Model Context Protocol (MCP) has quickly become one of the most debated topics in AI engineering. Is it just another abstraction layer? A repackaging of APIs? Or something fundamentally different?
In this AutoCon 4 on-demand session, William Collins, Director of Technical Evangelism at Itential, breaks down what MCP actually is – and what it isn’t – based on hands-on experimentation, real architectural tradeoffs, and lessons learned from trying to not use MCP first.
This session moves past hot takes to examine the real problems MCP was designed to solve, how it differs from REST and function calling approaches, and what scalable MCP architectures could look like in practice.
In this session, William covers:
- Why MCP is often misunderstood as “just an API wrapper.”
- The n×m integration problem MCP aims to address.
- Key architectural differences between RESTful APIs and MCP.
- Limitations of manual function calling and OpenAPI-based approaches.
- How MCP shifts integration from endpoint-based to intent-based design.
- What enterprise-scale MCP adoption could look like over time.
Get a clear, technical perspective on MCP – grounded in real-world builds, not hype.
![]()
You can’t get to agentic AI without first getting automation and orchestration right.
William Collins, Tech Evangelist
Video Notes
00:00 Why MCP Is So Polarizing
02:00 Is MCP Just an API Wrapper?
06:30 The Real Problem MCP Tries to Solve
10:30 Why REST and Function Calling Don’t Scale
18:00 Early MCP Experiments
24:40 How MCP Actually Works
31:10 From Endpoints to Intent-Based Design
37:50 Securing Tool Access with MCP
43:40 Scaling MCP for the Enterprise
45:00 Final Takeaways
View Transcript
William Collins • 00:09
Uh good morning. Really happy to be here. Um I don’t know how deep this is gonna go. Don’t uh don’t get too excited, but um also it’s funny, like I haven’t uh you know, at conferences like this, you don’t sleep 9 h a night, so I’m a little loopy on less sleep, and what that usually means for me is I mean I’ll just be square. I could say anything right now. I don’t know what I’m gonna say. So uh we’ll see how this goes.
William Collins • 00:37
Um so yeah, I’m William, director of technical evangelism. It’s a funny title sometimes because my grandma still thinks I work on computers for like a mega church. Like that’s her like seriously. Um so we might need to work on that. But um yeah, I work with Itential. Um if you want to learn more about Itential, you can go to the expo hall. And if you you can follow those neon signs and you’ll find us.
William Collins • 01:03
They they they stand out very nicely. So um today I want to look at something that is a little bit polarizing. And um what I really wanted to do with this, and and also to kind of preface this a little bit, I was kind of a late addition uh for this talk in particular. Um so late, in fact, that I actually started my slides, believe it or not, on the airplane here. So and then uh I worked on them in one of my least favorite places to work on slides now, which was on my bum in the Atlanta airport, which is not fun, and then finished them last night. So um but the good thing is I have a lot of time invested in this. Um
William Collins • 01:47
Uh well not for that long actually because it’s not been around for a year. I think the the year anniversary is next week or something since MCP got dropped. But anyway, let’s get started. Um so I want to look at isn’t MCP an API abstraction? Or is it something a little bit more? Um are we even asking the right questions about that? And why is it so polarizing?
William Collins • 02:08
What are the hot takes? Um so let’s get going. Uh so the obligatory agenda. Um, you know, framing the landscape, uh, framing some of the polarization, but then looking at kind of the okay, like why was this thing created? Why does it exist? Like what problem was it actually trying to solve? And for me, like
William Collins • 02:33
Not to be self-deprecating, but in the beginning, even though I saw all this hype, like you know, a hundred new LinkedIn posts a day, I was a little pessimistic. You know, for me, uh like one thing I’ll probably do through these slides a lot, and one thing I’ve done throughout my life is I always throw my hands up, oh, another thing. Do we really need another thing? We have RESTful APIs. We can use RESTful APIs for everything. Come on. And I went through the hard exercise of actually building these out with RESTful APIs and trying to make it work that way to prove that maybe we don’t need a new thing.
William Collins • 03:04
And what I realized was, okay, this actually has a place, and I’ll I’ll go into why. You know, those two things actually get conflated a lot anyway. Like and those are two different things. They’re related, but they’re also different. Like a a wrapper is uh makes it easier for me to use endpoints and it just makes things a little easier. And abstraction might make it to where I don’t even need to worry about the the endpoints themselves. So, you know, words matter and conflating these, I don’t think helps much.
William Collins • 03:45
So we’ll look at the RESTful API mechanics and then we’ll go in and kind of layer them on to MCP and look at really what’s different and how it’s different. And then we’ll a lot of this, I I gotta say, for a long time, um, it’s science experiment. Like we’re running all this stuff from our laptops. Uh imagine a world where everybody’s running MCP servers everywhere and every way, and okay, like that doesn’t scale. Come on. So after like adding this intelligence and layering that on, like what is the play, or like what is the path that this is like a thing that we can scale, you know, for a large company. So 1st of all, let’s examine the landscape a little bit.
William Collins • 04:34
So I I actually heard this quote right here. I was at a talk and I can’t remember how many months ago, but this is a pretty common one. MCP servers are just wrappers around APIs. Everyone’s got a gimmick. And I’m like, oh, come on. No, not MCP, you can’t talk about it that way. But then as I started to think about this, and here here I am, like already So I’m gonna still man that argument a little bit real you know, real quick.
William Collins • 05:02
So if you actually go out and look at a lot of these implementations, that is that’s literally exactly what they are. So you could say that there’s empirical proof out there that that’s like a true statement, but that doesn’t mean that’s how it’s supposed to be. There’s no empirical evidence that this is ever going to happen, but this there’s actually some talk tracks and lines of thought that, like, hey, MCPs here, they’re they’re gonna surplant RESTful APIs. You know, that their RESTful APIs are gonna be no more. And that’s I I think we can all agree that that’s just not gonna happen. Um and then the last one, and this is a this one was interesting. So I remember I got in a I wouldn’t say it was a debate, but just it was a really good conversation with a group of folks probably earlier this year about this very thing.
William Collins • 06:01
And and what they said was MCP offers nothing beyond this existing function calling mechanisms. And I think my to add context for me in this scenario, like what it took for me was actually going and trying to build this and prove that MCP wasn’t needed, and trying the function calling methodology and then trying the, you know, let’s import a whole API schema. You know, how does that work? And kind of working through these things. So we will get into that here in a 2nd . But looking a little bit further, yeah, November 25th, that’s what it was.
William Collins • 06:38
I was trying to remember. Um so yeah, we’re almost at a year. Um it would have been really sweet if uh it could have been on this day that I was talking about this. Ah, it would have been great. Too bad. So what is MCP? And I’m just gonna read.
William Collins • 06:51
I took this definition just straight from their GitHub. Uh it’s an open protocol for um that enables seamless, seamless integration between LLM applications and external data sources and tools. Okay, that’s Sounds not crazy special. It’s okay. But the 1st thing that you know, if you’re a network engineer, you think of okay, why kind of like why do I need this? And and like why should I care?
William Collins • 07:20
Let’s be let’s be real. So again, I don’t know if I took this from the GitHub or one of their blogs, but um basically their definition without a standard connecting AI applications, two data sources requires custom integrations to every combination. So lots of integrations. And maybe it never happens. Or maybe you work with a medium-sized company, and maybe it takes like five to eight months, or maybe you maybe you work you you bring in a startup that’s desperate for customers, and they’re like, yeah, we’ll have that tomorrow or next week. Um all of those are valid things that tend to happen. So integrations, it’s part of our all of our lives.
William Collins • 08:13
So I for me and my in the beginning, my pessimistic attitude, it was kind of like not enough. Like, okay, so is this really problematic enough? Again, hands in the air, why do we need another thing? I’m there’s so many things already. Like I just, it’s it’s overwhelming. So what what then is the real problem? And my the way that I see it, and I think the way that the folks that actually built MCP, there’s some blogs, there’s a lot of writing out there.
William Collins • 08:45
But just looking at the um n times M, this this integration problem, and we’ll get into that here in a 2nd . Uh So I I love this quote, I’ve used it a few times. But if our brains were simple enough for us to understand them, we’d be so simple that we couldn’t. The collapse of chaosy and stewart. Great one to have on the shelf. So the n times m problem.
William Collins • 09:10
And basically what this says basically is n is going to be representative of the number of models. So Claude, uh it actually these are now that I’m thinking about this, these are not actually models, they’re like the AI platforms, but you get the idea, the models under the platforms. So and then you have all these unique integrations with. So this maps to the number of tools. So like Salesforce, GitHub, your your private things that you’ve built. So if you think about it, uh just simple example. So if you have four models with access to 10 tools, you have 40 separate integrations, or so the you know, the talking track goes.
William Collins • 09:53
That’s a lot of integrations, but at this point, like Like even MCP on my laptop right now, I’ve been running probably four models with way more integrations than that. So you can see how this would become problematic if you’re a big company and big companies do lots of things. Um and if this AI thing is gonna be as big as everybody thinks it is, there’s gonna be a lot of this happening. So like we just determined, if you don’t have a standard You have customizations. If you have customizations, you have brittleness.
William Collins • 10:28
If you have brittleness, hey, things break. They cause outages. You know, cloud cloud flare could could go down. So uh this, you know, four models. Um I, you know, just thinking about this or trying to think about it, you you have this, you know, if you think about developer bottlenecks, and I I hate using like vendor lock in talking points are like some of my least favorite things, but I think it’s actually interesting in this context because usually actually the 1st thing that comes to my mind when I think of vendor lock in is Active Directory. Active directory, the the master class there. But then you have like um in reality, a lot of times with big companies, you’ll have things happen like okay, we’re we’re in a single cloud provider, or like we’re in AWS.
William Collins • 11:19
Okay, that’s a single point of failure. We don’t want to be locked in. Like we need negotiating leverage, like all sorts of talking points there. So then the logical thing to do is to go into four cloud providers, and that will fix those problems. So vendor lock in with in the context of this conversation is a little nuanced. It’s actually different because And I’ve thought about this a lot, and I would actually love if any of you all after this talk have opinions or thoughts about this too.
William Collins • 11:48
I just think it’s interesting. But it’s kind of split. Like usually it’s the vendor. Like you’re the customer, you need more vendors or more things, so you’re not locked into a certain type of technology. But this is, you know, if you think about it from the vendor perspective, it’s more of like a cost lock in in a sense, because you have the developers that are building the integrations. You have uh uh competitive pressures from your your um competitors out there, you have pressures from your customers to support more. And hey, you you know, back to the last talk, you know, engineers are good engineers are in high high demand, you know, and they’re probably you know very expensive as well.
William Collins • 12:30
So that sort of in my in my mind feeds down to the, you know, it has a direct impact and a correlation on the customer side. Because customers It’s the same thing. Like they it basically doesn’t they they don’t have leverage on the vendors and the tool providers and the the LLM providers. Like they lose that leverage and just more of the traditional sort of view of the vendor lock and stuff. So it’s kind of like a split there. And there’s also the high maintenance.
William Collins • 13:04
You know, I don’t want to belittle this point or belabor this point, but you know, very high maintenance. Lots of stuff, lots of brittleness. And I think the last one that’s important and it’s worth thinking about is this quadratic complexity, which is to say not linear. That’s a terrible definition of that. Hold on. That’s that’s cheap. Um if I was in your seat, I would be like, what did you just say?
William Collins • 13:31
Uh so quadratic complexity uh stems from something with like models machine learning called uh self attention. Uh and self-attention has you know n squared complexity, meaning that you know the oh that the computational cost is going to scale with the square of the input length. Well now that I say that that sounds confusing too. Hold on. So so basically what that means is like if you have 10 tokens, that’s like a hundred operations. All right, or if you have a hundred tokens, that is geez, 10,000 operations. You get the point.
William Collins • 14:15
It’s full mesh. That’s let’s think about it that way. So plowing ahead. So what what does MCP try to do to this to make it better? So of course it’s a standard, but you basically to basically connect that n model to m number of tools, it shifts it to n clients plus n number of servers, so it becomes additive. Okay, so that’s easier on on the surface. So
William Collins • 14:51
Again, this it’s so funny because uh just thinking about my experience with APIs personally, like over the years. Uh I I remember when I 1st started working with APIs, I was like building like horrible stuff in Perl at the time and horrible stuff in Python earlier on. And there’s actually someone here, I don’t know if he’s in here, but when I in a galaxy far far away, when I was in ops, I remember the 1st time I started building with uh soap and I was in XML Purgatory and I had like Python, big suds, and just I thought I was a real hot shot. I don’t know if you’re in here, Kevin, but you were you there he is. We yeah, funny how small of a world this is. But those were good times.
William Collins • 15:36
And then Rust came along and I was like, not another thing. That’s always my initial reaction. Hands in the air, like knee-jerk, and then then I’ll use the new thing, and I’m like, oh, this is good. This was a good thing. So very quick. Um but I I love this quote in in one of my knee-jerk reaction attitudes, someone sent this to me. If we open a quarrel between past and present, we shall find that we have lost the future.
William Collins • 15:59
I love that. It made it to my sticky noteboard that I write cool things on when I I need a little bit of inspiration. So Just again, API mechanics. Um, you know, so we this should be a visual that all of us have probably seen a thousand times. Um, but I just want to point out a few distinct things before we get to the MCP AI things. So, you know, all the way on the left you have the client, all the way on the right you have a server.
William Collins • 16:27
Okay, it’s a client server architecture. Awesome. Uh it’s also more or less a framework. Um an MCP is a protocol. But I mean the this framework, this RESTful framework does use a protocol, it uses HTTP. But you have, you know, the way that you’re going to structure and start building things, you have these fixed verbs. You have Git, you have, you know, put, you know, post, delete.
William Collins • 16:52
Like these are the things we do all the time uh every day. And so the the main thing here to keep in mind is this is like uh the uh you know, request, response, request, response. That’s the model. There’s no state. Like it’s not like you open a session and there’s all this state there and you’re just continuously doing things back and forth. Client server, request response, um stateless. And we should know that like, you know, I love firewalls and load balancers to death.
William Collins • 17:23
They’re great until you but they’re stateful. Well, the stateful things, things break and it’s like, uh, so you love them until they break. And that’s what we get when we incorporate a ton of state in in one place. So When you know traditionally, like how we would go about doing this, and one thing, so I I in my haste to get these slides done, I failed to make a slide to explain this. But I I’m gonna have some coding examples I’m gonna go through. Of course, you can’t fit many lines of code to where anybody can see anything on the PowerPoint slide.
William Collins • 18:04
So at the end of this talk, there is going to be a QR code. You you can scan the QR code. And that is going to take you to the new trendy thing, the the link tree, where you have all these links to how to find people. You’re gonna find my my TikTok where you can find my excellent dancing videos, and then you will find my GitHub which will have a project called Talks that’s pinned. And within that project called Talks, there will be a folder called like 2025 NAF Autocon or something along those lines. So these these coding examples will be in there if you actually want to go in and look at them and figure things out. And another thing too, I these coding examples were at a time in my life where I was almost trying to disprove that MCP was necessary.
William Collins • 18:54
And I’m also a hockey fan. I love hockey. I play hockey. And then we’re Git, you know, it it returns data to us. Well, then with that day that it returns, I need to take out the things in that data and filter the things that are important to me. So I can format them, and I I just don’t want everything.
William Collins • 19:56
I want the things that I want, right? So I do these things, I run this thing, and then I have this magnificent piece of stats that you know I am not an Eulers fan, by the way. I just I can’t stand them, but I am a Connor McDavid fan. I don’t know if anybody here follows hockey. It’s like watching Magic on Ice. He’s incredible. Best hockey player that’s ever lived, fastest, his toe drags are amazing, etc.
William Collins • 20:19
So moving ahead. Um so I mean this is just this is what we’ve been doing forever. This is, you know, history. So in my mind, early on, I thought, okay, how do I do this and connect LLM and you know, how do I do this through REST? You know, if we don’t want to use MCP, like what are even the options? So the 1st option that I ran into earlier on is something that you you uh I actually don’t even know.
William Collins • 20:48
I mean it this is probably the name, or I don’t know if it has an official name, but just manual function calling. So in this sort of scenario, you’re you’re just you’re handcrafting these these JSON schemas by actually by hand. It’s pretty manual. And there’s uh there’s tons of glue code. There’s just lots of stuff that you have to account for. And I think the hardest thing to wrap my head around was actually doing this uh agent loop thing. Um which is not I mean, I’m not like a very seasoned like software architect.
William Collins • 21:19
You know, I’m sure for like the smart software architects, it’s like, yeah, that’s I’ll just wipe that out real quick. But you have to account for like the all the tool calling, the messaging, the tool execution, the state stuff, like all these things. You know, really it’s the uh It’s the orchestration of the conversation flow with the agent. I don’t even know if I said that right or elegantly that you have to really facilitate here. And after getting it in and actually finally getting to work, I was like, the no bueno, I can’t do this. This is not, this is a little too hard for me.
William Collins • 21:57
So then I started looking at these other alternatives at the time, just approaches. And the other logical thing was okay, we have REST is very well defined. We have lots of you know schema files out there all over the planet. So, okay, we just pull the tools or we just import a you know open API schema. And then we ma you know it’ll automatically make our tools and we’ll have to do like a little bit of things, and then that’s that’s it. That’s the solution. The things I ran into, so yeah, it builds all the tools.
William Collins • 22:31
Like I don’t have to worry about that anymore, but I still have a lot of glue code that I have to account for. And it’s funny because we a lot of times we’ll we’ll make like one thing easier and then it creates like other thing, other problems that then we have to deal with. So maybe like two problems solved, five new problems or something along those lines. So you you have the custom logic stuff that you still have to do. Like how you know we have these tools now, how do you filter them? How do you categorize them? You know, dynamic, you know, selection of said tools, yada yada yada.
William Collins • 23:06
So what that turns into is, and I just said one spec file, a hundred tools, but some of these spec files have lots of endpoints. Lots. So then you are dealing with um the I I think the core thing here that that you run into is you know what they call, you know, you’re bloating the context window. So you’re providing so many tools uh that the AI robot is getting confused because things are not relevant to what you’re you’re trying to get out of it. It’s getting a lot of different stuff. And just from a I’ve read a lot about this.
William Collins • 23:41
I don’t know what the guidance is now. It’s been a few, and this stuff changes so much. But I think the generally what I’ve read is like you don’t want to provide more than like 10, or not 10, like 20 to 30 tools, I think, maybe. Like once you start throwing in like more than that, you’re you’re hitting like massive confusion. Your results are not gonna be the greatest. Um performance, degradation, all these things. You’re just not gonna have a good experience.
William Collins • 24:08
Gonna be a little bit rough. So this is like when it’s like, okay, uh Let’s try to build an MCP server and see what happens. And this is there’s many projects out there that make some of these things very easy. Fast MCP, fast API, there’s a lot of stuff to where you’re not starting from the ground floor. You’re you got some help and you have a lot of good documentation. So one of the quotes that I think um is really spot on.
William Collins • 24:42
So Abraham Lincoln said that um MCP is probably the only tech that has more builders than users. And and he was very ahead of his time with the statement. Um I I agree, and it’s it’s still relevant, believe it or not. So I when I was going through and actually doing these slides, someone said that you you gotta do like a side by side with a few of the the attributes of each, because that’ll be easier. Because if you do one section on one thing and one section on the other, you know, it’ll be confusing. So um I did want to line this up. So RESTful APIs, they’re they’re built for me.
William Collins • 25:20
They’re built for all of you. They’re built for humans to write some software. Like, let’s go. MCP wasn’t built for me. It was built for models. In this, you know, to try to basically, you know, expose tool, you know, connect tools data stuff safely. Well, safely is relative sometimes, but yeah.
William Collins • 25:42
So REST, as we discussed, um, it is an architecture. It’s not a protocol, but it does use HTTP. MCP is an open standard. Standard, standard, standard. Standards are good, right? Um, public specification, etc. So um and and this is the big one here for me.
William Collins • 26:04
Because I I think I uh like so I remember the last time. The last time I attended and and presented at like an Ansible fest, like way, way back, and like Terraform was up and coming and stuff, and I in the beginning I had this thing of like, oh, is Terraform better than Ansible? Is Ansible better than Terraform? And just like the last time, as I grew and I started using these tools, I’m like, okay, what is what kind of that’s wrong, the wrong question. One is not better than the other. And one of the things that makes those tools fundamentally different, and one thing that causes actually a ton of confusion is one is very stateful with very big state files, and the other is not. I think that’s probably one of the fundamental differences about what makes those tools different.
William Collins • 27:08
Um, declarative, imperative, etc. So Just like with REST and MCP, one is stateful, one is stateless. Well that that’s a big difference. Um that that changes things. So that last uh that RESTful API little diagram that I put together with like the pretty boxes, and it was it was very beautiful, very elegant. Uh if if I take that beautiful diagram and I try to like retweak it for MCP, it probably looks something like this.
William Collins • 27:39
So you have host all the way on the left. So this is see, this is kind of like it’s funny because like when I think of host, I think of like my MacBook or I think of like a server connecting to a network. And this is kind of confusing because like in this world, like a host is is actually a uh like uh an LLM application. It’s the execution layer for this. So like claude desktop or like an IDE or something. That’s considered a host. It’s like virtual private context and virtual private cloud.
William Collins • 28:11
Let’s just kind of say the same thing and they mean completely different things. So basically what’s gonna happen here is it’s gonna use JSON RPC for for the transport. And those fixed uh those fixed verbs, you know, with REST that we talked about, um, we we flip that over, and and kind of what we have here is resources, prompts, and and tools. Now we all all of us are probably prompting experts at this point. You’re just templating what you want and you know, feeding your you know stuff, like prompts are not that hard to wrap your head around. But resources are interesting because um you know resources are basically a a uh A way to return structured data in a sense and then load context.
William Collins • 29:00
So AI agents can can do things. And it’s it’s read-only. So I mean it’s almost like a I guess if you wanted to try to make a comparison, it’s like a Git, you know, request with REST, maybe a little bit, but not really. This is why it’s hard to compare things. You know, because there are similarities with certain things, but in a lot of ways they’re they’re fundamentally different. So you have that thing where you’ve pulled in the context, you have the resources, and the tools are where the where the action happens.
William Collins • 29:30
That’s your your execution. And I guess if you wanted to compare the frameworks, like Git would fall under the resources, and the put, post, and delete would fall under the tools if you wanted to try to draw that conclusion. But again, different different things. I sped through this part right here in my slides, but I have that content, context, and logs down there as an example of something that’s getting, you know, shot back to the to the client. And they somebody said this to me, and I I didn’t actually. You’d have to Fact check this, or uh not fact check, but this is the way I thought this was a cool thing.
William Collins • 30:27
So content is kind of like the the what. So you can almost think about it as like the actual response, kind of how you get a response with rest, like you’re returning something. And then the context is the where, like the um the stuff that’s getting loaded in in the context window, and then the logs are the how. Like you have all this stuff coming back. You you know, if there’s a problem, you have just continual stuff streaming back to the client. So it’s this thing that it’s like a loop. Um now going from my like when I went from okay, like just trying to do all of this in REST is really hard.
William Collins • 31:10
And I I can’t do it very well. So this is when I was like, okay, I’m gonna build this MCP thing. And it’s funny because like these examples work now, but when I I ran them a few days ago just to make sure they still worked because I built them like a long time ago. And of course everything was broke. Like so much has changed since when I 1st built them, like ah. So I had to go back it. They do work now though, but you better try them quick, or they might break again.
William Collins • 31:37
So So looking at what makes the MCP experience actually a little bit different is decorators automatically generate the schemas from your doc strings. So that eliminates so the way that this is fundamentally built is it eliminates a lot of stuff that you or that I was having to do. So really reduces and almost eliminates a lot of the glue code I was putting together, which wasn’t the best. But you know, you you’re not accountable or on the hook for the JSON RPC, like all the message handling stuff. Um and and no more agent loop. So when I didn’t have to do the agent loop part of this to get it to actually work, I was sold.
William Collins • 32:17
It was like, yep, let’s go. Um much cleaner, much more elegant, much less lines of things, and and much more consistency. So it it’s interesting when when you when you start using or you’re building or you’re something programmatically, a lot of times what I would do is I’d go into um oh Uh postman. And you know, I’m building these calls and you know trying to figure things out, and then I end up moving to like request Python or something, and I I build my thing. Um 1II try to help, you know, I’m not an expert at any in fact, like, you know, Malcolm Gladwell, yeah, I think Malcolm Gladwell, like he didn’t do the research, but you know, the whole 10,000 hours thing. You 10,000 hours of not just saying I work in IT or I work in network engineering, but intentional practice.
William Collins • 33:12
That’s what makes you an expert. Now there’s real research behind that somewhere, but I I I don’t know. Um Uh what it is, but so guess who doesn’t have 10,000 hours building this stuff? This guy. That’s a lot of time and a lot of intentional practice for something that hasn’t been around that long. Um and I don’t know very many, like personally, very many people that do.
William Collins • 33:35
That’s a lot of time. So one of the things, you know, that I get a lot of questions on like LinkedIn for help with certain things, and it’s funny because one of the questions that I’ve gotten the most that I’ve actually been able to help people with is, and these are like some of them are software engineers, is how do I connect to the thing? Like, I do I can I do it from Postman or what the heck is going on? This documentation is like out of control. Was it generated by an LLM? You know, whatever. So the experience of even starting to get connected here is a little interesting.
William Collins • 34:06
So Generally, what happens, we want to get started, we want to start testing. We clone some repo that has some things in it. I just use the repo that I have these tests from. So we clone that down, and then we are all we are all good humans, and we create virtual environments with a good version of Python that’s compatible with all the things we want to do because we’re responsible. I always use 3.11 for like the past two months because it just seems to work with everything. So I create a virtual environment, and then I resolve all this dependencies, install my dependencies.
William Collins • 34:44
And this is actually where where some of the folks that I um was helping out, they are like stuck. Like, what isn’t it ready? Like, how do I connect to it? It’s there. Do I just launch a Python file? Like, why is this so confusing? And um generally the way that this will go is if you’re using something like uh well, actually, if you’re using like the claud codes or the Gemini’s, these I started experimenting heavily with like cloud code like a few months ago.
William Collins • 35:08
And it has like this use you know, a/and MCP, and then you can just put in some things and it’ll do it for you. But a lot of what we were doing before, and kind of what you still do in some circumstances is you have this um, you know, you have a JSON file. Um and it defines all of your MCP servers that you want to be available to you know, something like Claude Code. And these look for these files in a certain place, etc. So make sure that whatever host that you’re using um that you put the file in the right place because that’s a common problem. And then you have, you know, basically two things.
William Collins • 35:45
If you’re running it locally right here, you have the command, which is basically your it’s just a path to an interpreter. It’s your execution. And then you have a bunch of arguments you can pass in. And if you look at I should have like pulled out my one of my other ones. It’s like these arguments can just get out of control. Because you can pass in so many things. But yeah the the argument here is just passing to the actual you know server that we want to run.
William Collins • 36:11
So basically in this scenario, I’m not going, I’m not, you know In my my Linux terminal, I’m not going to this directory and saying, Python, run this file. Okay, I have a server running on my machine. No, this is going to do that. It’s gonna call the interpreter and pass in my args when I open up whatever the host is. So in my case, I did this with Cloud Desktop. So I open and I had these little things here that I didn’t even look at that.
William Collins • 36:40
I had animations and everything, and I put the card before the horse and I just talked through it. Anyway. So after I do this, I have this file and it’s saved. Like, what do I do now? Well, now all you gotta do is open up your host. So and then you can toggle the tools. Um a lot of times there’s just so many tools.
William Collins • 37:00
And this is a good way. So if I have like a list of you know 20 or 30 tools, I can say, okay, for this thing, I’m just gonna have these four selected. And that way, every time you open up the host, most of them will remember that. And those are the tools that you will start with. So everything gets instantiated as soon as you open up the application. Um so now I can go in and I can just have a fancy way to say, oh, what are Connor McDavid’s stats? Um and even like I added this was really cool because I started adding a few other things.
William Collins • 37:32
I just copied that and I’m like, why don’t I compare his stats to like oh Austin Matthews? You know, they lost uh Marner, and it’s just like they’re they’re just gonna stink this year. Because Marner, nobody appreciated him. And he he was a very good supporting player. Sorry, it drives me nuts. But um yeah, I get all this stuff and I can just do a lot more easier. So now
William Collins • 37:58
Thinking about this and and just thinking about like how do we how do we scale? And I think oh I think it was um I think it was actually Jeremy Schulman at some other event, but he was saying something about how like uh he had this little spiel about like getting, you know, make getting vendors to get on board and accountable to start doing things. I I can’t say it the way he said it. He said it much better and elegantly. But yeah, push the vendors that you’re using to start doing this. And that always made me think of um, you know, there was a quote from Batman Dark Knight Rises from Commissioner Gordon where he said, MCP is the standardized interface we deserve, but not the one vendors need right now.
William Collins • 38:45
So they’ll question it because it can take it. Because it’s not just another API wrapper, it’s a context provider, a capability exposer, a model context protocol. So thank you, Commissioner. So plowing right ahead. Um and this is I don’t know, this is even hard for me to say out loud, but um because I think like some of these words it’s hard because like uh Just marketing and industry, like we’ve abused like so many words and tried to make them like say so many different things that eventually they like lose meaning. So I’m gonna try here to be genuous and say this.
William Collins • 39:27
So one thing I sort of kind of figured out is like instead of thinking about like it’s always for me, it’s always been about the endpoints, the endpoint this, endpoint that. You have to like shift that thinking from endpoint to actual intentions. So like on the left here, in the left corner, we have this endpoint mapping, you know, say like an API wrapper, and we’ve all built stuff like this where hey, we get a list of like a bunch of a bunch of devices, and we have this ID that we return, and then we insert that into another call, and that returns a thing, and then we insert that into another call, or we take some data out of that and do another thing. So we’re really like looking at this endpoint-based way of architecting things. And with um with this stuff, it’s a little bit different. So it’s more intent-based. You know, semantic abstraction.
William Collins • 40:18
So if you think of the whole thing like, okay, I want to um whatever, I want to back up a config. I can hardly see my examples down there. I want to run a compliance check. I want to back up a device configuration. It’s like this one thing that is composed of like, you know, many different tools that that meet that outcome. Um what it really so in my mind, like when I try to like think of it and like reason through it, it’s like, okay, like if I’m wrapping APIs, which we’ve already established that This is a real thing.
William Collins • 40:55
You can use MCP to wrap APIs. Like, that is a real thing. You you’re doing direct endpoint to tool mapping. And so you become a systems integrator. That is what your AI is doing. And you’re you’re spending lots of money on tokens for maybe nothing. And the sort of the oh well, I can’t even see the white, whatever that says, but I think it was you know a full sort of domain operator or an expert in a specific domain.
William Collins • 41:24
Like that is what the AI, like, kind of like where you want to go with this snooish thing um with MCP. So as we start to like layer on, you know, we have this architecture and we start to try to layer on intelligence, we we don’t want to live in, you know, hackers are never gonna stop. They’re just not. So I would love to live in this world where we could just run everything everywhere. Everybody’s happy, we don’t have to worry about security. Wouldn’t that be nice? But then unfortunately, we’re never gonna live in that world.
William Collins • 41:58
So as far as like a shifting in thinking, capability filtering becomes very important, context where you know tool exposure. So when you think of like Roles, personas. Roles and personas are really different. Uh like let’s just say the persona of ops and a persona of like uh engineer. So you have these different roles, you already have R back, you already have um organizational security. How do we get these things that we’ve built to be able to be connected and and sort of like architected with those things?
William Collins • 42:33
So we have to be able to define roles. And one of the great ways that you can do this is actually defining tags. Um having tool exposure based on tags. So say that I have an ops team and I just have a health tag. You know, that might expose you know tools like this. Like get the system health or something, uh, maybe restart certain types of services, etc. And then again to the engineering side, uh, backup configuration, or whatever a network engineer or a systems engineer would be able to do.
William Collins • 43:05
So this is kind of the, you know, as we start to see these mature, like this is where it’s gonna go. We have an architecture, we’ve built an optimized MCP server. We’re trying to build it the right way, and and then we can start doing neat things like this. So what about scale though? And this is something that’s really important is like we can science experiment all day. Um But like where what are the paths that this is going to go to where like you can you know an enterprise can can use this thing or they’re gonna buy something and it’s scalable.
William Collins • 43:42
So uh I think the this is what I have my money. Well I shouldn’t say that here, but uh my money would be on like uh history. So if you look at like the proliferation of APIs around the planet, and then suddenly these API gateways pop up. Okay? Makes sense. So wow, now we have this proliferation of MCP servers all over the planet. So wouldn’t wouldn’t it make sense that MCP gateways are gonna start to pop up?
William Collins • 44:10
Maybe. Um one thing that’s already happening is there’s a lot that are well not a lot. There’s some that are vendor hosted now. So a vendor might have a platform that’s like cloud based and they just expose an endpoint, and that’s how you connect to MCP. Um am I over time? Holy smokes. Um that’s like the I guess the vendor hosted methodology.
William Collins • 44:33
That’s just again that’s already happening. And then you have the private stuff in your own data centers, and that’s Probably gonna be Kubernetes clustered, like just kind of the same old way that we’re architecting those things now in data centers. Um again, adding intelligence doesn’t mean scale. These are two very different things. Very different things, different problems to solve. There’s some bullet points there as to why, you know, that makes sense.
William Collins • 45:02
And I’m going to Come to a conclusion now. So thank you. There’s my pretty QR code. Thanks a lot.