MCP Beyond the API Wrapper

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.

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.

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:51

I took this definition just straight from their GitHub. Uh it’s an open protocol that enables 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 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 to 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 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 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 overwhelming. So what what then is the real problem?

William Collins • 09:10

And basically what this says is n is going to be representative of the number of models. So Claude, you know — these are not actually models, they’re like the AI platforms, but you get the idea, the models under the platforms. And then you have all these unique integrations with. So this maps to the number of tools. So like Salesforce, GitHub, your private things that you’ve built. So if you think about it — simple example — if you have four models with access to 10 tools, you have 40 separate integrations.

William Collins • 09:53

That’s a lot of integrations, but at this point, 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, Cloudflare could go down. Just thinking about this — if you think about developer bottlenecks, and I hate using vendor lock-in talking points — they’re some of my least favorite things, but I think it’s actually interesting in this context.

William Collins • 13:04

You know, I don’t want to belittle this point or belabor this point, but very high maintenance. Lots of stuff, lots of brittleness. And I think the last one that’s important and worth thinking about is this quadratic complexity, which is to say not linear. That’s a terrible definition of that. Hold on. If I was in your seat, I would be like, what did you just say?

William Collins • 13:31

So quadratic complexity stems from something with machine learning models called self-attention. Self-attention has n-squared complexity, meaning the computational cost is going to scale with the square of the input length. Basically what that means is if you have 10 tokens, that’s like a hundred operations. If you have a hundred tokens, that is 10,000 operations. You get the point. It’s full mesh. That’s let’s think about it that way.

William Collins • 14:15

So plowing ahead. What does MCP try to do to make this better? Of course it’s a standard, but basically to 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 the surface.

William Collins • 16:27

It’s a client-server architecture. Awesome. It’s also more or less a framework. MCP is a protocol. The RESTful framework does use a protocol, it uses HTTP. But you have these fixed verbs — GET, PUT, POST, DELETE — these are the things we do every day. The main thing here to keep in mind is this is request-response, request-response. That’s the model. There’s no state. It’s not like you open a session and there’s all this state. Client-server, request-response, stateless.

William Collins • 24:42

Abraham Lincoln said that MCP is probably the only tech that has more builders than users — and he was very ahead of his time with that statement. I agree, and it’s still relevant, believe it or not. So I wanted to line this up. RESTful APIs — they’re built for me, for all of you, for humans to write some software. MCP wasn’t built for me. It was built for models. To expose tools and data safely. (Safely is relative sometimes.)

William Collins • 25:42

REST is an architecture. It’s not a protocol, but it does use HTTP. MCP is an open standard. Standards are good, right? Public specification.

William Collins • 27:08

Declarative, imperative, etc. Just like with REST and MCP, one is stateful, one is stateless. That’s a big difference. So that beautiful RESTful API diagram — if I retweak it for MCP, it probably looks like this.

William Collins • 27:39

You have host all the way on the left. When I think of host, I think of like my MacBook or a server connecting to a network. In this world, a host is actually an LLM application — the execution layer for this. Like Claude Desktop or an IDE. That’s considered a host.

William Collins • 28:11

So basically what’s gonna happen here is it’s gonna use JSON RPC for the transport. And those fixed verbs we talked about with REST — we flip that over, and what we have here is resources, prompts, and tools. We are all probably prompting experts at this point. Resources are interesting because they’re a way to return structured data and load context.

William Collins • 29:00

AI agents can do things. And it’s read-only. So it’s almost like a GET request with REST, maybe a little bit, but not really. This is why it’s hard to compare things. There are similarities, but in a lot of ways 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 action happens.

William Collins • 31:10

So this is when I was like, okay, I’m gonna build this MCP thing. These examples work now, but when I ran them a few days ago just to make sure they still worked, of course everything was broke. So much has changed since when I first built them. They do work now though, but you better try them quick, or they might break again.

William Collins • 31:37

Looking at what makes the MCP experience a little different: decorators automatically generate the schemas from your doc strings. So that eliminates a lot of stuff that I was having to do. Really reduces and almost eliminates a lot of the glue code. You’re not accountable for the JSON RPC, all the message handling stuff. And no more agent loop. When I didn’t have to do the agent loop part of this to get it to actually work, I was sold.

William Collins • 37:58

Thinking about this and how do we scale — I think it was Jeremy Schulman at some other event, but he was saying something about getting vendors to get on board and accountable to start doing things. Push the vendors that you’re using to start doing this. That always made me think of — 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 • 39:27

One thing I sort of figured out is instead of always thinking about endpoints, you have to shift that thinking from endpoint to actual intentions. With MCP, it’s more intent-based — semantic abstraction. So if you think of the whole thing like, okay, I want to back up a config. I want to run a compliance check. It’s like this one thing that is composed of many different tools that meet that outcome.

William Collins • 40:55

If I’m wrapping APIs — which we’ve already established is a real thing — you’re doing direct endpoint-to-tool mapping. You become a systems integrator. That is what your AI is doing. You’re spending lots of money on tokens for maybe nothing. The goal you want with MCP is more of a full domain operator or expert in a specific domain.

William Collins • 41:58

As far as a shifting in thinking: capability filtering becomes very important, context, tool exposure. When you think of roles and personas — they’re really different. The persona of ops vs. the persona of engineer. You have these different roles. You already have RBAC, you already have organizational security. How do we get these things we’ve built to be connected and architected with those things?

William Collins • 42:33

We have to be able to define roles. One of the great ways you can do this is by defining tags — having tool exposure based on tags. Say I have an ops team and I just have a health tag. That might expose tools like “get the system health” or “restart certain types of services.” Then on the engineering side, backup configuration, or whatever a network or systems engineer would need.

William Collins • 43:42

So my money would be on history. Look at the proliferation of APIs around the planet — then suddenly API gateways popped up. So with this proliferation of MCP servers all over the planet, wouldn’t it make sense that MCP gateways are gonna start to pop up? Maybe.

William Collins • 44:10

One thing already happening is there are some that are vendor hosted now. A vendor might have a platform that’s cloud-based and they just expose an endpoint, and that’s how you connect to MCP. That’s the vendor-hosted methodology. And then you have the private stuff in your own data centers — probably Kubernetes-clustered, the same way we’re architecting things now in data centers. Adding intelligence doesn’t mean scale. These are two very different things, different problems to solve.

William Collins • 45:02

And I’m going to come to a conclusion now. So thank you. There’s my QR code. Thanks a lot.