I missed an update. How did MCPs come into this world?
MCP vs. API Explained
91–100 of 119 posts
Re: MCP vs. API Explained
#92Earlier quoted context omitted.
Exactly. An AI-web based on the principles of HATEOAS is the next step, where instead of links, we would have function calls. As you said, HATEOAS requires a generic client that can understand anything at runtime — a client with general intelligence. Until recently, humans were the only ones fulfilling that requirement. And because we suck at reading JSON, HATEOAS had to use HTML. Now that we have strong AI, we can d…
Both blog posts were excellent. Thanks for the breakdown. I’m bullish on MCP-what is are some non-obvious things I shod consider that might dampen my fire?
TL;DR: IMHO, the MCP enforces too much structure, which makes it vulnerable to disruption by less structured protocols that can evolve according to user needs.
The key reason the web won out over Gopher and similar protocols was that the early web was stupidly simple. It had virtually no structure. In fact, the web might have been the greatest MVP of all time: it handed server developers a blank canvas with as few rules as possible, leading to huge variance in outputs. Early websites differed far more from each other than, for example, Gopher sites, which had strict rules on how they had to work and look.
Yet in a server-client "ping-pong" system, higher variance almost always wins. Why? Because clients consume more of what they like and less of what they don't. This creates an evolutionary selection process: bad ideas die off, and good ideas propagate. Developers naturally seem to develop what people want, but they are not doing so by deliberate choice — the evolutionary process makes it appear so.
The key insight is that the effectiveness of this process stems from a lack of structure. A lack of structure leads to high variance, which lets the protocol escape local minima and evolve according to user needs.
The bear case for MCP is that it's going the exact opposite route. It comes with tons of features, each adding layers of abstractions and structure. While that might work in narrowly understood fields, it's much harder to pull off in novel domains where user preferences aren't clear — knowing what users want is hard. The MCP's rigid structure inherently limits variance in server styles (a trend already observable IMHO), making MCP vulnerable to competition by newer, less structured protocols — similar to how the web steamrolled Gopher, even though the latter initially seemed too far ahead to catch. The fact that almost all MCP servers are self-contained (they don't link to other MCP servers) further means the current lead is not as effective, as the lock-in effect is weaker.
Re: MCP vs. API Explained
#93Earlier quoted context omitted.
The success rate of this is impractically low. APIs are dirty, inconsistent things. Real-world connection to obscure APIs is a matter of hard sleuthing. Docs are wrong, endpoints are broken, auth is a nightmare. These APIs need to be massaged in advance and given a sanity-wrapper if you want any semblance of reliable success when a model calls them.
Wouldn’t you just do that with an SDK? Why the extra layer of complexity with MCP?
Personally, I’ve found the SDKs worse in almost all cases.
Re: MCP vs. API Explained
#94Earlier quoted context omitted.
Both blog posts were excellent. Thanks for the breakdown. I’m bullish on MCP-what is are some non-obvious things I shod consider that might dampen my fire?
TL;DR: IMHO, the MCP enforces too much structure, which makes it vulnerable to disruption by less structured protocols that can evolve according to user needs. The key reason the web won out over Gopher and similar protocols was that the early web was stupidly simple. It had virtually no structure. In fact, the web might have been the greatest MVP of all time: it handed server developers a blank canvas with as few ru…
Under this thesis, then SLOP would win, except I don’t yet see how it can be composed by the user, which MCP is supposed to have moved the composability into?
Re: MCP vs. API Explained
#95shameless plug: we're building a registry and tooling for multi-platform MCP-based tools check it out https://www.mcp.run/
Re: MCP vs. API Explained
#96Earlier quoted context omitted.
My impression, and perhaps this is wildly off, is that MCP could be useful to whitelist safe usage of tools by LLMs. I say this out loud so someone can correct me if I’m mistaken!
Then it's a useless concept, because people who use LLMs don't want to be bounded by a whitelist.
Strong disagree. I want absolutely control over what tools my agent can access on my computer.
Re: MCP vs. API Explained
#97It's much simpler: MCP allows tools to be added at runtime instead of design-time. That's it. And because this can happen at runtime, the user (NOT the developer) can add arbitrary functionality to the LLM application (while the application is running — hence, runtime). One could make the argument that LLM applications with MCP support are conceptually similar to browsers — both let users connect to arbitrary MCP/HTT…
Yeah, maybe it's because I spent too much time working on another open standard (otel), but this seems pretty obvious (and much simpler -- for now). MCP standardizes how LLMs can call tools at runtime, and how tools can call LLMs at runtime. It's great!
It sounds like pushing the logic of API calling into one of the many "mcp servers", with the user still needing to go through the manual step of creating accounts on third party services, generating a bunch of different tokens, and dealing with them all.
In essence it seems like an additional shim that removes all the security of API tokens while still leaving the user to deal with them.
Side note, has Tron taught us nothing about avoiding AI MCPs?
Re: MCP vs. API Explained
#98Earlier quoted context omitted.
MCP is more like a UI that is optimized for LLMs for interacting with a tool or data source. I'd argue that an API is not a user interface and that's not really their intention. > Regardless, again: if the AI is so smart, and it somehow needs something akin to MCP as input (which seems silly), then we can use the AI to take, as input, the human readable documentation -- which is what we claim these AIs can read and u…
> I'd argue that an API is not a user interface and that's not really their intention. API is a user interface for other developers – just like MCP is a UI for LLMs.
The U in UI is User, and refers to the human. If something is Interfacing with an Application, and that something is another Application instead of a human, that means the interaction is happening via an Application Interface (to make things easier, we'll call it an AI for short...just kidding).
That seems to be what happens here with MCP: it is a way for an Application (the LLM) to derive programming by Interfacing with another Application (the 3rd party API provider, for example).
That would make MCP an API for accessing other APIs. Not that that's bad, computers are layers of abstraction all the way down. At the same time though, we already have some of those. Perhaps some sort of OpenAPI bridge would be useful in the same manner and not require rewriting API specs, but that probably exists, too.
Who am I kidding, though? The AI assistants/agents are going to be writing whatever manifests are necessary to run more AI, so it'll be a negligible increase in effort to do both.
Re: MCP vs. API Explained
#99It's much simpler: MCP allows tools to be added at runtime instead of design-time. That's it. And because this can happen at runtime, the user (NOT the developer) can add arbitrary functionality to the LLM application (while the application is running — hence, runtime). One could make the argument that LLM applications with MCP support are conceptually similar to browsers — both let users connect to arbitrary MCP/HTT…
What does it actually offer over OpenAPI though? If I feed an openapi spec to an LLM it can use it as a tool
Re: MCP vs. API Explained
#100Earlier quoted context omitted.
Yeah, maybe it's because I spent too much time working on another open standard (otel), but this seems pretty obvious (and much simpler -- for now). MCP standardizes how LLMs can call tools at runtime, and how tools can call LLMs at runtime. It's great!
It sounds like pushing the logic of API calling into one of the many "mcp servers", with the user still needing to go through the manual step of creating accounts on third party services, generating a bunch of different tokens, and dealing with them all. In essence it seems like an additional shim that removes all the security of API tokens while still leaving the user to deal with them. Side note, has Tron taught us…
Yes, although this is not a consumer play. This is an enterprise play. At my workplace, I'm already signed in to my document portal, debugging tools, slack, and other tools for my work through Okta SSO. I imagine some future agent I use to sift through various things will have similar access privileges.