MCP vs. API Explained
91 comments
·March 8, 2025ondrsh
phillipcarter
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!
imtringued
The spec and server docs also contain a helpful explanation:
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
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 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
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?
campbel
The most important thing for developers to understand when it comes to MCP: MCP is a protocol for dynamically loading additional capabilities into an AI application, e.g. Claude Desktop, Cursor, Highlight.ai etc...
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
I saw you were downvoted and could not understand why, so I'm both upvoting and replying. This is all correct. MCP is, realistically speaking, the extension API for Claude Desktop and Cursor. It's really cool if you do want to extend those apps, but that's all it's for. The article in this case is really confusing and unnecessary.
westoncb
This is mistaken. It was effectively true until recently but all kinds of people are building things with it now. This article is likely on HN today because there has been a surge of general interest lately. Here's another example: https://github.com/block/goose. MCP servers are a bit heavyweight but most common case is probably using those developed and/or hosted by others. Clients (e.g. Cursor, Claude Desktop) on the other hand will likely be widespread before long.
electroly
My involvement level here is "I'm deep into the implementation and use of my own MCP server," I very much already knew about Goose. I don't think OP or I made our point clear here if you're seeing Goose as a counterargument. Goose is just another MCP client like Cursor and Claude Desktop and MCP is, indeed, its extension API. As OP said, if you are writing your own app that interacts directly with a model API, rather than using a generic app that specifically offers AI agent capability with an extension API, then you'll need to use the model's function calling capability directly. MCP is a very thin layer on top specifically for these agent apps.
gsibble
Absolutely correct. You can also use tools everywhere while clients have to be MCP compatible.
MCP is not all it's cracked up to be.
nsonha
It's crack up to be because tools need to be hard-coded. MCP is not.
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
Nobody says that your tools declaration must be hardcoded – you can resolve them at runtime. MCP simply describes convention on how to do it. The benefit is that you can write your own provider this way and if you follow this convention anybody can use it easily similarly to how people can use published packages (npm, python package etc.) that follow their publish/consume conventions.
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
1) Ok, so you are reinventing SOAP or WSDL or whatever... did that ever go well? How and why is this different from every prior attempt to create the one true API layer?
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
MCP tends to be much simpler, less powerful than an API that you’d actually try to develop against. The LLMs need the most simplified access patterns possible
fulafel
Most people hate SOAP and WSDL. You can argue most web APIs are reinventing them in the sense that you could reimplement them with WSDL, to get worse versions of them.
muzani
I wouldn't call it another form of API. It's more like an SDK. If you were accessing a REST API from Android, iOS, Windows, Mac, Firefox, they'd be mostly the same. But an SDK for Android and an SDK for iOS has been built for the platform. Often the SDK encapsulates the official API.
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
I didn't have a good term so I went with "API layer" (not merely "API"), but, to try to clarify... that's what you also get with SOAP/WSDL or any of the other numerous attempts over the years to build an API "layer" thing: you can use the one universal SDK you have, plus only the schema / IDL, to use the API. Every time people try to describe MCP it just sounds like yet another API description language when we already have a giant drawer of those that never really worked out, including OpenA"P"I (lol ;P).
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
Why not JSON/XML?
{"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
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 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.'
outofpaper
No, an API is the closest term, as calling MCP, which is a simple protocol, an SDK is literally wrong.
A protocol is not a software development kit.
null
no_wizard
Question three is what hits the nail on the head about how this “AI revolution” isn’t as robust as often claimed.
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
> If it was truly intelligent it could reason about things like API specifications without any precursors or shared structure, but it can’t
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
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!
immibis
Then it's a useless concept, because people who use LLMs don't want to be bounded by a whitelist.
zombiwoof
Exactly Any junior developer can reason about API and integrate
But LLm will replace them?
nsonha
1) Valid point, this could haven been wsdl/swagger. But the MCP spec supports spinning up local applications and communicate via stdio which open api cannot do.
2 + 3) having a few commands that AI knows it should call and confidently so without security concern, is better than just give AI permision to do every thing under the sun and tell it to code a program doing so.
The prompt for the later is also much more complex and does not work as predictably.
redm
What the article doesn't say (well, there's a lot it doesn't say) is that this protocol was created by Anthropic but is being adopted more widely.
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
Yes. The article comes across as a response from an LLM chat. I think that it's OK to write blog posts with AI assistance, and I like the logical and simple writing style that these models output.
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
Author here, good point! I should have mentioned that MCP was created by Anthropic but is seeing wider adoption.
Appreciate the feedback - brb I'll update the post to include this!
whazor
The MCP protocol is very similar to Language Server Protocol (LSP) in design. LSP has the same requests, responses, and notifications setup. Also the initialization with what capabilities the server has it the same.
Normally, LSP when running on a remote server, you would use a continuous (web)socket instead of API requests. This helps with the parsing overhead and provides faster response for small requests. Also requests have cancellation tokens, which makes it possible to cancel a request when it became unnecessary.
chrislloyd
MCP strikes me as roughly equivalent to HTML. Headline features like dynamic “tool” discovery (and more!) are solved well with HTML.
MCP is probably easier for clients to implement but suffers from poor standardization, immaturity and non-human readability. It clearly scratches an itch but I think it’s a local-minimum that requires a tremendous amount of work to implement.
nsonha
MCP is not that hard to understand why does it keep getting the wackiest comparison?
chrislloyd
MCPs goal is to standardize the transfer of application context and tool definitions to a client (let’s ignore prompts for the moment). That’s the same goal as Hypertext. In HTML, context is <p>, <img/> etc. and “tools” are <form>, <a> and <button>s. Instead of separating the two (like in MCP) - it’s all included in the same document.
I’ve used MCP quite a bit but perhaps I’m misunderstanding something? Happy to hear why you think it’s “wacky”.
nsonha
Stop calling HTML hypertext, it has been unstructured content for as long as I write code.
rsp1984
To be honest I don't understand why this is needed. All the leading AI models can already write code that interfaces perfectly with well-known APIs, and for the niche-APIs I can supply the docs of that API and the model will understand.
So all that's needed are API docs. Or what am I missing?
frabjoused
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.
nostrebored
Wouldn’t you just do that with an SDK? Why the extra layer of complexity with MCP?
frabjoused
Not all http based APIs have an SDK. It’s wildly inconsistent. And when you ask the llm to do something new, does it download the SDK on the fly?
muzani
Writing code for interfaces is an extra "cognitive layer" for the AI, just like it would be for a human.
Let's say you want to add or delete Jira tickets. A MCP is like a big labeled button for the AI to do this, and it doesn't come with the token cost of reading an API or the possibility of making a mistake while accessing it.
nsonha
Sorry but I'm extremelly annoyed with this idiotic take that many people seem to have. Is it that easy to prompt AI to write code and call an API predictably?
saurik
This is like the simplest task you can give a software developer, as it is nigh-unto merely a document "translation" task, without much real thought required. If an LLM is failing to do this task, why do we hope whatever chain of reasoning it is about to embark on would work?
frabjoused
This is very naive. How many different APIs have you authenticated with and connected to? Just the big ones? What happens when the docs are wrong or incomplete?
nsonha
https://news.ycombinator.com/item?id=43304457
Also > ...if an LLM is failing to do this task...
It CURRENTLY fails to do so, PREDITABLY and securely. What are you gonna do about that? Keep throwing more data into it and hope to start building stuff on top, one day?
dinkumthinkum
I am somewhat shocked by the level of incredulity people are having in this thread toward having an alternative to traditional APIs for use with LLMs. It is a lot of the same "If the AI is incapable of <blah blah> then why would anyone use it?". I guess I don't see what the big deal is in having a more robust standard for interfacing with a system such as LLMs. Do they fear the engineering effort is orders of magnitude? I mean really, I think it is more of an anti-AI or anti-LLM sort of sentiment, which, frankly, I am quite sympathetic to, but this is sort a bad argument or position to have.
1116574
The article has the same usb-c photo three times, but doesn't actually explain what it is, or how it works.
SamBam
Not only that, but the whole section on "Consider these scenarios" simply described the same thing as an API each time, but added words like "smoothly" and "richer" to make it sound different.
I honestly think most of the article was written by an LLM.
crabmusket
The structure seems very LLM-ish. And the details are blurry:
> Two-way communication: MCP supports persistent, real-time two-way communication - similar to WebSockets. The AI model can both retrieve information and trigger actions dynamically".
This is not what two-way communication means.
swyx
unfortunately it is indistinguishable from what a reasonable human high on mcp copium might write
doug_durham
The usb-c metaphor along with most of the text are lifted from the Anthropic documentation without attribution. I'm not impressed with the author.
punkpeye
Random: I tried posting this as ShowHN, but I am guessing I don't have enough reputation, because it was hidden.
So if you are here for MCP, I will use the opportunity to share what I've been working on the last few months.
I've hand curated hundreds of MCP servers, which people can access and browse via https://glama.ai/mcp/servers and made those servers available via API https://glama.ai/mcp/reference
The API allows to search for MCP servers, identify their capabilities via API attributes, and even access user hosted MCP servers.
However, you can also try these servers using an inspector (available under every server) and also in the chat (https://glama.ai/chat)
This is all part of a bigger ambition to create an all encompassing platform for authoring, discovering and hosting MCP servers.
I am also the author of https://github.com/punkpeye/fastmcp framework and several other supporting open-source tools, like https://github.com/punkpeye/mcp-proxy
If you are also interested in MCP and want to chat about the future of this technology, drop me a message.
smallnix
So it's an indirection layer to the actual APIs.
The value of MCP then depends on it's adoption. If I need to write an MCP adapter for everything, it's value is little. If everyone (API owners, OS, Clouds, ...) puts in the work to have an MCP compatible interface it's valuable.
In a world where I need to build my own X-to-USB dongle for every device myself, I wouldn't use USB, to stay with the articles analogy.
mirekrusin
Tangential but it's a shame people are often missing the opportunity to align jsonrpc with programming language semantics 1) name methods so they can be methods in programming langugage (no "/" in names like MCP does) 2) use arity based calling convention (no named params, use array instead because that's what your programming language does when you define functions or methods; if you want named params, just use object as first argument).
Following those two principles means your implementation ends up as simple class, with simple methods, with simple params - possibly using decorators to expose it as rpc and perform runtime type assertion for params (exposing rpc, server side) and result (using rpc, client side) – consuming jsonrpc now looks like using any ordinary library/package that happens to have async methods (this is important, there is no special dialect of communication, it's all ordinary semantics everybody is already used to, your code on client and server side doesn't jump between mapping to/from language and jsonrpc, there is a lot of complexity that's collapsed, code looks minimal, it's small, natural to read etc).
Notifications also map naturally to well established pattern (ie. event emitter in nodejs).
And yes, that's my main criticism of MCP – you're making standard for communication meant to be used from different languages, why adding this silly, unnecessary complexity by using "/" in method names? It frankly feels like amateur mistake by somebody who thinks it should be a bit like REST where method is URL path.
Another tangent – this declaration of available enpoints is unnecessarily complicated – you can just use url: file://.. scheme to start process on that executable with stdin/stdout as communication channels (this idea is great btw, good job!), ws:// or wss:// for websocket comms to existing service and http:// or https:// for jsonrpc over http (no notifications).
It'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/HTTP servers at runtime.
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