152 points by typhon04 20 hours ago | 93 comments
ondrsh 17 hours ago
But the comparison with HTTP is not a very good one, because MCP is stateful and complex. MCP is actually much more similar to FTP than it is to HTTP.
I wrote 2 short blog posts about this in case anyone is curious: https://www.ondr.sh/blog/thoughts-on-mcp
phillipcarter 13 hours ago
MCP standardizes how LLMs can call tools at runtime, and how tools can call LLMs at runtime. It's great!
imtringued 7 hours ago
https://spec.modelcontextprotocol.io/specification/2024-11-0...
https://modelcontextprotocol.io/sdk/java/mcp-server
Also, btw, how long until people rediscover HATEOAS, something which inherently relies on a generalised artificial intelligence to be useful in the first place?
ondrsh 6 hours ago
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 drop the Hypermedia from 'H'ATEOAS and use JSON instead.
I wrote about that exact thing in Part 2: https://www.ondr.sh/blog/ai-web
thierrydamiba 6 hours ago
I’m bullish on MCP-what is are some non-obvious things I shod consider that might dampen my fire?
ondrsh 5 hours ago
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.
yourapostasy 1 hour ago
campbel 17 hours ago
If you are building your own applications, you can simply use "Tools APIs" provided by the LLM directly (e,.g. https://platform.openai.com/docs/assistants/tools).
MCP is not something most people need to bother with unless you are building an application that needs extension or you are trying to extend an application (like those I listed above). Under the hood the MCP is just an interface into the tools API.
electroly 16 hours ago
westoncb 9 hours ago
electroly 8 hours ago
westoncb 8 hours ago
gsibble 17 hours ago
MCP is not all it's cracked up to be.
nsonha 16 hours ago
When computer use was demoed it seems like a big deal. However, with MCP, any one can create and MCP server and run it on their computer and hook it up to an MCP compatible client, regardless of the model.
mirekrusin 8 hours ago
Their config manifest is like package.json's dependencies.
Their init is like import resolution.
Jsonrpc methods are like exported functions in package.
Json schema declarations are like type declarations (ie. .d.ts) files.
In your config manifest you specify "imports" that llm can use and it handles populating tools - it's like npm for llm sessions.
saurik 17 hours ago
2) Is this meaningfully different from just having every API provide a JavaScript SDK to access it, and then having the model write code? That's how humans solve this stuff.
3) If the AI is actually as smart at doing tasks like writing clients for APIs as people like to claim, why does it need this to be made machine readable in the first place?
jes5199 11 hours ago
muzani 16 hours ago
That's a direct answer for (2) too - instead of writing a JS SDK or Swift SDK or whatever, it's an AI SDK and shared across Claude, OpenAI, Groq, and so on.
(3) is exactly related to this. The AI has been trained to run MCPs, viewing them as big labeled buttons in their "mind".
I think you got the questions spot on and the answers right there as well.
saurik 16 hours ago
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 understand -- and just have it output something akin to MCP. The entire point of having an AI agent is that it is able to do things similar to a software developer, and interfacing with a random API is probably the most trivial task you can possible do.
muzani 12 hours ago
{"action": "create_directory", "value": "foobar/assets/"} is 15 tokens whereas create_directory("foobar/assets/") is 7 tokens. It's not the exact format, but you get the idea.
It's not just about cost, higher tokens also result in lower performance. It's as hard for the LLM to read this as it is for you to read it.
I did some experiments with protocols last year. YAML was the most efficient one by a large margin, and yet it often made mistakes. Half the output layer code is dedicated to fixing common mistakes in formatting, like when it forgets to put in a dash or merges one parameter with another. We had 2/3 of the input prompt dedicated to explaining the spec and giving examples. It's definitely not trivial.
MCP is pre-trained into the models, no need for all this.
The work we had it on did not need a good model. We had to use a more expensive model and most open source/self-trained ones didn't do the trick. We ended up taking a 3x more expensive model. Also don't look at it as LLMs being smart enough to do it; we also want something for the dumb & cheap micro LLMs as well, and micro LLMs will likely be doing agentic work.
It's also as likely to make mistakes as a human - LLMs didn't output JSON until mid 2024. Gemini was one of the first to officially feature JSON output and it was still randomly breaking by Sept 2024 with JSON arrays, even when giving the API a properly detailed spec to respond in.
They can improve it, but they have to train it on something and they might as well make something up that's more efficient. OpenAI might do one too. Even with images we see newer protocols like HEIC, WEBP when PNG works fine. I expect MCP will live because it's particularly suited to this use case.
myownpetard 10 hours ago
> 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 understand -- and just have it output something akin to MCP.
This example is like telling someone who just wants to check their email to build an IMAP client. It's an unnecessary and expensive distraction from whatever goal they are actually trying to accomplish.
As others have said, models are now being trained on MCP interactions. It's analogous to having shared UI/UX patterns across different webapps. The result is we humans don't have to think as hard to understand how to use a new tool because of the familiar visual and interaction patterns. As the design book title says, 'don't make me think.'
notpushkin 7 hours ago
API is a user interface for other developers – just like MCP is a UI for LLMs.
outofpaper 16 hours ago
A protocol is not a software development kit.
saurik 12 hours ago
outofpaper 6 hours ago
https://github.com/modelcontextprotocol/specification/blob/m...
no_wizard 17 hours ago
If it was truly intelligent it could reason about things like API specifications without any precursors or shared structure, but it can’t.
Are LLMs powerful? Yes. Is current “AI” simply a re-brand of machine learning? IMO, also yes
vineyardmike 9 hours ago
I can reason about any API or specification. But when I'm trying to get a different, compound, and higher-level task done, its quite a bit faster and less distracting if I can rely on someone else to have already distilled what I need (into a library, cheat-sheet, tutorial, etc).
Similarly, I've seen LLMs do things like generate clients and scripts for interacting with APIs. But its a lot easier to just hand them one ready to go.
james_marks 13 hours ago
I say this out loud so someone can correct me if I’m mistaken!
immibis 13 hours ago
zombiwoof 15 hours ago
But LLm will replace them?
fulafel 7 hours ago
redm 18 hours ago
MCP reminds me of a new platform opportunity akin to the Apple App Store.
It's rapidly adopted, with offerings from GitHub, Stripe, Slack, Google Maps, AirTable, etc. Many more non-official integrations are already out there. I expect this will only gain adoption over the coming year.
fallinditch 14 hours ago
But with MCP there's not a whole lot of information out there for LLMs to digest and so perhaps for that reason the article is not particularly insightful.
Thank you HN for bringing the insights!
norsak 11 hours ago
Appreciate the feedback - brb I'll update the post to include this!