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.
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?
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.
It seems like you're describing a scenario where you know at design-time which tools will be included. In that case the benefit of using MCP is less clear.
While you usually get tools that work out of the box with MCP (and thus avoid the hassle of prompting + testing to get working tool code), integrating external APIs manually often results in higher accuracy and performance, as you're not limited by the abstractions imposed by MCP.
Also, btw, how long until people rediscover HATEOAS, something which inherently relies on a generalised artificial intelligence to be useful in the first place?
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.
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.
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?
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...
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.
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.
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.
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.
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.
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.
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?
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.
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.
{"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.
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.'
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.
> 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
My point is, the applications have been (until recently) predominantly written by humans. API is the interface developers use through the code they write. Just like a UI can be better or worse, so can API: it might be concise, expressive, consistent – or verbose, clunky and completely unpredictable. Just like in UI you don’t want to click through dozens of submenus, in API you don’t want to make a dozen of calls to do something simple. It’s way more similar than you think!
Now where MCP fits in here is a whole other question...
I am not even the person who said "I wouldn't call it another form of API"... can you maybe just stick to the concrete and explain how this is different from SOAP/WSDL or OpenAPI/Swaggar? I honestly don't even know what short term either I or you would now use for any of them, but I feel confident that the overall premise described by this article doesn't differentiate: they offer a standardized connector to various tools and data sources behind otherwise different APIs, even offering--through a registry such as UDDI--dynamic discovery of these resources. The only not-really-a-difference I feel is that we are explicitly describing wrapping the other APIs into this protocol... but like, that's what you'd of course have to do or expose an existing API via SOAP (which is also a capital-P-stands-for-Protocol).
Yup. Though it's a JSON API and not an XML API like SOAP. As for how it differs form the old OpenAPI/Swaggar... shrug... not much... its got a lot less flexibility to it and it has specific tooling for agentic tool use.
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
> 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.
It doesn’t negate my point; the technology can’t self reason any API specification, and if it could this wouldn’t be needed because while humans benefit from this simplification why would a machine that can think 10000x faster than a human can?
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.
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.
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.
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.
I'd like to recommend another protocol—ANP (AgentNetworkProtocol).
While similar to MCP, ANP is significantly different. ANP is specifically designed for agents, addressing communication issues encountered by intelligent agents. It enables identity authentication and collaboration between any two agents.
Key differences include:
ANP uses a P2P architecture, whereas MCP follows a client-server model.
ANP relies on W3C DID for decentralized identity authentication, while MCP utilizes OAuth.
ANP organizes information using Semantic Web and Linked Data principles, whereas MCP employs JSON-RPC.
MCP might excel at providing additional information and tools to models and connecting models to the existing web. In contrast, ANP is particularly effective for collaboration and communication between agents.
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.
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".
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.
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”.
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.
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?
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.
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.
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?
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?
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?
> This is very naive. How many different APIs have you authenticated with and connected to? Just the big ones?
I mean, a lot? I have multiple times felt like that was my entire life for weeks or months on end during the past over three decades of doing software development...
(If we expand the scope a bit to network protocols, as opposed to just "APIs", I was even the person who first spiked nmap's protocol scanning and detection logic.)
To wit, I am one of those people who pretty much never use an SDK provided for an API: if I have to, I will rather reverse engineer the protocol using a disassembler.
(This then being part of why I've won millions of dollars in bug bounties, as part of my relentless drive to always operate at the lowest level presented to me.)
But, regardless, can we move past trying to attack my credibility on software, and shift back to more productive forms of analysis? (Why did this become so personal?!)
> What happens when the docs are wrong or incomplete?
If we posit that the documentation for the API is wrong, so we should this MCP description / wrapper, as both were written by the humans charged to enable this function.
And, of course, the real point is whether the task is easier than the thing we are trying to do... even writing a correct tree map is much harder than an API client.
^ Both of these arguments can be made by someone who doesn't even do software development, helping us try to understand why MCP is being hyped up as a new paradigm.
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?
I don't understand your response as it feels like it is also my point, and something I would say to you? :( If the LLM cannot do basic tasks such as this, what are you going to do? Keep throwing more "tools" at it and hope to start building stuff on top of it? People are trying to get these things to do complex multi-step reasoning tasks, including making changes to their codebase (?!), automating behaviors as "agents" that need to predictably and secure function... but, somehow, as part of the same explanation, it can't even translate API documentation, one of the most trivial code tasks a human does? There are reports that OpenAI is planning to sell "mid-tier agents for software development costing possibly $10,000 a month" (to quote The Information)... and yet, here we are, claiming it isn't up to writing API boilerplate? Help me make this make sense :(.
> Keep throwing more "tools" at it and hope to start building stuff on top of it
Yes and it's working? People ARE CURRENTLY building things.
They are NOT currently whinning that LLM is not smart enough so they must sit and wait for the next model to be able to code any problem, (again RELIABLY) on demand.
> People are trying to get these things to do complex multi-step reasoning tasks, including making changes to their codebase (?!), automating behaviors as "agents" that need to predictably and secure function...
You understand that all these are powered by tools calling underneath? The planning and orchestration of tasks follows a structure, to be fed into tools. This is why a plain model cannot do shit, people have to make products with the right tools on top to make a llm behave the way they want, and not just chit chat endlessly.
The abitrary execution approach, if it ever works, is by building tools and MCP servers for code execution. Because obviously it's not the LLM server who executes code.
You clearly have never thought about how to actually build any of these things.
> ...writing API boilerplate
Tool/function calling can be anything, it's you who decided that you can only use it for API boilerplate. Does the word "function" always mean boilerplate in progranming?
I feel like you are being overly hostile and you and saurik are both arguing the same point... maybe? Following this thread has not been easy, not sure which positions each of you are even defending.
I honestly clearly don't understand the downstream disagreement myself, am getting tired of being shouted at today, and feel like entering this part of the thread by replying to someone who was clearly already past their breaking point to defend what they had already claimed was an "idiotic take that many people seem to have", was a mistake ;P.
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.
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.
If the goal is to build AI agents, I’d think the maximum utility from them would come from building agents that can use the UI that humans use. Or at the very least, the lesser available API. MCP is yet another interface to services when there’s already at least two out there available to use
One thing I like about MCP's decision _not_ to just use HTTP APIs is that it makes it possible to build and distribute tools that people can use without having to set up a server for them. This goes a long way for enabling open-source and locally-running tools.
I built https://skeet.build where anyone can try out mcp for cursor and dev tools without a lot of setup
Mostly for workflows I like:
- start a PR with a summary of what I just did
- slack or comment to linear/Jira with a summary of what I pushed
- pull this issue from sentry and fix it - pull this linear issue and do a first pass
- pull in this Notion doc with a PRD then create an API reference for it based on this codebase, then create a new Notion page with the reference
MCP tools are what the LLM uses and initiates
MCP prompts are user initated workflows
MCP resources is the data that the APIs provide and structure of that data (because porting APIs to MCPs are not as straight forward)
Anyways please give me feedback!
So there’s a lot of noise about MCP but it’s just a tool - we found that we’re solving for developer workflows (where there’s pain). People want to get shit done but after coding to update JIRA tickets just kills momentum.
We just make it a highly reliable, easy to use, after committing - add a comment with a summary to that Jira/linear issue. Start a PR in GitHub and assign x, update the slack channel with an update.
In order to get this it wasn’t about porting APIs to mcp. It was thoughtfully designing and optimizing for these workflows. Also quality and polish where the calls are highly reliable - required lower level networking optimizations, sessions, etc to make to work smoothly.
But yes, also part of the frictionless experience was, just oauth.
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).
I don't really get how MCP is materially different from a standardized API interface. It will be interesting to see if the other big model providers decide to standardize on MCP or push their own competing standards.
It seems like MCP is a pretty cool protocol, but has anyone seen any actually useful integrations?
I've played a lot with the FileSystem MCP server but couldn't get it to do something useful that I can't already do faster on my own. For instance, asking it how many files have word "main" in it. It returns 267, but in reality there are 12k.
Looks promising, but I am still looking for useful ways to integrate it into my workflow.
In Cursor for example, it gives the agent the ability to connect to the browser to gather console logs, network logs and take screenshots. The agent will often invoke the tools automatically when it is debugging or verifying it's work, without being explicitly prompted to do so.
It's a little bit of a set up process, as it requires a browser extension on top of the MCP configuration.
So, now when Roo Code does tasks for me, it takes notes and searches memory.
It’s good as a means to get a quick POC running, for dev oriented use cases.
I have seen very few implementations that use anything but the tools capabilities though.
The complete lack of auth consideration and the weird orchestration (really the “client” manages its own “server” processes), make me doubt it’s going to get serious adoption in prod. It’s not something I’d have a lot of confidence in supporting for non dev users.
Most LLMs including Claude struggle using the @modelcontextprotocol/server-filesystem server - it's way too complex (and tools like Goose wrap ripgrep in an MCP to handle it). A simple MCP Server with the SDKs can easily be less than 20 lines of code and be useful.
I wrote mcp-hfspace to let you connect to Hugging Face Spaces; that opens up a lot of image generation, vision, audio transcription and other services that can be integrated quickly and easily in to your Host app.
i use it to give claude internet access. it's pretty helpful! i run searxng locally, and have an mcp server that calls it. repo: https://github.com/aeon-seraph/searxng-mcp
So how does MCP differ from a regular library like aisuite or vercel ai sdk?
Regular SDK lib:
- Integration Effort: just like MCP
- Real-Time Communication - Sure
- Dynamic Discovery - obviously. just call refresh or whatever
- Scalability - infinite, it is a library
- Security & Control - just like mcp
I suspect that an MCP is just a rebranded API. We have also seen these sorts of extensibility mechanisms before. Browser extensions, Object Linking and Embedding, Dynamic Data Exchange, and Visual Studio Code extensions are all examples of having a standard API which allows lots of different things to plug into it.
Beyond the developer, the user massively benefits from MCP. Like you said, using any other SDK to build is a very valid approach but then you are tied down to a single client that you have built on that SDK.
If you would like to switch clients, then you have build it yourself. MCP solves this very well since, any MCP supported client can use the same tools/resources that you have built.
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
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?
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.
What does it actually offer over OpenAPI though? If I feed an openapi spec to an LLM it can use it as a tool
It seems like you're describing a scenario where you know at design-time which tools will be included. In that case the benefit of using MCP is less clear.
While you usually get tools that work out of the box with MCP (and thus avoid the hassle of prompting + testing to get working tool code), integrating external APIs manually often results in higher accuracy and performance, as you're not limited by the abstractions imposed by MCP.
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?
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
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.
Thanks again for the thorough response.
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?
https://i-love-slop.com/
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.
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.
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.
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.
I was correcting this: "MCP is, realistically speaking, the extension API for Claude Desktop and Cursor".
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.
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.
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.
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?
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.
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).
https://www.openapis.org/
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.
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.
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.'
> 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.
> 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
My point is, the applications have been (until recently) predominantly written by humans. API is the interface developers use through the code they write. Just like a UI can be better or worse, so can API: it might be concise, expressive, consistent – or verbose, clunky and completely unpredictable. Just like in UI you don’t want to click through dozens of submenus, in API you don’t want to make a dozen of calls to do something simple. It’s way more similar than you think!
Now where MCP fits in here is a whole other question...
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.
I am not even the person who said "I wouldn't call it another form of API"... can you maybe just stick to the concrete and explain how this is different from SOAP/WSDL or OpenAPI/Swaggar? I honestly don't even know what short term either I or you would now use for any of them, but I feel confident that the overall premise described by this article doesn't differentiate: they offer a standardized connector to various tools and data sources behind otherwise different APIs, even offering--through a registry such as UDDI--dynamic discovery of these resources. The only not-really-a-difference I feel is that we are explicitly describing wrapping the other APIs into this protocol... but like, that's what you'd of course have to do or expose an existing API via SOAP (which is also a capital-P-stands-for-Protocol).
Yup. Though it's a JSON API and not an XML API like SOAP. As for how it differs form the old OpenAPI/Swaggar... shrug... not much... its got a lot less flexibility to it and it has specific tooling for agentic tool use.
https://github.com/modelcontextprotocol/specification/blob/m...
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
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
> 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.
It doesn’t negate my point; the technology can’t self reason any API specification, and if it could this wouldn’t be needed because while humans benefit from this simplification why would a machine that can think 10000x faster than a human can?
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.
Exactly Any junior developer can reason about API and integrate
But LLm will replace them?
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.
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.
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.
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!
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!
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.
I'd like to recommend another protocol—ANP (AgentNetworkProtocol).
While similar to MCP, ANP is significantly different. ANP is specifically designed for agents, addressing communication issues encountered by intelligent agents. It enables identity authentication and collaboration between any two agents.
Key differences include:
ANP uses a P2P architecture, whereas MCP follows a client-server model. ANP relies on W3C DID for decentralized identity authentication, while MCP utilizes OAuth. ANP organizes information using Semantic Web and Linked Data principles, whereas MCP employs JSON-RPC. MCP might excel at providing additional information and tools to models and connecting models to the existing web. In contrast, ANP is particularly effective for collaboration and communication between agents.
Here is a detailed comparison of ANP and MCP (including the GitHub repository): https://github.com/agent-network-protocol/AgentNetworkProtoc...
The article has the same usb-c photo three times, but doesn't actually explain what it is, or how it works.
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.
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.
unfortunately it is indistinguishable from what a reasonable human high on mcp copium might write
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.
Author here – fair point! I can def see how it could've used more explanation. I'll update the post - appreciate the heads-up!
How many R's are in "strawberry"? ;)
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.
MCP is not that hard to understand why does it keep getting the wackiest comparison?
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”.
Stop calling HTML hypertext, it has been unstructured content for as long as I write code.
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.
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?
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?
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?
Personally, I’ve found the SDKs worse in almost all cases.
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.
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?
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?
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?
> This is very naive. How many different APIs have you authenticated with and connected to? Just the big ones?
I mean, a lot? I have multiple times felt like that was my entire life for weeks or months on end during the past over three decades of doing software development...
(If we expand the scope a bit to network protocols, as opposed to just "APIs", I was even the person who first spiked nmap's protocol scanning and detection logic.)
To wit, I am one of those people who pretty much never use an SDK provided for an API: if I have to, I will rather reverse engineer the protocol using a disassembler.
(This then being part of why I've won millions of dollars in bug bounties, as part of my relentless drive to always operate at the lowest level presented to me.)
But, regardless, can we move past trying to attack my credibility on software, and shift back to more productive forms of analysis? (Why did this become so personal?!)
> What happens when the docs are wrong or incomplete?
If we posit that the documentation for the API is wrong, so we should this MCP description / wrapper, as both were written by the humans charged to enable this function.
And, of course, the real point is whether the task is easier than the thing we are trying to do... even writing a correct tree map is much harder than an API client.
^ Both of these arguments can be made by someone who doesn't even do software development, helping us try to understand why MCP is being hyped up as a new paradigm.
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?
I don't understand your response as it feels like it is also my point, and something I would say to you? :( If the LLM cannot do basic tasks such as this, what are you going to do? Keep throwing more "tools" at it and hope to start building stuff on top of it? People are trying to get these things to do complex multi-step reasoning tasks, including making changes to their codebase (?!), automating behaviors as "agents" that need to predictably and secure function... but, somehow, as part of the same explanation, it can't even translate API documentation, one of the most trivial code tasks a human does? There are reports that OpenAI is planning to sell "mid-tier agents for software development costing possibly $10,000 a month" (to quote The Information)... and yet, here we are, claiming it isn't up to writing API boilerplate? Help me make this make sense :(.
How does the model retrieve documentation? Through an MCP server?
> Keep throwing more "tools" at it and hope to start building stuff on top of it
Yes and it's working? People ARE CURRENTLY building things.
They are NOT currently whinning that LLM is not smart enough so they must sit and wait for the next model to be able to code any problem, (again RELIABLY) on demand.
> People are trying to get these things to do complex multi-step reasoning tasks, including making changes to their codebase (?!), automating behaviors as "agents" that need to predictably and secure function...
You understand that all these are powered by tools calling underneath? The planning and orchestration of tasks follows a structure, to be fed into tools. This is why a plain model cannot do shit, people have to make products with the right tools on top to make a llm behave the way they want, and not just chit chat endlessly.
The abitrary execution approach, if it ever works, is by building tools and MCP servers for code execution. Because obviously it's not the LLM server who executes code.
You clearly have never thought about how to actually build any of these things.
> ...writing API boilerplate
Tool/function calling can be anything, it's you who decided that you can only use it for API boilerplate. Does the word "function" always mean boilerplate in progranming?
I feel like you are being overly hostile and you and saurik are both arguing the same point... maybe? Following this thread has not been easy, not sure which positions each of you are even defending.
I honestly clearly don't understand the downstream disagreement myself, am getting tired of being shouted at today, and feel like entering this part of the thread by replying to someone who was clearly already past their breaking point to defend what they had already claimed was an "idiotic take that many people seem to have", was a mistake ;P.
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.
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.
If the goal is to build AI agents, I’d think the maximum utility from them would come from building agents that can use the UI that humans use. Or at the very least, the lesser available API. MCP is yet another interface to services when there’s already at least two out there available to use
One thing I like about MCP's decision _not_ to just use HTTP APIs is that it makes it possible to build and distribute tools that people can use without having to set up a server for them. This goes a long way for enabling open-source and locally-running tools.
I built https://skeet.build where anyone can try out mcp for cursor and dev tools without a lot of setup Mostly for workflows I like: - start a PR with a summary of what I just did
- slack or comment to linear/Jira with a summary of what I pushed
- pull this issue from sentry and fix it - pull this linear issue and do a first pass
- pull in this Notion doc with a PRD then create an API reference for it based on this codebase, then create a new Notion page with the reference
MCP tools are what the LLM uses and initiates
MCP prompts are user initated workflows
MCP resources is the data that the APIs provide and structure of that data (because porting APIs to MCPs are not as straight forward) Anyways please give me feedback!
What is unique about your solution? Are you essentially handling auth tokens for the user to interface MCPs with external APIs?
So there’s a lot of noise about MCP but it’s just a tool - we found that we’re solving for developer workflows (where there’s pain). People want to get shit done but after coding to update JIRA tickets just kills momentum.
We just make it a highly reliable, easy to use, after committing - add a comment with a summary to that Jira/linear issue. Start a PR in GitHub and assign x, update the slack channel with an update.
In order to get this it wasn’t about porting APIs to mcp. It was thoughtfully designing and optimizing for these workflows. Also quality and polish where the calls are highly reliable - required lower level networking optimizations, sessions, etc to make to work smoothly.
But yes, also part of the frictionless experience was, just oauth.
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).
Here's the spec: https://spec.modelcontextprotocol.io/specification/2024-11-0...
A sample MCP example with data would be helpful.
Author here - yeah that makes sense. A real example would def make it clearer - I'll add one. Thanks for the suggestion!
I don't really get how MCP is materially different from a standardized API interface. It will be interesting to see if the other big model providers decide to standardize on MCP or push their own competing standards.
Every API is different/custom whereas MCP is supposed to be universal. Is that it?
Ok but why would every app and website implement this new protocol for the benefit of LLMs/agents?
Ironic this post is written in repetitive SEO spam format.
> MCP allows AI models to dynamically discover and interact with available tools without hard-coded knowledge of each integration
Did they just now discover abstract base classes?
shameless plug: we're building a registry and tooling for multi-platform MCP-based tools check it out https://www.mcp.run/
So it's yet another one API to rule them all?
The only thing that idea ever lead to was more (complicated) APIs.
I missed an update. How did MCPs come into this world?
https://x.com/bibryam/status/1892332097999626634/photo/1
It seems like MCP is a pretty cool protocol, but has anyone seen any actually useful integrations?
I've played a lot with the FileSystem MCP server but couldn't get it to do something useful that I can't already do faster on my own. For instance, asking it how many files have word "main" in it. It returns 267, but in reality there are 12k.
Looks promising, but I am still looking for useful ways to integrate it into my workflow.
I've found BrowserTools MCP useful in my development workflow: https://browsertools.agentdesk.ai/installation
In Cursor for example, it gives the agent the ability to connect to the browser to gather console logs, network logs and take screenshots. The agent will often invoke the tools automatically when it is debugging or verifying it's work, without being explicitly prompted to do so.
It's a little bit of a set up process, as it requires a browser extension on top of the MCP configuration.
I’ve used it to connect my open source memory application to Roo Code: https://github.com/elroy-bot/elroy
So, now when Roo Code does tasks for me, it takes notes and searches memory.
It’s good as a means to get a quick POC running, for dev oriented use cases.
I have seen very few implementations that use anything but the tools capabilities though.
The complete lack of auth consideration and the weird orchestration (really the “client” manages its own “server” processes), make me doubt it’s going to get serious adoption in prod. It’s not something I’d have a lot of confidence in supporting for non dev users.
Most LLMs including Claude struggle using the @modelcontextprotocol/server-filesystem server - it's way too complex (and tools like Goose wrap ripgrep in an MCP to handle it). A simple MCP Server with the SDKs can easily be less than 20 lines of code and be useful.
I wrote mcp-hfspace to let you connect to Hugging Face Spaces; that opens up a lot of image generation, vision, audio transcription and other services that can be integrated quickly and easily in to your Host app.
i use it to give claude internet access. it's pretty helpful! i run searxng locally, and have an mcp server that calls it. repo: https://github.com/aeon-seraph/searxng-mcp
So far I have not found anything useful.
https://x.com/thdxr/status/1897369381195092197
So how does MCP differ from a regular library like aisuite or vercel ai sdk?
Regular SDK lib: - Integration Effort: just like MCP - Real-Time Communication - Sure - Dynamic Discovery - obviously. just call refresh or whatever - Scalability - infinite, it is a library - Security & Control - just like mcp
i trully don't get it
I suspect that an MCP is just a rebranded API. We have also seen these sorts of extensibility mechanisms before. Browser extensions, Object Linking and Embedding, Dynamic Data Exchange, and Visual Studio Code extensions are all examples of having a standard API which allows lots of different things to plug into it.
Beyond the developer, the user massively benefits from MCP. Like you said, using any other SDK to build is a very valid approach but then you are tied down to a single client that you have built on that SDK.
If you would like to switch clients, then you have build it yourself. MCP solves this very well since, any MCP supported client can use the same tools/resources that you have built.
Erlang
Do you mind elaborating?