Today MCP added Streamable HTTP [0] which is a huge step forward as it doesn't require an "always-on" connection to remote HTTP servers.
However, if you look at the specification it's clear bringing the LSP-style paradigm to remote HTTP servers is adding a bunch of extra complexity. This is a tool call, for example:
Which traditionally would just be HTTP POST to `/get_weather` with `{ "location": "New York" }`.
I've made the suggestion to remove some of this complexity [1] and fall back to just a traditional HTTP server, where a session can be negotiated with an `Authorization` header and we rely on traditional endpoints / OpenAPI + JSON Schema endpoint definitions. I think it would make server construction a lot easier and web frameworks would not have to materially be updated to adhere to the spec -- perhaps just adding a single endpoint.
MCP is just too complex for what it is supposed to do. I don't get what's the benefit. It is the kind of thing that has the potential to be a huge time waste because it requires custom dev tools to develop and troubleshoot.
It is not even a protocol in the traditional sense - more of a convention.
And of course we will implement it, like everyone else, because it is gathering momentum, but I do not believe it is the right approach at all. A simpler HTTP-based OpenAPI service would have been a lot better and it is already well supported in all frameworks.
The only way I can make sense of MCP in the context of an STDIO.
The `stdio` approach for local services makes complete sense to me. Including using JSONRPC.
But for remote HTTP MCP servers there should be a dead simple solution. A couple years ago OpenAI launched plugins as `.well-known/ai-plugin.json`, where it'd contain a link to your API spec, ChatGPT could read it, and voila. So all you needed to implement was this endpoint and ChatGPT could read your whole API. It was pretty cool.
ChatGPT Plugins failed, however. I'm confident it wasn't because of the tech stack, it was due to the fact that the integration demand wasn't really there yet: companies were in the early stages of building their own LLM stacks, ChatGPT desktop didn't exist. It also wasn't marketed as a developer-first global integration solution: little to no consistent developer advocacy was done around it. It was marketed towards consumers and it was pretty unwieldy.
IMO the single-endpoint solution and adhering to existing paradigms is the simplest and most robust solution. For MCP, I'd advocate that this is what the `mcp/` endpoint should become.
Edit: Also tool calling in models circa 2023 was not nearly as good as it is now.
I agree. What OpenAI did was simple and beautiful.
Also, I think there is a fundamental misunderstanding that MCP services are plug and play. They are not. Function names and descriptions are literally prompts so it is almost certain you would need to modify the names or descriptions to add some nuances to how you want these to be called. Since MCP servers are not really meant to be extensible in that sort of way, the only other alternative is to add more context into the prompt which is not easy unless you have a tone of experience. Most of our customers fail at prompting.
The reason I like the ai-plugin.json approach is that you don't have to change the API to make the description of a function a little bit different. One day MCP might support this but it will another layer of complexities that could have been avoided with a remotely hosted JSON / YAML file.
It’s not just about passing prompts — in production systems like Ramp’s, they had to build a custom ETL pipeline to process data from their endpoints, and host a separate database to serve structured transaction data into the LLM context window effectively.
We’ve seen similar pre-processing strategies in many efficient LLM-integrated APIs — whether it’s GraphQL shaping data precisely, SQL transformations for LLM compatibility, or LLM-assisted data shaping like Exa does for Search.
PS: When building agents, prompt and context management becomes a real bottleneck. You often need to juggle dynamic prompts, tool descriptions, and task-specific data — all without blowing the context window or inducing hallucinations. MCP servers help solve this by acting as a "plug-and-play" prompt loader — dynamically fetching task-relevant prompts or tool wrappers just-in-time. This leads to more efficient tool selection, reduced prompt bloat, and better overall reasoning for agent workflows.
The good thing to note is that (AFAIK) MCP is intended to be a collaborative and industry-wide effort. Whereas plugins was OpenAI-specific.
So, hopefully, we can contribute and help direct the development! I think this dialogue is helpful and I'm hoping the creators respond via GitHub or otherwise.
It took me a minute to even understand this comment because for me the “obvious” use-case for MCP is local filesystem tasks, not web requests. Using MCP to manipulate files is my primary LLM use-case and has been ever since Anthropic released it and integrated it into Claude Desktop. I understand where you’re coming from, but I suspect that the idea here is to build something that is more “filesystem first.”
That makes sense. But if that's the case I think we should call a spade a spade and differentiate "Local-first MCP" and "Remote MCP"; because what (many, most?) companies are really trying to do is integrate with the latter.
Which is where you see this sort of feedback, where a bunch of us API engineers are like; "there's already a well-trodden path for doing all of this stuff. Can we just do that and agree that it's the standard?"
100%. I know I’m in the “get off my lawn” phase of my career when I see things like MCP and LangChain, but know I would have been excited about them earlier in my career.
LangChain is an objectively terrible Frankenstein's monster of an API. If you were a good developer in your youth, you'd have still held it in contempt, and treat MCP with caution.
The MCP API is pretty bad, too, it's just that a paradigm is starting to emege regarding modularity, integration and agentic tooling, and MCP happens to be the only real shot in that direction st this particular moment.
How is the MCP API bad? It uses simple and widely available standards-based transports while still allowing custom transport implementations, along with a simple API that can be used easily without any libraries, in any programming language under the sun?
Could you elaborate on your issues with LangChain?
We're kinda headed towards using it as it seems to be a flexible enough abstraction that is relatively stable to work with, so I'd like to know if I'm overlooking something..?
A big soup of untyped json blobs and python, all working highly asynchronously in complicated ways.
Is this variable available in my agent’s state?
Depends! Is it an agent that started an hour ago before you made that other change? Is it in the manager state or not? Did the previous agent run correctly or not? Did something else go wrong?
Eh, more the wider cultural effects of them. Vibe coding, everyone now creating kitchen sink apps that do everything under the sun, k8s everywhere, agents everywhere. It feels like a big part of the industry has lost all focus and is sprinting towards some endless vague panacea instead of focusing on solving specific well defined business problems.
It’s always been a bit like this but it feels particularly bad since AI hit mainstream coding tooling. Just my 2c :)
I tend to agree here.
Alot of the use cases are around STDIO and using MCPs within existing apps like Cursor/Windsurf etc.
Most developers want to build and integrate their own tools and the complexity required here (build out the server, bundle a client, and the additional latency) is probably not worth the ROI.
There also seems to be a notion that security is "handled" by MCP which might be premature. I mean, there are several good decisions in the standard (tls with sse, sampling etc), but critical choices around auth and scope for agents or 3rd party mcp providers are still wide open IMO.
Yeah, I had more luck with just giving an ai the openapi spec and letting it figure everything out. I like a lot about MCP (structure, tool guidance, etc), but couldn't it just have been a REST API and a webserver?
I think people often think of their specific use-case and tend to forget the bigger picture. MCP does not force one transport or the other and that is great—use any transport you want as long as it uses JSON RPC as the payload.
The two built in transports are also extremely minimalistic and for SSE transport use regular HTTP—no need for web sockets or other heavier dependencies because SSE events are lightweight and broadly supported.
Second that. A lot of our use cases are "remote tooling", i.e. calling APIs. Implementing an MCP server to wrap APIs seems very complex - both in terms of implementation and infrastructure.
We have found GraphQL to be a great "semantic" interface for API tooling definitions since GraphQL schema allows for descriptions in the spec and is very humanly readable. For "data-heavy" AI use cases, the flexibility of GraphQL is nice so you can expose different levels of "data-depth" which is very useful in controlling cost (i.e. context window) and performance of LLM apps.
In case anybody else wants to call GraphQL APIs as tools in their chatbot/agents/LLM apps, we open sourced a library for the boilerplate code:
https://github.com/DataSQRL/acorn.js
Oh wow. Amazing. I did not think of that. I am not fan of GraphQL but you might be onto something here. I have not checked the code and perhaps this is not the right channel for this but my read is that this library allows any generic GraphQL server to exposed in this sort of way?
I am actually working on such a thing, and I want to get it righr. This is like RSS or Atom or Jabber or XMPP wars. Or OpenGraph vs Twitter’s meta tags etc. I want interoperability which is cool, but I also want it to seamlessly interoperate with human roles and services.
What is the best way to connect with you? I would like to discuss ideas and protocols if you’re up for that.
"Tool calling" is just one part of MCP, there are more things like "Sampling" which allow the server itself to initiate stuff on the client. As for tool calling, having a layer like MCP makes sense because there a lot of things which don't have a REST-API + may need direct access to the computer (filesystem, processes, etc).
Examples:
* Running SQL commands on a DB or a Redis instance.
* Launching Docker containers, SSHing to a server an running some command.
* Reading a file and extracting relevant information from it, like OCR.
* Controlling a remote browser using the WebDriver protocol, have some kind of persistent connection to a backend.
As for just pure REST-API usecases, I think MCP serves what Swagger/OpenApi-Spec are meant to do, i.e. enforce some kind of format and give each endpoint a "Name" + list of Params which the LLM can invoke.
The issue is that there is no standardised way to pass these API specs to LLMs as tools (maybe something can be built in this space). In the future, I can easily see some kind of library/abstraction that allows an MCP server to parse an existing API spec file to expose those APIs as tools which can be combined with some local state on the computer to allow stateful interactions with a REST API.
I just made a tool which parses any OpenAPI spec to MCP spec: https://www.open-mcp.org (literally just deployed so I don't know if the DNS has propagated globally yet..)
Thanks, I just added support for relative URLs, try again. Your OpenAPI spec defines a relative base URL for the server /metatx but no domain. You can now specify the full base URL in your MCP client's environment variables:
I don’t disagree. I fought this battle for a long time — ran a company where I tried to simplify SDK development by making every endpoint POST and JSON params; sorta like SOAP / just simple RPC. Why do you need all the HTTP methods when most SDKs simplify everything to .retrieve etc, why not name the endpoints that?
What I realized was that these specs are valuable because they’re stable over long periods of time and handle many sorts of edge cases. Also from a systems integration perspective, everybody already knows and is trained in them. Over many years I accepted the wisdom of commons.
A lot of tooling already exists to make development of these sorts of systems easy to implement and debug. Hence why I think for Remote MCP servers, HTTP as it exists is a great choice.
I don't feel that's really true, it's easy to forget how fast things have moved.
For a long time lots of servers didn't really support PUT or DELETE, and it was only the early 2010s that it became common.
It's still a problem sometimes that you have to explicitly enable them (I'm looking at you IIS + WebDAV).
PATCH wasn't even added till 2010 and you still don't see it commonly used.
Perhaps we have different understandings of 'stable' and 'many years'.
I also agree with you on RPC, it's pretty ridiculous that some guys tried to boil every single API down to essentially 4 verbs. I remember when Google went all crazy on implementing pure REST and their APIs were atrocious.
And everyone still goes along with it even though it clearly doesn't work, so you always end up with a mix of REST and RPC in any non-trivial API.
But pure RPC doesn't really work as then you have to change every call to a POST, as you mention. Which is also confusing as everyone is now used to using the really restricted REST CRUD interface.
So now pure REST sucks and pure RPC sucks. Great job HTTP standards team!
To be fair to them, I know it's hard and at some point you can't fix your mistakes. These days I guess I've just accepted that almost all standards are going to suck a bit.
ad hoc RPC[1] that involves JSON request/response payloads and is wed to HTTP transport is arguably worse than conforming to the JSON-RPC 2.0 specification[2].
[1] if it’s not REST (even giving a pass on HATEOAS) then it’s probably, eventually, effectively RPC, and it’s still ad hoc even if it’s well documented
The big irony behind HATEOAS is that LLMs are the mythical "evolvable agents" that are necessary to make HATEOAS work in the first place. HATEOAS was essentially built around human level intelligence that can automatically crawl your endpoints and read documentation written in human language and then they scratched their head why it didn't catch on.
Only browser like clients could conform to HATEOAS, because they essentially delegate all the hard parts (dealing with a dynamically changing structureless API) to a human.
With e.g. JSON over HTTP, you can implement an API that satisfies the stateless-ness constraint of REST and so on. Without hypermedia controls it would fit at Level 2 of the RMM, more or less.
In that shape, it would still be a different beast from RPC. And a disciplined team or API overlord could get it into that shape and keep it there, especially if they start out with that intention.
The problem I've seen many times is that a JSON over HTTP API can start out as, or devolve into, a messy mix of client-server interactions and wind up as ad hoc RPC that's difficult to maintain and very brittle.
So, if a team/project isn't committed to REST, and it's foreseeable that the API will end up dominated by RPC/-like interactions, then why not embrace that reality and do RPC properly? Conforming to a specification like JSON-RPC can be helpful in that regard.
Yeah, I always thought MCP was a bit verbose. It reminds me of the WSDL and SOAP mess of the 2000s. Model tool calls are just RPCs into some other service, so JSON-RPC makes sense. Is there anything else has wide adoption and good client support? XML-RPC? gRPC? Protobufs? I mean, it shouldn't need extra libraries to use. You can handroll a JSON-RPC request/response pretty easily from any programming language.
Regarding the verbosity, yeah, it's interesting how model providers make more money from more tokens used, and you/we end up paying for it somehow. When you're doing lots of tool calls, it adds up!
Totally agree - a well-defined REST API "standard" for tool listing and tool execution would have been much better. Could extend as needed to websockets for persistent connections / streaming data.
fully agree, and that's what we do at ACI.dev as a managed authenticated tool calling platform. https://www.aci.dev/
And we expose more tool discovery flexibility rather than just list_tools()
It is essentially a standard (has a schema) that has an ecosystem of tools around it.
(completely opensource, no protocol/bridge lockin, no vendor/provider lockin, no ide/client/auton lockin, http/sse/jsonrpc/whatever, local/remote, composable)
So far I'm categorically calling MCP a "bridge", because BLAH supports other bridges such as SLOP (https://github.com/agnt-gg/slop/blob/main/README.md) and conceptually OpenAPI (or simply HTTP) is a bridge.
So blah can orchestra/compose any number of bridges, and it can list any tools it style/format of any bridge. (sorry that sounds so dumb)
For example, you can run `blah mcp start --config blah.json`, and add that to your cursor/claude mcp servers. When you fetch the tools, it loops over all your tools in your blah.json and fetches them whether it is an mcp server, slop server or openapi, it's agnostic and will return a full list of tools pulling from all bridges.
And then you can do `blah slop start`, which will do the same, but the opposite, start a slop server but it will boot up mcp servers and serve them over http too.
So essentially a bridge/protocol agnostic system, you ask for a list of tools, and it traverses everything that can list tools and splats them all together.
That's a little of the main pitch but there are larger plans to try build an ecosystem like npmjs where there is a public registry of any tool (which are just functions at the end of the day). Clouldflare AI team is really getting it right now (https://blog.cloudflare.com/remote-model-context-protocol-se...), most people would rather just tools being hosted for them, and workers is perfect for that.
It also means you just have to add one MCP server and use one configuration file to manage your tools. (Also has way more control over logging which MCP devs would love)
---
And that all maybe sounds complicated, but it's meant to make things A LOT easier. The README.md is horrible, just lots of random ideas and my comment isn't much better, but I'm aiming to have an alpha version in a week or so. Would absolutely love feedback!
I agree, people don't want to manually add all MCP servers they want to connect to. I think we're headed in a direction where dynamic tool discovery will be important. E.g. I want to do "x" which requires doing "y" and "z". The client or server should then search for the tools (or agents as tools) that can do the job. So this would basically be a semantic search for which tools are most likely to do the job, then use those tools, and search for more tools if it needs to. RAG for tools, essentially. I wrote an article on how to give ChatGPT unlimited functions a year ago, where I implemented this method.
I basically created a vector database for functions, and created the store based on the tool description, then added the tool definition as metadata. Then for every request I ran a lookup for tools, added them to the tools list. Since tool definitions are added to the context we would have to do something like this at some stage when we want to implement a lot of tools.
This is very cool but definitely has the XKCD standards vibe [0]. If the industry is standardizing on MCP but then we decide it's not good enough, we just end up back where we started. I hope there's enough willpower (and low enough ego) to get to a really tight, single great implementation.
Complete with the alt text mentioning USB, which is used in the MCP website to describe it. Someone else said it and I agree, it's not a good analogy. Most of what we do in software development is connecting things. Saying "this is like USB but for X" could cover a huge chunk of what software is.
Besides, this "think of" analogies kinda irk me because I don't want you to give me a mental image you think I can digest, I want to know how it works. Abstractions in software are great and all but the fact that for some reason most explainers have decided they should be opaque is very unhelpful when you're trying to learn.
Only a certain subset of developer spends most of their time "connecting things", and if that's the kind of developer you consider yourself, I'd be looking to either upskill or change professions as this will be the first kind of developer eliminated if we continue to see decent progress in automation.
Doesn't mean it's not all the same or boring drudge work :).
Though I disagree with GP's reply to you about being product-oriented and such - 90% of products are just "system integration" with some custom marketing graphics and a sprinkle of vendor lock in :).
Combination of standardization and AI will end in a great carnage of software developer jobs, as system integration is basically the poster child of a job that should not exist in ideal world - i.e. all problems are problems of insufficient automation or insufficient ability to cope with complexity. But there's only so much demand for R&D and creating bona fide new capabilities, and not everyone wants to be a manager or a salesperson...
IDK, might be really the time to pick some trade skills, as manual labor in the field is likely the last thing to be automated away.
I would still feel zero job security in such a position, and would be looking for work which is not only intellectually and creatively rewarding, but considerably more difficult to automate. Often this means becoming product-oriented or getting into leadership positions.
To really understand MCP you need to think about application design in a different way.
In traditional applications, you know at design-time which functionality will end up in the final product. For example, you might bundle AI tools into the application (e.g. by providing JSON schemas manually). Once you finish coding, you ship the application. Design-time is where most developers are operating in, and it's not where MCP excels. Yes, you can add tools via MCP servers at design-time, but you can also include them manually through JSON schemas and code (giving you more control because you're not restricted by the abstractions that MCP imposes).
MCP-native applications on the other hand can be shipped, and then the users can add tools to the application — at runtime. In other words, at design-time you don't know which tools your users will add (similar to how browser developers don't know which websites users will visit at runtime). This concept — combined with the fact that AI generalizes so well — makes designing this kind of application extremely fascinating, because you're constantly thinking about how users might end up enhancing your application as it runs.
As of today, the vast majority of developers aren't building applications of this kind, which is why there's confusion.
I think this is a good explanation on the client side of MCP. But most developers are not building MCP clients (I think?). Only a few companies like OpenAI, Anthropic, Cursor and Goose are building MCP client.
Most developers are currently building MCP servers that wrap a 3rd party or wrap their own service. And in this case, they are still at deciding on the tools in design-time, not runtime.
Also I want to mention that both Cursor and Claude desktop don't support dynamic toggling on / off tools within a MCP server, which means users can't really pick which tools to expose to AI. It exposes all tools within a MCP server in current implementation.
The concept of design-time vs. runtime applies to both clients and servers.
I believe you're implying that server developers can focus less on this concept (or sometimes even ignore it) when building a server. This is true.
However, the fact that end-users can now run MCP servers directly — rather than having to wait for developers to bundle them into applications — is a significant paradigm shift that directly benefits MCP server authors.
This a good characterisation of functionality MCP might enable. Thanks.
In your opinion, what percentage of apps might benefit from this model where end users bring their own MCP tools to extend the capabilities of your app. What are some good examples of this - e.g., a development tool like Cursor, WindSurf likely apply, but are there others, preferable with end users?
How is the user incentivized to upskill towards finding the right tool to "bring in", installing it and then using it to solve their problem.
How do we think about about the implications of bring your own tools, knowing that unlike plugin based systems (e.g,. Chrome/extensions), MCP servers can be unconstrained in behaviour - all running within your app
> In your opinion, what percentage of apps might benefit from this model where end users bring their own MCP tools to extend the capabilities of your app.
Long term close to 100%. Basically all long-running, user-facing applications. I'm looking through my dock right now and I can imagine using AI tools in almost all of them. The email client could access Slack and Google Drive before drafting a reply, Linear could access Git, Email and Slack in an intelligent manner and so on. For Spotify I'm struggling right now, but I'm sure there'll soon be some kind of Shazam MCP server you can hum some tunes into.
> How is the user incentivized to upskill towards finding the right tool to "bring in", installing it and then using it to solve their problem.
This will be done automatically. There will be registries that LLMs will be able to look through. You just ask the LLM nicely to add a tool, it then looks one up and asks you for confirmation. Running servers locally is an issue right now because local deployment is non-trivial, but this could be solved via something like WASM.
> How do we think about about the implications of bring your own tools, knowing that unlike plugin based systems (e.g,. Chrome/extensions), MCP servers can be unconstrained in behaviour - all running within your app
There are actually 3 different security issues here.
#1 is related to the code the MCP server is running, i.e. the tools themselves. When running MCP servers remotely this obviously won't be an issue, when running locally I hope WASM can solve this.
#2 is that MCP servers might be able to extract sensitive information via tool call arguments. Client applications should thus ask for confirmation for every tool call. This is the hardest to solve because in practice, people won't bother checking.
#3 is that client applications might be able to extract sensitive information from local servers via tool results (or resources). Since the user has to set up local servers themselves right now, this is not a huge issue now. Once LLMs set them up, they will need to ask for confirmation.
> local deployment is non-trivial, but this could be solved via something like WASM.
This is why I started working on hyper-mcp which use WASM for plugin development & OCI registry for hosting. You can write Dockerfile for plugin packaging
You develop plugins in any language you want as long as it supports WASM
I can’t express how much I agree with your perspective. It’s a completely different/total shift in how we might deliver functionality and… composability to users.
Unfortunately, MCP is not HATEOAS. It doesn't need to be, because it's not web-like. I wish it were.
HATEOAS is great for web-like structures because in each response it not only includes the content, but also all actions the client can take (usually via links). This is critical for architectures without built-in structure — unlike Gopher which has menus and FTP and Telnet which have stateful connections — because otherwise a client arriving at some random place has no indication on what to do next. MCP tackles this by providing a stateful connection (similar to FTP) and is now moving toward static entry points similar to Gopher menus.
Plugins have pre-defined APIs. You code your application against the plugin API and plugin developers do the same. Functionality is being consumed directly through this API — this is level 1.
MCP is a meta-protocol. Think of it as an API that lets arbitrary plugins announce their APIs to the application at runtime. MCP thus lives one level above the plugin's API level. MCP is just used to exchange information about the level 1 API so that the LLM can then call the plugin's level 1 API at runtime.
This only works because LLMs can understand and interpret arbitrary APIs. Traditionally, developers needed to understand an API at design-time, but now LLMs can understand an API at runtime. And because this can now happen at runtime, users (instead of developers) can add arbitrary functionality to applications.
> And because this can now happen at runtime, users (instead of developers) can add arbitrary functionality to applications.
I don't understand what you mean by this. Currently without MCP a server has an API that's documented and to interact with it(thus provide "arbitrary functionality") you call those APIs from your own application code(e.x. python script).
With MCP an LLM connected to your application code calls an API that's documented via MCP to provide "arbitrary functionality".
How are these different, and how does MCP allow me to do anything I couldn't before with API access and documentation? In both cases the application code needs to be modified to account for the new functionality, unless you're also using the LLM to handle the logic which will have very unpredictable results.
>In both cases the application code needs to be modified to account for the new functionality, unless you're also using the LLM to handle the logic which will have very unpredictable results.
In the case of MCP, no application code is modified. You first ship the application and then functionality is added. Using plain APIs, it's the other way around. That's the difference.
If my application performs some function dependant on data from an API(e.x. showing tax information, letting a user input tax information, and performing tax calculations and autocomplete), how do I extend that UI easier with MCP than with an HTTP REST API.
Even with MCP I need to update my application code to add UI elements(inputs, outputs) for a user to interact with this new functionality, no?
No, MCP does not include any concept of UI (yet). Tool results are usually text only, although there is also the abstraction of an Image (which can be displayed as clients as decide to, e.g. inline).
So no application code needs to be changed because no application code exists.
Isn't that like saying you don't need to modify application code with an REST API if your "application" is just a list of instructions on how to use wget/bash to accomplish the task?
As it currently stands, MCP is absolutely a security nightmare. Combine this with a general lack of appreciation for security culture amongst developers, and the emerging vibe coding paradigm where non-security-minded people automatically generate and fail to properly audit production-facing code, and it's a disaster waiting to happen.
Feels like we've slid back into the 90s in this regard. Great time to be a security researcher!
> Feels like we've slid back into the 90s in this regard.
Thank $deity. 90s and early 2000s were the times software was designed to do useful work and empower users, as opposed to lock them into services and collect telemetry, both of which protected by the best of advancement in security :).
I'm only half-joking here. Security is always working against usefulness; MCP is designed to be useful first (like honest to $deity useful, not "exploit your customers" useful), so it looks like security nightmare. Some of that utility will need to go away, because complete lack of security is also bad for the users - but there's a tradeoff to be made, hopefully one that doesn't just go by modern security zeitgeist, because that is already deep into protecting profits by securing services against users.
> a general lack of appreciation for security culture amongst developers, and the emerging vibe coding paradigm where non-security-minded people automatically generate and fail to properly audit production-facing code
There is also a general lack of consideration of who is being protected from whom, and why in the security culture. MCP, vibe coding, and LLMs in general are briefly giving end-users back some agency, bringing back the whole idea of "bicycle for the mind" that was completely and intentionally destroyed when computing went mainstream. Let's not kill it so eagerly this time.
- How does a consumer of a remote MCP server trust that it is not saving/modifying their data, or that it is doing something other than what it said it would?
- How does a consumer of a local MCP server trust that it won't wreck their machine or delete data?
- How do servers authorize and authenticate end users? How do we create servers which give different permissions to different users?
These are examples of things which must be done right, and sacrificing user security in order to achieve market dominance is ethically bankrupt. Pedestrians don't know exactly which regulations serve them when a bridge is built, so we don't expect pedestrians to be able to stop corruption and laziness in civil engineering. The same should be true for mass infrastructure; we have a duty as engineers to make the right call.
> MCP, vibe coding, and LLMs in general are briefly giving end-users back some agency, bringing back the whole idea of "bicycle for the mind"
I love what software might look like in 15 years. I don't plan to kill that. I want to protect it, and also protect everyone involved.
It’s pretty astounding to me that this aspect of MCP is not mentioned more. You’re putting a LOT of trust in both the model and the system prompt when you start attaching MCPs that provide unfettered access to your file system, or connect up to your REST API’s POST endpoints.
(That being said, I have to admit I’ve been writing my own powerful but extremely dangerous tools as an experiment (e.g. run arbitrary Python code on my machine, unsandboxed) and I have to admit the results have been incredibly compelling.)
I really enjoyed both your blog posts. You've clearly thought about this a lot and explained things well. I'd love to subscribe to be updated on your next post (even if it's not for months/years). Any chance you could add an RSS feed to your blog?
> MCP is an open protocol that standardizes how applications provide context
> to LLMs. Think of MCP like a USB-C port for AI applications. Just as USB-C
> provides a standardized way to connect your devices to various peripherals
> and accessories, MCP provides a standardized way to connect AI models to
> different data sources and tools.
I want to know in which way is USB-C applicable here. The complicated plug that's actually 30 different protocol's that's difficult understand what capabiltiies a plug/cable actually has?
Yes. 99% of that complexity is on the side of implementers - where it should be - and for actual use, approximately everything works well with everything else; specifics matter mostly when you're trying to plug devices that exercise the limits of advanced capabilities. Which sucks, yes, but mostly because implementers/vendors made it this way (would it hurt y'all to label your cables and devices properly, correctly and visibly?!).
Maybe they used an LLM to explain it. Gemini in particular is obsessed with these utterly useless analogies for everything, when I would prefer something closer to Wikipedia with more context. (Needless to say, I currently don't find LLMs useful for learning about things. That's a shame because that use case feels promising.)
I saw this ChatGPT-created analogy on a JS subreddit the other day:
> Imagine you have a robot in a room, and this robot can perform actions like turning on a light, opening a door, or picking up objects. Now, if you want to tell the robot to do something, you usually say something like, "Robot, pick up the pen!" or "Robot, open the door."
> In JavaScript, ‘this’ is like the "robot" in the room
LLMs are like an unlimited, poorly written encyclopedia. Often inaccurate or not entirely helpful, but will get you enough of an idea to find better sources. Sort of solving the "I don't know what I don't know" gap.
The closest software analogy I’ve heard is like passing around a callable/function with a standard interface. An LLM can call the callable and work with the returned data without needing to go back and forth between your application logic.
> MCP, despite its open-source claim, heavily relies on proprietary interfaces from Anthropic's Claude model. Thus, the proclaimed openness is surface-level at best, creating subtle but significant barriers within the ecosystem.
This strikes me as fundamentally untrue, but I'd love to see an example of this in the source code or documentation.
This is just an ontological issue. Is it a standard because it is designed to be one, or is it only a standard once it actually fulfills its role and is recognized as a standard? That's something we could debate all night. :)
they probably mean it’s going to be difficult early on to find standards compliant implementations. and then always very annoying to make sure all involved components support the correct feature set.
Do they? Like actually, know it cover-to-cover, or do they just know of it? Because the first thing to point out is that USB-C isn't a protocol, it's a connector standard.
It's a beautiful and deep analogy, and works for both software engineer and their mom.
Mom-level: ChatGPT ("or that other ChatGPT with a human name, Klaus I think? No, it was Claude.") can use software that says it supports MCP. If it says "MCP", I can use it with my AI.
Software dev level: MCP servers and MCP clients should just work, like USB. I don't really have to care about this, I expect them to connect just fine. Like with USB, there's a crap ton of complexity dumped on implementers of the spec to make it work reliably and cheaply - as it should be. That's literally their job: to take all the "secret sauce" that makes their product "special" and hide it behind a standard, because they're not special and nobody cares.
As another software engineer: if it ain't USB, I ain't buying, because I'm too old to deal with the proprietary per-device unique connectors bullshit. The standard exists so I don't have to think about it.
I am really struggling with what the value-add is with MCP. It feels like another distraction in the shell game of contemporary AI tech.
> MCP is an open protocol that standardizes how applications provide context to LLMs.
What is there to standardize? Last I checked, we are using a text-to-text transformer that operates on arbitrary, tokenized strings. Anything that seems fancier than tokens-to-tokens is an illusion constructed by the marketing wizards at these companies. Even things like tool/function calling are clever heuristics over plain-ass text.
> Currently, the MCP spec defines two kinds of servers, based on the transport mechanism they use: ...
This looks like micro services crossed with AI. I don't think many are going to have a happy time at the end of this adventure.
If you're interested, I'd encourage you to implement an MCP integration and see if you change your mind.
For instance, I have a little 'software team in a box' tool. v1 integrated github and three different llms manually (react + python backend). This is fine. You can call github commands via CLI on the backend, and add functionality somewhat easily, depending on the LLM's knowledge.
Pain points -- if you want workflow to depend on multiple outputs from these pieces, (e.g. see that there's a pull request, and assess it, or see that a pull request is signed off on / merged, and update something) -- you must code most of these workflows manually.
v2, I wiped that out and have a simple git, github and architect MCP protocol written up. Now I can have claude as a sort of mastermind, and just tell it "here are all the things you can do, please XXX". It wipes out most of the custom workflow coding and lets me just tell Claude what I'd look to do -- on the backend, my non-LLM MCP server can deal with things it's good at, API calls, security checks, etc.
So is the MCP server acting like a middleman between the llm and the application you want to control?
Like, could I give the MCP server the ability to say exec Unix code on my machine and then tell the LLM "here's the MCP server, this function can execute Unix code and get back the response".
Then I can tell the LLM, "create an application using the MCP server that will listen to a GitHub webhook and git pull when the webhook hits and have it running" then the LLM would generate the commands necessary to do that and run them through the MCP server which just executed the Unix code. And viola?
I've gotten an llm to create files and run system commands for me.
“Implementation detail” is doing a lot of work in the second sentence, though. There are whole startups like langchain that were trying to build out a reasonable agent framework integrated in such a way that the LLMs can drive. MCP makes that really easy — LLM training just has to happen once, against MCP spec, and I get client and LLM support for an iterative tool use scenario right in the LLM.
At a high level, the request format and endpoints. Instead of needing to write a bespoke connector for every type of context that matches their preferred API standards, I just tell my client that the server exists and the standard takes care of the rest.
Do you have similar doubts about something like gRPC?
> This looks like micro services crossed with AI.
Seems like a cynical take with no substance to me. What about a standard request protocol implies anything about separation of concerns, scaling, etc?
Because it's not a request format for LLMs, it's a request format for client software that is instrumenting LLMs. If you make a connector to say HomeAssistant to turn on/off your lights you're exposing a tool definition which is really just a JSON schema. The agent will present that tool to the LLM as one it's allowed to use, validate that the LLM matched your change_light_state tool schema and send off the appropriate API call to your server.
The spec is genuinely a hot fucking mess that looks like a hobby project by an overeager junior dev but conceptually it's just a set of JSON schemas to represent common LLM things (prompts, tools, files) and some verbs.
Right now your typical interaction in chat is limited with some exceptions of out of box tooling that most current platforms provide: file attachment, web search, etc.
MCP is a way to extend this toolbox, but the cooler thing is AI will be able to determine _at inference time_ what tools to use to fulfill the user's prompt.
If we want to get pedantic, in context of practical transformer models it has never been text to text. It has always been tokens to tokens. The tokens can represent anything. "multimodal" is a marketing term.
You could say the same thing about almost any protocol, e.g. HTTP, which runs on arbitrary streams of bytes over TCP; and the headers, methods and status codes are just illusions on top of that.
Sure, like how we all self-host our own email servers and photo albums? Honestly, I think you’re about as wrong as you could possibly be, both on timelines, and in that I’d argue the arc of consumer tech adoption bends towards centralisation most often.
Standards are already emerging, including MCP, and to say that simply because they’ll evolve and be replaced over time means they’re not ‘real’ now is ridiculous. Look at the early internet and web as examples.
Local models, even accounting for reasonable progress and device performance improvements, will always, inherently, be behind the eight ball compared to SOTA models. While they may be sufficient for the low hanging fruit, I’d not bet against the frontier models being every bit as compelling relatively speaking.
Using weasel words like ‘real’ and ‘x is the future’ is astoundingly arrogant, and anyone claiming with confidence that they’ve got any idea where we’re heading is almost assuredly wrong.
1) It isn't a standard yet, but what else apart from filesystem-mcp can be used for prompts like "write me README.md for this repo" (like really produce the file)
2) For me it is not clear the future is smaller self-hosted LLMs. As of today, most useful for me is to use best models, and those are not self-hosted.
Once we get used to the fact that LLMs exist they won't be sold on the gee-whiz "wow, a talking assistant just like in my sci-fi movies!" factor.
They'll be used for particular language classification and search tasks, and for that you'd want several lighter, faster, cheaper and more specialized models. Not one with an arbitrary "best" score that's based on tricking the Turing test.
I feel like that article doesn't really live up to its title. At the end, its basic point is that MCP isn't a magic bullet (I don't think anyone claimed it was?) and that it has a lot of hype. It also makes it clear why MCP is good (ie don't need to rely on LangChain). Feels like its title should be "Why MCP is a Good Step but Doesn't Solve Agents" or something. But then, it wouldn't enable the millenial urge to use "shit".
the problem of agents is not the lack of standards, but reliability (reliability of tool use and reliability of outcomes). MCP does not solve any of that.
Standards might not have been _the_ problem, but they were _a_ problem. Before MCP I couldn't distribute a tool call that could be configured by end-users to be used with multiple mainstream clients.
This is just moving the goalposts, MCP is not supposed to solve every problem with agents. It's meant to make it easier to provide easier, standardised ways for LLMs to interact with external tools, which it has done. Reliability is a completely different problem.
That article seems to miss the point by being incurious about _why_ there is hype around MCP instead of LangChain, LangGrah, SmolAgents, LlamaIndex, etc.
We've had tool call frameworks before, but we haven't had a way of making tools that our clients actually talked to. There was no way to build tools that other people could download and run locally without getting them to switch to a client that baked those tools in. It's like the difference between static linking and dynamic linking, but for tool calls.
Tool calls in any of the agent frameworks are just wrappers around native functions.
MCP let's you handle the processing outside of the agent context, redistribute tools independently, and provide them as either private or public hosted services.
Basically, add an HTTP layer on the existing concept of tools. It is not a replacement for a framework, it is an enhancement of a well established pattern.
> That article seems to miss the point by being incurious about _why_ there is hype around MCP instead of LangChain, LangGrah, SmolAgents, LlamaIndex, etc.
The VCs that were invested in AI companies (like Cursor) would of course need to hype something up like MCPs to get us to build them as little of those tools did not exist.
Cursor already makes $100M+. So why not get behind and integrate this chosen standard to make even more money with more MCP servers.
The last ingredient is to hype it all up on the internet to get everyone building.
A win for the VCs regardless even though it was suspiciously orchestrated as soon as Cursor integrated it.
MCPs aren't specific to Cursor. Rather, they enable any IDE to become a Cursor competitor.
Example: JetBrains released an MCP server plugin for their IDEs recently and it enables Claude Desktop to seamlessly use the IDE for reading and writing files and even compiling or running tests against it.
And that's just one example; there are MCP servers for anything from VSCode to Emacs already. That means almost anyone can now use LLMs to generate code in their IDE of choice, just as they would do with Cursor.
In fact, MCPs are posing a threat to many startups, especially the "wrapper" ones.
I too feel it's bad that companies take VC money and build open standards which let me build faster and target more providers. Seriously, what? I struggle to understand the mindset of someone frequenting HN who can say unironically that "getting everyone building" is a bad outcome.
I'd like some more of that getting everyone building please.
VCs invested in AI and agentic companies needed a way to get you guys to accelerate agents this year.
So why not "create" artificial hype for MCPs on the internet, since there were little to no MCP servers for LLMs to use despite it being several months old (November 2024) until Cursor integrated it.
This is the true reason why you see them screaming about MCPs everywhere.
Hype isn’t free. Maybe the benefit is mutual, but I can’t tell how Anthropic gets paid.
Anthropic subsidizes an open standard, but proprietary extensions later emerge that lock you into servers from their marketplace or something? I need a sociopath to help me understand this.
The Anthropic models are running underneath everything (Claude Code, Windsurf, Cursor, etc). Whenever someone is using MCP they (in the generalized case, until now) ultimately end up using Anthropic as their LLM and Anthropic gets paid whenever someone does that.
There's already like a half dozen such "marketplaces" and they all ultimately point to open source repos. If the goal was to lock people in, they did a bad job of it.
there's a reason there's MCP plugins for LangChain. Some companies will need massively customized workflows that LangChain is appropriate for, where it only needs to dig into a couple potentially publically accessed MCPS for things.
I could see a future where companies have their developer portal where now they have their APIs document, the pretty in swagger, the samples, etc, but they'll have a MCP endpoint (potentially), where they're safely exposing the data to an LLM. Your langchain node step to to get context, could call out to some of these hosted/shared mcps where you do standard stuff, like post to a Slack channel, grab some data from a SFDC instance, etc....
I hoped OpenAI would support OpenAPI for connecting to tools. Having created a couple of MCP servers, it feels like a less flexible and worse documented API to me. I can’t really see anything that is made better by MCP over OpenAPI. It’s a little bit less code for a lot less options. Give it some time and it will also get Swagger built in.
It’s solving a problem that was already robustly solved. So get we go with another standard.
transport argument is irrelevat when http can be both TCP and UDP, and even if you wanna do one protocol, it can be proxied/tunneled via another protocol transparently via VPN/wireguard/proxy.
so transport protocol is moot, especially from latency perspective when most time is spent doing AI inference (seconds) rather than passing packets (milliseconds).
I really wish OpenAI just embraced OpenAPI and that would have instantly gained millions of existing sites available to ChatGPT with zero code change.
It's transport-agnostic in the sense that it works locally (over stdout), not just remotely. It's not just for web-services. That's why HTTP isn't baked into this.
I feel like we should have transport agnostic RPC by now, GRPC?
And MCP is stateless too.
And you don't have to create a client per API, it's up to implementation.
Are we reading the same documents? MCP implementations are all websockets so it's not really transport agnostic. They try to talk
about how you can use other transports but its just that it's JSON-RPC and if you're willing to code both ends you can do whatever… which is always true. And MCP is explicitly a stateful protocol [1].
They mention stdio specifically under the transport section of the spec.
Most protocols are transport agnostic, but http APIs tend to require HTTP methods.
Http itself is transport agnostic, but truthfully all we’re doing is shuffling bytes around.
If you look at the stateless examples in that PR, they both assume some state (specifically the capabilities) and just behave accordingly.
To get the full features of the protocol (like notifications) a stateful connection would still be required.
There's already swagger MCP service out there, I don't know how production ready it is, but I saw something the other day when searching through GitHu. One of several implementations: https://github.com/dcolley/swagger-mcp
Can't I do function calling in OpenAPI? I also feel like MCP is reinventing the wheel.
I have been converting OpenAPI documents into function calling schemas and doing tool calling since function calling first came out in 2023, but it's not easy to recreate a backend server to fit MCP.
Also, these days, I'm making a compiler-driven function calling specialized framework, but I'm a little cautious about whether MCP will support it. It enables zero-cost tool calling for TypeScript classes based on the compiler, and it also supports OpenAPI.
However, in the case of MCP, in order to fit this to the compiler-driven philosophy, I need to create a backend framework for MCP development first, or create an add-on library for a famous framework like NestJS. I can do the development, but there's so much more to do compared to OpenAPI tool calling, so it's a bit like that.
How should an MCP server like git work in your opinion? Should it then be written as a FastAPI server so that you have an openapi spec instead of just a CLI?
"Think of MCP like a USB-C port for AI applications."
Given the enormous amounts of pain I've heard are involved in actually implementing any form of USB, I think the MCP community may want to find a different analogy!
What are people using MCPs for? I search on youtube and see a lot of videos explaining how MCPs work, but none showing practical uses for a programmer (aside from getting the weather via cursor).
I have two that I use a lot:
- Postgres one connected to my local db
- A browser (Playwright)
That way I can ask cursor something like: "Find an object with xxx property in the db, open its page in the browser, fix console errors"
And it's able to query my db, find relevant object, open the browser, check logs, fix the code based on errors.
Even simpler stuff:
- copying pasting a broken local url in cursor, and asking it to fix all console errors. Works really well.
- or when you have a complex schema, and need to find some kind of specific record, you can just ask cursor "find me a user that has X transactions, matches Y condition, etc..". I found it much faster than me at finding relevant records
I think I’m starting to see the potential.. So I could MPC cursor to my local Postgres (or, after some practice to build confidence, prod Postgres). Then use cursor to help debug.
This sounds risky but very useful if it works as intended!
Yes, I have used that workflow to fix a tricky data corruption issue earlier this week.
A buggy feature left DB in invalid state, I described the issue to Claude + Postgres MCP to both query the DB to analyze and then generate SQL scripts to fix, and validation and rollback scripts. Easy enough to do without the tooling... but with the tooling, it took probably a quarter or less of the time.
- filesystem, read(and occasionally write) to local disk
- mcp-perplexity, so I can essentially have Claude sample from perplexity's various models and/or use it for web search. Somewhat superseded by Claude's own new web search capability, but perplexity's is generally better.
If you want to try out mcp (model context protocol) with little to no setup:
I built https://skeet.build/mcp where anyone can try out mcp for cursor and now OpenAI agents!
We did this because of a painpoint I experienced as an engineer having to deal with crummy mcp setup, lack of support and complexity trying to stand up your own.
Mostly for workflows 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
* Find a bug a create a linear issue to 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 code
* Postgres or MySQL schemas for rapid model development
Everyone seems to go for the hype but ease of use, practical pragmatic developer workflows, and high quality polished mcp servers are what we’re focused on
Call it a protocol and suddenly it sounds like a foundational technology.
Nah, it's just a fancy JSON schema that lets LLMs play hot potato with metadata.
Shamelessly promoting in here, I created an architecture that allows an AI agent to have those so called "tools" available locally (under the user control), and works with any kind of LLMs, and with any kind of LLM server (in theory). I've been showing demos about it for months now. Works as a middle-ware, in stream, between the LLM server and the chat client, and works very well. The project is open source, even the repo is outdated, but simply because no one is expressing interest in looking into the code. But here is the repo: https://github.com/khromalabs/Ainara. There's a link to a video in there. Yesterday just recorded a video showcasing DeepSeek V3 as the LLM backend (but could be any from OpenAI as well, or Anthropic, whatever).
The lack of interest may be from the crypto aspect:
> While the project will always remain open-source and aims to be a universal AI assistant tool, the officially developed 'skills' and 'recipes' (allowing AI to interact with the external world through Ainara's Orakle server) will primarily focus on cryptocurrency integrations. The project's official token will serve as the payment method for all related services.
Thank you for the feedback... actually I need to update that, the crypto part of my project will be closed source (an specific remote server) but the idea behind the project itself is universal and open since the very beginning, I already developed dozens of skills including a meta-search engine (searches in several engines at once and combines results dynamically, all balanced by the AI) which are open source as well. Crypto just kind of showed itself as way of funding project, with no strings attached, and till this very day no one else showed up.
I'm new to "MCP"... It says here that even IDE plug into this MCP server [1], as in you don't edit files directly anymore but go through a client/server?
It wasn't bad enough that we now run servers locally to constantly compile code and tell us via json we made a typo... Soon we won't even be editing files on a disk, but accessing them through a json-rpc client/server? Am I getting this wrong?
I think you are getting it wrong. Some IDEs like Cursor and VS Code extensions like Cline support MCP servers, meaning you can give them access to your databases, Jira tickets, Notion notes, Slack messages, etc.
This is great, I was debating whether I should do my latest project using the new OpenAI Responses API (optimized for agent workflows) or using MCP, but now it seems even more obvious that MCP is the way to go.
I was able to make a pretty complex MCP server in 2 days for LLM task delegation:
claude needed these those tools in 2024, so having the community contribute for free was actually a smart move.
service providers get more traffic, so they’re into it. makes sense.
claude 3.5 was great at the time, especially for stuff like web dev. but now deepseek v3 (0324) is way better value. gemini's my default for multimodal. openai still feels smartest overall. i’ve got qwq running locally. for deep research, free grok 3 and perplexity work fine. funny enough, claude 3.7 being down these two days didn’t affect me at all.
i checked mcp since i contribute to open source, but decided to wait. few reasons:
- setup’s kind of a mess. it’s like running a local python or node bridge, forwarding stuff via sse or stdio. feels more like bridging than protocol innovation
- I think eventually we need all the app to be somehow built-in AI-first protocol. I think only Apple (maybe Google) have that kind of influence. Think about the lightening vs usb-c.
- performance might be a bottleneck later, especially for multimodal.
- same logic as no.2 but the question is that do you really want every app to be AI-first?
main issue for me: tools that really improve productivity are rare. a lot of mcp use cases sound cool, but i'll never give full github access to a black box. same for other stuff. so yeah—interesting idea, but hard ceiling.
You should take a look at how Claude Code does its permissioning. It's totally fine to connect it right up to your GitHub MCP server because it'll ask each time it wants to take an action (and you can choose "don't ask again for this tool" if it's an obviously safe operation like searching your PRs).
Does anyone have any prior art for an MCP server "message bus" with an agent framework like Mastra?
E.g. suppose I want my agent to operate as Discord bot listening on channel via an MCP server subscribed to the messages. i.e. the MCP server itself is driving the loop, not the framework, with the agent doing the processing.
I can see how this could be implemented using MCP resource pubsub, with the plugin and agent being aware of this protocol and how to pump the message bus loop, but I'd rather not reinvent it.
Is there a standard way of doing this already? Is it considered user logic that's "out of scope" for the MCP specification?
I'm curious what the revenue plan is for MCP authors. I mean, I can see wanting to add support for existing products (like an code/text editor, image/sound/video editor, etc.)
But is there a market for stand-alone paid MCP services? It seems these will mostly be usurped by the models themselves sooner or later. I mean if you create a MCP popular enough to actually make money, the foundation model will soon be able to just do it without your service. Almost like you are doing experimentation on high-value agent features for free.
Also, something about the format just reeks of SOAP to me. It feels over-engineered. Time will tell, obviously.
Most MCP servers are thin wrappers around an API, I don't think there will be a big paid market. I imagine they will be released like SDKs are now, either by companies themselves, or by individuals when there's no official implementation. A few dev agents can even write MCP servers for themselves.
Right, that is why I said it makes sense for existing products. I mentioned desktop apps, but it would apply to any existing project. Like JIRA, or HubSpot, Wordpress, or Figma, etc.
But there is hype around MCP as if independent devs could do something with it. And some will just for fun, some will for open source cred. But it is my experience that longevity is usually the result of stable revenue.
I guess what I predict happening here is a few people will build some useful MCPs, realize there is no way to monetize despite generating a lot of interest and the most useful/popular MCPs will be integrated directly into the offerings of the foundational AI companies. And in a few years we won't even remember the acronym unless you happen to work for some big corp that wants to integrate your existing service into LLMs.
The currently-dominant open source paradigm (i.e. motivated and well-meaning developers work themselves to the bone under pressure from tech giants who will never pay them) is clearly not sustainable. Moreover, many are probably not happy with their code being used (without permission) to train machines whose putative intent is to replace those self-same developers. Now the question is, how many will want to do something similar, again?
Is what you are insinuating that the only licensing model for independent MCP authors is open source? Are you assuming that MCPs are only viable as free (as in beer) projects?
I feel like software license and business revenue models are only very loosely correlated. I guess if you are assuming there is no money at all to be made in MCP then my question wouldn't make sense.
MCP is great. But what i'd like to understand is whats the difference between MCP and manually prompting the model a list of tools with description and calling the specific function based on the llm response ?
1. it makes tool discovery and use happen elsewhere so programs become more portable
2. it standardizes the method so every LLM doesn't need to do it differently
3. it creates a space for further shared development beyond tool use and discovery
4. it begins to open up hosted tool usage across LLMs for publicly hosted tools
5. for better or worse, it continues to drive the opinion that 'everything is a tool' so that even more functionality like memory and web searching can be developed across different LLMs
6. it offers a standard way to set up persistent connections to things like databases instead of handling them ad-hoc inside of each LLM or library
If you are looking for anything more, you won't find it. This just standardizes the existing tool use / function calling concept while adding minimal overhead. People shouldn't be booing this so much, but nor should they be dramatically cheering it.
You can build all the tools yourself, or you can just go to a "tools store", install it and use it. MCP is just the standard everyone can use to build, share and use these tools.
Just like an app store, a chrome extension store, we can have a LLM tools store.
Was wondering if this would ever happen. I wrote an MCP server that hooked up Azure Monitor (or whatever the hell microsoft is calling it) via Microsoft's python SDK so I could get it to query our logs without using command line tools. Took about half a day, mostly due to writing against the wrong Microsoft SDK. It will be nice to let ChatGPT have a crack a this too!
If you haven't tried any of these yet, the first place to start is Claude Desktop. If you'd like to write your own agents, consider https://github.com/evalstate/fast-agent
EDIT: I may have misunderstood your question. If you're asking "how can I make an API call to OpenAI, and have OpenAI call an MCP server I'm running as part of generating its response to me", the answer is "you can't". You'll want a proxy API that you call which is actually an MCP client, responsible for coordinating between the MCP servers and the OpenAI API upstream agent.
You can run remote MCP servers and configure whatever client to use them. This should work even via OpenAI's API(perhaps not yet, but it's just another 'tool' to call)
This seems to be just implementing tools functionality, no resources or prompts, roots or sampling. I can't blame them.
I'm wondering though about progress notifications and pagination. Especially the latter should be supported as otherwise some servers might not return the full list of tools. Has anyone tested this?
Ideally in the future we won't need an MCP server when the AI can just write Unix terminal code to do anything it needs to get the job done? It seems using an MCP server and having the AI know about its "tools" is more of training wheels approach.
If you have a clean, well-documented API that can be understood in under 30 minutes by a decent software engineer, congrats: you are MCP ready. I wonder how many discussions there will be about "adding MCP support" to software without this prerequisite.
Kinda naive question. All you need is a way to convince the LLM to output json according to your schema, then call the function. So what is the use of MCP servers? Why complicate things by adding another layer?
hopefully they integrate it with their customGPT approach! I think they already work fantastically especially since the addition of the @ sign and automatic completion to easily include them in normal conversations. the only thing that was missing was access to the local machine.
Today MCP added Streamable HTTP [0] which is a huge step forward as it doesn't require an "always-on" connection to remote HTTP servers.
However, if you look at the specification it's clear bringing the LSP-style paradigm to remote HTTP servers is adding a bunch of extra complexity. This is a tool call, for example:
Which traditionally would just be HTTP POST to `/get_weather` with `{ "location": "New York" }`.I've made the suggestion to remove some of this complexity [1] and fall back to just a traditional HTTP server, where a session can be negotiated with an `Authorization` header and we rely on traditional endpoints / OpenAPI + JSON Schema endpoint definitions. I think it would make server construction a lot easier and web frameworks would not have to materially be updated to adhere to the spec -- perhaps just adding a single endpoint.
[0] https://spec.modelcontextprotocol.io/specification/2025-03-2...
[1] https://github.com/modelcontextprotocol/specification/issues...
I fully agree.
MCP is just too complex for what it is supposed to do. I don't get what's the benefit. It is the kind of thing that has the potential to be a huge time waste because it requires custom dev tools to develop and troubleshoot.
It is not even a protocol in the traditional sense - more of a convention.
And of course we will implement it, like everyone else, because it is gathering momentum, but I do not believe it is the right approach at all. A simpler HTTP-based OpenAPI service would have been a lot better and it is already well supported in all frameworks.
The only way I can make sense of MCP in the context of an STDIO.
The `stdio` approach for local services makes complete sense to me. Including using JSONRPC.
But for remote HTTP MCP servers there should be a dead simple solution. A couple years ago OpenAI launched plugins as `.well-known/ai-plugin.json`, where it'd contain a link to your API spec, ChatGPT could read it, and voila. So all you needed to implement was this endpoint and ChatGPT could read your whole API. It was pretty cool.
ChatGPT Plugins failed, however. I'm confident it wasn't because of the tech stack, it was due to the fact that the integration demand wasn't really there yet: companies were in the early stages of building their own LLM stacks, ChatGPT desktop didn't exist. It also wasn't marketed as a developer-first global integration solution: little to no consistent developer advocacy was done around it. It was marketed towards consumers and it was pretty unwieldy.
IMO the single-endpoint solution and adhering to existing paradigms is the simplest and most robust solution. For MCP, I'd advocate that this is what the `mcp/` endpoint should become.
Edit: Also tool calling in models circa 2023 was not nearly as good as it is now.
I agree. What OpenAI did was simple and beautiful.
Also, I think there is a fundamental misunderstanding that MCP services are plug and play. They are not. Function names and descriptions are literally prompts so it is almost certain you would need to modify the names or descriptions to add some nuances to how you want these to be called. Since MCP servers are not really meant to be extensible in that sort of way, the only other alternative is to add more context into the prompt which is not easy unless you have a tone of experience. Most of our customers fail at prompting.
The reason I like the ai-plugin.json approach is that you don't have to change the API to make the description of a function a little bit different. One day MCP might support this but it will another layer of complexities that could have been avoided with a remotely hosted JSON / YAML file.
It’s not just about passing prompts — in production systems like Ramp’s, they had to build a custom ETL pipeline to process data from their endpoints, and host a separate database to serve structured transaction data into the LLM context window effectively.
We’ve seen similar pre-processing strategies in many efficient LLM-integrated APIs — whether it’s GraphQL shaping data precisely, SQL transformations for LLM compatibility, or LLM-assisted data shaping like Exa does for Search.
https://engineering.ramp.com/ramp-mcp
PS: When building agents, prompt and context management becomes a real bottleneck. You often need to juggle dynamic prompts, tool descriptions, and task-specific data — all without blowing the context window or inducing hallucinations. MCP servers help solve this by acting as a "plug-and-play" prompt loader — dynamically fetching task-relevant prompts or tool wrappers just-in-time. This leads to more efficient tool selection, reduced prompt bloat, and better overall reasoning for agent workflows.
The good thing to note is that (AFAIK) MCP is intended to be a collaborative and industry-wide effort. Whereas plugins was OpenAI-specific.
So, hopefully, we can contribute and help direct the development! I think this dialogue is helpful and I'm hoping the creators respond via GitHub or otherwise.
It took me a minute to even understand this comment because for me the “obvious” use-case for MCP is local filesystem tasks, not web requests. Using MCP to manipulate files is my primary LLM use-case and has been ever since Anthropic released it and integrated it into Claude Desktop. I understand where you’re coming from, but I suspect that the idea here is to build something that is more “filesystem first.”
That makes sense. But if that's the case I think we should call a spade a spade and differentiate "Local-first MCP" and "Remote MCP"; because what (many, most?) companies are really trying to do is integrate with the latter.
Which is where you see this sort of feedback, where a bunch of us API engineers are like; "there's already a well-trodden path for doing all of this stuff. Can we just do that and agree that it's the standard?"
100%. I know I’m in the “get off my lawn” phase of my career when I see things like MCP and LangChain, but know I would have been excited about them earlier in my career.
LangChain is an objectively terrible Frankenstein's monster of an API. If you were a good developer in your youth, you'd have still held it in contempt, and treat MCP with caution.
The MCP API is pretty bad, too, it's just that a paradigm is starting to emege regarding modularity, integration and agentic tooling, and MCP happens to be the only real shot in that direction st this particular moment.
How is the MCP API bad? It uses simple and widely available standards-based transports while still allowing custom transport implementations, along with a simple API that can be used easily without any libraries, in any programming language under the sun?
Could you elaborate on your issues with LangChain?
We're kinda headed towards using it as it seems to be a flexible enough abstraction that is relatively stable to work with, so I'd like to know if I'm overlooking something..?
A lot of folks use it to get started quickly and then realize the unnecessary abstractions are obfuscating the actual hard parts.
A big soup of untyped json blobs and python, all working highly asynchronously in complicated ways.
Is this variable available in my agent’s state?
Depends! Is it an agent that started an hour ago before you made that other change? Is it in the manager state or not? Did the previous agent run correctly or not? Did something else go wrong?
You spend more time fighting the tool/framework than working on the product you’re trying to build.
Cryptic errors that will make you tear your hair out and docs that are constantly changing
I’m seriously considering getting out of IT because of it
because of MCP and langchain?
Eh, more the wider cultural effects of them. Vibe coding, everyone now creating kitchen sink apps that do everything under the sun, k8s everywhere, agents everywhere. It feels like a big part of the industry has lost all focus and is sprinting towards some endless vague panacea instead of focusing on solving specific well defined business problems.
It’s always been a bit like this but it feels particularly bad since AI hit mainstream coding tooling. Just my 2c :)
I tend to agree here. Alot of the use cases are around STDIO and using MCPs within existing apps like Cursor/Windsurf etc. Most developers want to build and integrate their own tools and the complexity required here (build out the server, bundle a client, and the additional latency) is probably not worth the ROI. There also seems to be a notion that security is "handled" by MCP which might be premature. I mean, there are several good decisions in the standard (tls with sse, sampling etc), but critical choices around auth and scope for agents or 3rd party mcp providers are still wide open IMO.
Overall, a step in the right direction, but still early. I wrote more on this here. https://newsletter.victordibia.com/p/no-mcps-have-not-won-ye...
How much of this is already addressed by Cloudflare’s Remote MCP setup? https://blog.cloudflare.com/remote-model-context-protocol-se...
Yeah, I had more luck with just giving an ai the openapi spec and letting it figure everything out. I like a lot about MCP (structure, tool guidance, etc), but couldn't it just have been a REST API and a webserver?
I think people often think of their specific use-case and tend to forget the bigger picture. MCP does not force one transport or the other and that is great—use any transport you want as long as it uses JSON RPC as the payload.
The two built in transports are also extremely minimalistic and for SSE transport use regular HTTP—no need for web sockets or other heavier dependencies because SSE events are lightweight and broadly supported.
Second that. A lot of our use cases are "remote tooling", i.e. calling APIs. Implementing an MCP server to wrap APIs seems very complex - both in terms of implementation and infrastructure.
We have found GraphQL to be a great "semantic" interface for API tooling definitions since GraphQL schema allows for descriptions in the spec and is very humanly readable. For "data-heavy" AI use cases, the flexibility of GraphQL is nice so you can expose different levels of "data-depth" which is very useful in controlling cost (i.e. context window) and performance of LLM apps.
In case anybody else wants to call GraphQL APIs as tools in their chatbot/agents/LLM apps, we open sourced a library for the boilerplate code: https://github.com/DataSQRL/acorn.js
Oh wow. Amazing. I did not think of that. I am not fan of GraphQL but you might be onto something here. I have not checked the code and perhaps this is not the right channel for this but my read is that this library allows any generic GraphQL server to exposed in this sort of way?
Exactly, any generic GraphQL server can be turned into a set of LLM tools with minimal overhead and complexity.
I am actually working on such a thing, and I want to get it righr. This is like RSS or Atom or Jabber or XMPP wars. Or OpenGraph vs Twitter’s meta tags etc. I want interoperability which is cool, but I also want it to seamlessly interoperate with human roles and services.
What is the best way to connect with you? I would like to discuss ideas and protocols if you’re up for that.
Exactly my points: https://taoofmac.com/space/notes/2025/03/22/1900
https://engineering.ramp.com/ramp-mcp
https://blog.cloudflare.com/remote-model-context-protocol-se...
"Tool calling" is just one part of MCP, there are more things like "Sampling" which allow the server itself to initiate stuff on the client. As for tool calling, having a layer like MCP makes sense because there a lot of things which don't have a REST-API + may need direct access to the computer (filesystem, processes, etc).
Examples:
* Running SQL commands on a DB or a Redis instance. * Launching Docker containers, SSHing to a server an running some command. * Reading a file and extracting relevant information from it, like OCR. * Controlling a remote browser using the WebDriver protocol, have some kind of persistent connection to a backend.
As for just pure REST-API usecases, I think MCP serves what Swagger/OpenApi-Spec are meant to do, i.e. enforce some kind of format and give each endpoint a "Name" + list of Params which the LLM can invoke. The issue is that there is no standardised way to pass these API specs to LLMs as tools (maybe something can be built in this space). In the future, I can easily see some kind of library/abstraction that allows an MCP server to parse an existing API spec file to expose those APIs as tools which can be combined with some local state on the computer to allow stateful interactions with a REST API.
I just made a tool which parses any OpenAPI spec to MCP spec: https://www.open-mcp.org (literally just deployed so I don't know if the DNS has propagated globally yet..)
I received a 500 response when I attempted to create an MCP server for an API.
I was using this URL: https://engineapi.moonstream.to/metatx/openapi.json
The response body:
Thanks, I just added support for relative URLs, try again. Your OpenAPI spec defines a relative base URL for the server /metatx but no domain. You can now specify the full base URL in your MCP client's environment variables:
`OPEN_MCP_BASE_URL="https://engineapi.moonstream.to/metatx"`
very cool, I tried to feed it the toolhouse.ai openapi spec and it worked VERY quickly!! wow
My bias is I generally think RPC is much nicer than REST. But what's kind of funny here is that we have
(1) an RPC to call a (remote) method called "tools/call", which is a method that
(2) calls a method called get_weather
Both methods have arguments. But the arguments of "tools/call" are called "params" and the arguments of "get_weather" are called "arguments".
I realize this is a common pattern when you have to shell out, e.g. in python's subprocess.run().
But it also seems like there could be a cleaner API with better types.
I don’t disagree. I fought this battle for a long time — ran a company where I tried to simplify SDK development by making every endpoint POST and JSON params; sorta like SOAP / just simple RPC. Why do you need all the HTTP methods when most SDKs simplify everything to .retrieve etc, why not name the endpoints that?
What I realized was that these specs are valuable because they’re stable over long periods of time and handle many sorts of edge cases. Also from a systems integration perspective, everybody already knows and is trained in them. Over many years I accepted the wisdom of commons.
A lot of tooling already exists to make development of these sorts of systems easy to implement and debug. Hence why I think for Remote MCP servers, HTTP as it exists is a great choice.
I don't feel that's really true, it's easy to forget how fast things have moved.
For a long time lots of servers didn't really support PUT or DELETE, and it was only the early 2010s that it became common.
It's still a problem sometimes that you have to explicitly enable them (I'm looking at you IIS + WebDAV).
PATCH wasn't even added till 2010 and you still don't see it commonly used.
Perhaps we have different understandings of 'stable' and 'many years'.
I also agree with you on RPC, it's pretty ridiculous that some guys tried to boil every single API down to essentially 4 verbs. I remember when Google went all crazy on implementing pure REST and their APIs were atrocious.
And everyone still goes along with it even though it clearly doesn't work, so you always end up with a mix of REST and RPC in any non-trivial API.
But pure RPC doesn't really work as then you have to change every call to a POST, as you mention. Which is also confusing as everyone is now used to using the really restricted REST CRUD interface.
So now pure REST sucks and pure RPC sucks. Great job HTTP standards team!
To be fair to them, I know it's hard and at some point you can't fix your mistakes. These days I guess I've just accepted that almost all standards are going to suck a bit.
ad hoc RPC[1] that involves JSON request/response payloads and is wed to HTTP transport is arguably worse than conforming to the JSON-RPC 2.0 specification[2].
[1] if it’s not REST (even giving a pass on HATEOAS) then it’s probably, eventually, effectively RPC, and it’s still ad hoc even if it’s well documented
[2] https://www.jsonrpc.org/specification
The big irony behind HATEOAS is that LLMs are the mythical "evolvable agents" that are necessary to make HATEOAS work in the first place. HATEOAS was essentially built around human level intelligence that can automatically crawl your endpoints and read documentation written in human language and then they scratched their head why it didn't catch on.
Only browser like clients could conform to HATEOAS, because they essentially delegate all the hard parts (dealing with a dynamically changing structureless API) to a human.
Well, like I wrote, "giving a pass on HATEOAS".
With e.g. JSON over HTTP, you can implement an API that satisfies the stateless-ness constraint of REST and so on. Without hypermedia controls it would fit at Level 2 of the RMM, more or less.
In that shape, it would still be a different beast from RPC. And a disciplined team or API overlord could get it into that shape and keep it there, especially if they start out with that intention.
The problem I've seen many times is that a JSON over HTTP API can start out as, or devolve into, a messy mix of client-server interactions and wind up as ad hoc RPC that's difficult to maintain and very brittle.
So, if a team/project isn't committed to REST, and it's foreseeable that the API will end up dominated by RPC/-like interactions, then why not embrace that reality and do RPC properly? Conforming to a specification like JSON-RPC can be helpful in that regard.
Yeah, I always thought MCP was a bit verbose. It reminds me of the WSDL and SOAP mess of the 2000s. Model tool calls are just RPCs into some other service, so JSON-RPC makes sense. Is there anything else has wide adoption and good client support? XML-RPC? gRPC? Protobufs? I mean, it shouldn't need extra libraries to use. You can handroll a JSON-RPC request/response pretty easily from any programming language.
Regarding the verbosity, yeah, it's interesting how model providers make more money from more tokens used, and you/we end up paying for it somehow. When you're doing lots of tool calls, it adds up!
Why is this get_weather location "New York" always an example when people talk about tool calling?
1/ pre-trained models don't know current weather
2/ easy enough for people to understand
Because if you can make it New York City, you can make it anywhere.
Totally agree - a well-defined REST API "standard" for tool listing and tool execution would have been much better. Could extend as needed to websockets for persistent connections / streaming data.
Maybe MCP was developed with AI. LLMs tend to be overly verbose
fully agree, and that's what we do at ACI.dev as a managed authenticated tool calling platform. https://www.aci.dev/ And we expose more tool discovery flexibility rather than just list_tools()
>And we expose more tool discovery flexibility rather than just list_tools()
Extremely curious about this as just directly listing all tools to an agent will obviously not scale well. What does the interface look like?
perhaps openai is the wrong tool for this thing.
I've been working on BLAH - Barely Logical Agent Host (https://github.com/thomasdavis/blah/blob/master/packages/cli...) for the past few weeks.
It is essentially a standard (has a schema) that has an ecosystem of tools around it.
(completely opensource, no protocol/bridge lockin, no vendor/provider lockin, no ide/client/auton lockin, http/sse/jsonrpc/whatever, local/remote, composable)
So far I'm categorically calling MCP a "bridge", because BLAH supports other bridges such as SLOP (https://github.com/agnt-gg/slop/blob/main/README.md) and conceptually OpenAPI (or simply HTTP) is a bridge.
An example blah.json looks like this
So blah can orchestra/compose any number of bridges, and it can list any tools it style/format of any bridge. (sorry that sounds so dumb)For example, you can run `blah mcp start --config blah.json`, and add that to your cursor/claude mcp servers. When you fetch the tools, it loops over all your tools in your blah.json and fetches them whether it is an mcp server, slop server or openapi, it's agnostic and will return a full list of tools pulling from all bridges.
And then you can do `blah slop start`, which will do the same, but the opposite, start a slop server but it will boot up mcp servers and serve them over http too.
So essentially a bridge/protocol agnostic system, you ask for a list of tools, and it traverses everything that can list tools and splats them all together.
That's a little of the main pitch but there are larger plans to try build an ecosystem like npmjs where there is a public registry of any tool (which are just functions at the end of the day). Clouldflare AI team is really getting it right now (https://blog.cloudflare.com/remote-model-context-protocol-se...), most people would rather just tools being hosted for them, and workers is perfect for that.
It also means you just have to add one MCP server and use one configuration file to manage your tools. (Also has way more control over logging which MCP devs would love)
---
And that all maybe sounds complicated, but it's meant to make things A LOT easier. The README.md is horrible, just lots of random ideas and my comment isn't much better, but I'm aiming to have an alpha version in a week or so. Would absolutely love feedback!
4.5 Deep Research Report on BLAH - https://gist.github.com/thomasdavis/3827a1647533e488c107e64a...
I agree, people don't want to manually add all MCP servers they want to connect to. I think we're headed in a direction where dynamic tool discovery will be important. E.g. I want to do "x" which requires doing "y" and "z". The client or server should then search for the tools (or agents as tools) that can do the job. So this would basically be a semantic search for which tools are most likely to do the job, then use those tools, and search for more tools if it needs to. RAG for tools, essentially. I wrote an article on how to give ChatGPT unlimited functions a year ago, where I implemented this method.
I basically created a vector database for functions, and created the store based on the tool description, then added the tool definition as metadata. Then for every request I ran a lookup for tools, added them to the tools list. Since tool definitions are added to the context we would have to do something like this at some stage when we want to implement a lot of tools.
https://blogg.bekk.no/function-retrieval-add-unlimited-funct...
This is very cool but definitely has the XKCD standards vibe [0]. If the industry is standardizing on MCP but then we decide it's not good enough, we just end up back where we started. I hope there's enough willpower (and low enough ego) to get to a really tight, single great implementation.
[0] https://xkcd.com/927/
Complete with the alt text mentioning USB, which is used in the MCP website to describe it. Someone else said it and I agree, it's not a good analogy. Most of what we do in software development is connecting things. Saying "this is like USB but for X" could cover a huge chunk of what software is.
Besides, this "think of" analogies kinda irk me because I don't want you to give me a mental image you think I can digest, I want to know how it works. Abstractions in software are great and all but the fact that for some reason most explainers have decided they should be opaque is very unhelpful when you're trying to learn.
Only a certain subset of developer spends most of their time "connecting things", and if that's the kind of developer you consider yourself, I'd be looking to either upskill or change professions as this will be the first kind of developer eliminated if we continue to see decent progress in automation.
Would disagree there — system integration probably accounts for like 90% of development work; just at different layers of abstraction.
It’s evergreen work that companies are endlessly trying to eliminate or automate yet keep running headfirst into.
Doesn't mean it's not all the same or boring drudge work :).
Though I disagree with GP's reply to you about being product-oriented and such - 90% of products are just "system integration" with some custom marketing graphics and a sprinkle of vendor lock in :).
Combination of standardization and AI will end in a great carnage of software developer jobs, as system integration is basically the poster child of a job that should not exist in ideal world - i.e. all problems are problems of insufficient automation or insufficient ability to cope with complexity. But there's only so much demand for R&D and creating bona fide new capabilities, and not everyone wants to be a manager or a salesperson...
IDK, might be really the time to pick some trade skills, as manual labor in the field is likely the last thing to be automated away.
I would urge you to not think this way: https://www.osmos.io/fabric
You probably should've disclosed that you are promoting your own company's AI product here...
I would still feel zero job security in such a position, and would be looking for work which is not only intellectually and creatively rewarding, but considerably more difficult to automate. Often this means becoming product-oriented or getting into leadership positions.
aha can't disagree with that sentiment, best I can do is not make the standard suck.
Ehh. Sometimes you don't want to have to have string builders to assemble REST calls.
> Think of MCP like a USB-C port for AI applications.
That analogy may be helpful for mom, but not for me as a software engineer.
To really understand MCP you need to think about application design in a different way.
In traditional applications, you know at design-time which functionality will end up in the final product. For example, you might bundle AI tools into the application (e.g. by providing JSON schemas manually). Once you finish coding, you ship the application. Design-time is where most developers are operating in, and it's not where MCP excels. Yes, you can add tools via MCP servers at design-time, but you can also include them manually through JSON schemas and code (giving you more control because you're not restricted by the abstractions that MCP imposes).
MCP-native applications on the other hand can be shipped, and then the users can add tools to the application — at runtime. In other words, at design-time you don't know which tools your users will add (similar to how browser developers don't know which websites users will visit at runtime). This concept — combined with the fact that AI generalizes so well — makes designing this kind of application extremely fascinating, because you're constantly thinking about how users might end up enhancing your application as it runs.
As of today, the vast majority of developers aren't building applications of this kind, which is why there's confusion.
I think this is a good explanation on the client side of MCP. But most developers are not building MCP clients (I think?). Only a few companies like OpenAI, Anthropic, Cursor and Goose are building MCP client.
Most developers are currently building MCP servers that wrap a 3rd party or wrap their own service. And in this case, they are still at deciding on the tools in design-time, not runtime.
Also I want to mention that both Cursor and Claude desktop don't support dynamic toggling on / off tools within a MCP server, which means users can't really pick which tools to expose to AI. It exposes all tools within a MCP server in current implementation.
The concept of design-time vs. runtime applies to both clients and servers.
I believe you're implying that server developers can focus less on this concept (or sometimes even ignore it) when building a server. This is true.
However, the fact that end-users can now run MCP servers directly — rather than having to wait for developers to bundle them into applications — is a significant paradigm shift that directly benefits MCP server authors.
I see what you mean. It is a paradigm shift indeed if you look from the user's perspective.
This a good characterisation of functionality MCP might enable. Thanks.
In your opinion, what percentage of apps might benefit from this model where end users bring their own MCP tools to extend the capabilities of your app. What are some good examples of this - e.g., a development tool like Cursor, WindSurf likely apply, but are there others, preferable with end users?
How is the user incentivized to upskill towards finding the right tool to "bring in", installing it and then using it to solve their problem.
How do we think about about the implications of bring your own tools, knowing that unlike plugin based systems (e.g,. Chrome/extensions), MCP servers can be unconstrained in behaviour - all running within your app
> In your opinion, what percentage of apps might benefit from this model where end users bring their own MCP tools to extend the capabilities of your app.
Long term close to 100%. Basically all long-running, user-facing applications. I'm looking through my dock right now and I can imagine using AI tools in almost all of them. The email client could access Slack and Google Drive before drafting a reply, Linear could access Git, Email and Slack in an intelligent manner and so on. For Spotify I'm struggling right now, but I'm sure there'll soon be some kind of Shazam MCP server you can hum some tunes into.
> How is the user incentivized to upskill towards finding the right tool to "bring in", installing it and then using it to solve their problem.
This will be done automatically. There will be registries that LLMs will be able to look through. You just ask the LLM nicely to add a tool, it then looks one up and asks you for confirmation. Running servers locally is an issue right now because local deployment is non-trivial, but this could be solved via something like WASM.
> How do we think about about the implications of bring your own tools, knowing that unlike plugin based systems (e.g,. Chrome/extensions), MCP servers can be unconstrained in behaviour - all running within your app
There are actually 3 different security issues here.
#1 is related to the code the MCP server is running, i.e. the tools themselves. When running MCP servers remotely this obviously won't be an issue, when running locally I hope WASM can solve this.
#2 is that MCP servers might be able to extract sensitive information via tool call arguments. Client applications should thus ask for confirmation for every tool call. This is the hardest to solve because in practice, people won't bother checking.
#3 is that client applications might be able to extract sensitive information from local servers via tool results (or resources). Since the user has to set up local servers themselves right now, this is not a huge issue now. Once LLMs set them up, they will need to ask for confirmation.
> local deployment is non-trivial, but this could be solved via something like WASM.
This is why I started working on hyper-mcp which use WASM for plugin development & OCI registry for hosting. You can write Dockerfile for plugin packaging
You develop plugins in any language you want as long as it supports WASM
https://github.com/tuananh/hyper-mcp
I can’t express how much I agree with your perspective. It’s a completely different/total shift in how we might deliver functionality and… composability to users.
Well said.
Oh, it’s the new HATEOAS? A pluggable framework for automatic discoverability of HTTP APIs is incredibly useful, and not just for AI :)
Unfortunately, MCP is not HATEOAS. It doesn't need to be, because it's not web-like. I wish it were.
HATEOAS is great for web-like structures because in each response it not only includes the content, but also all actions the client can take (usually via links). This is critical for architectures without built-in structure — unlike Gopher which has menus and FTP and Telnet which have stateful connections — because otherwise a client arriving at some random place has no indication on what to do next. MCP tackles this by providing a stateful connection (similar to FTP) and is now moving toward static entry points similar to Gopher menus.
I specifically wrote about why pure HATEOAS should come back instead of MCP: https://www.ondr.sh/blog/ai-web
No, you can't understand it until you understand that the world isn't all webshit and not everything is best used via REST.
(Not even webshit is best used by REST, as evidenced by approximately every "REST" API out there, designed as RPC over HTTP pretending it's not.)
Nevertheless, MCP is a “webshit” protocol (even in stdio mode), so if web protocols are unsuitable for your problem, MCP would be as well.
Isn't this just the same paradigm as plugins?
Similar, but one level higher.
Plugins have pre-defined APIs. You code your application against the plugin API and plugin developers do the same. Functionality is being consumed directly through this API — this is level 1.
MCP is a meta-protocol. Think of it as an API that lets arbitrary plugins announce their APIs to the application at runtime. MCP thus lives one level above the plugin's API level. MCP is just used to exchange information about the level 1 API so that the LLM can then call the plugin's level 1 API at runtime.
This only works because LLMs can understand and interpret arbitrary APIs. Traditionally, developers needed to understand an API at design-time, but now LLMs can understand an API at runtime. And because this can now happen at runtime, users (instead of developers) can add arbitrary functionality to applications.
I hate plugging my own blog again but I wrote about that exact thing before, maybe it helps you: https://www.ondr.sh/blog/thoughts-on-mcp
> And because this can now happen at runtime, users (instead of developers) can add arbitrary functionality to applications.
I don't understand what you mean by this. Currently without MCP a server has an API that's documented and to interact with it(thus provide "arbitrary functionality") you call those APIs from your own application code(e.x. python script).
With MCP an LLM connected to your application code calls an API that's documented via MCP to provide "arbitrary functionality".
How are these different, and how does MCP allow me to do anything I couldn't before with API access and documentation? In both cases the application code needs to be modified to account for the new functionality, unless you're also using the LLM to handle the logic which will have very unpredictable results.
>In both cases the application code needs to be modified to account for the new functionality, unless you're also using the LLM to handle the logic which will have very unpredictable results.
In the case of MCP, no application code is modified. You first ship the application and then functionality is added. Using plain APIs, it's the other way around. That's the difference.
I don't understand this at all.
If my application performs some function dependant on data from an API(e.x. showing tax information, letting a user input tax information, and performing tax calculations and autocomplete), how do I extend that UI easier with MCP than with an HTTP REST API.
Even with MCP I need to update my application code to add UI elements(inputs, outputs) for a user to interact with this new functionality, no?
No, MCP does not include any concept of UI (yet). Tool results are usually text only, although there is also the abstraction of an Image (which can be displayed as clients as decide to, e.g. inline).
So no application code needs to be changed because no application code exists.
Isn't that like saying you don't need to modify application code with an REST API if your "application" is just a list of instructions on how to use wget/bash to accomplish the task?
This sounds like a security nightmare.
As it currently stands, MCP is absolutely a security nightmare. Combine this with a general lack of appreciation for security culture amongst developers, and the emerging vibe coding paradigm where non-security-minded people automatically generate and fail to properly audit production-facing code, and it's a disaster waiting to happen.
Feels like we've slid back into the 90s in this regard. Great time to be a security researcher!
> Feels like we've slid back into the 90s in this regard.
Thank $deity. 90s and early 2000s were the times software was designed to do useful work and empower users, as opposed to lock them into services and collect telemetry, both of which protected by the best of advancement in security :).
I'm only half-joking here. Security is always working against usefulness; MCP is designed to be useful first (like honest to $deity useful, not "exploit your customers" useful), so it looks like security nightmare. Some of that utility will need to go away, because complete lack of security is also bad for the users - but there's a tradeoff to be made, hopefully one that doesn't just go by modern security zeitgeist, because that is already deep into protecting profits by securing services against users.
> a general lack of appreciation for security culture amongst developers, and the emerging vibe coding paradigm where non-security-minded people automatically generate and fail to properly audit production-facing code
There is also a general lack of consideration of who is being protected from whom, and why in the security culture. MCP, vibe coding, and LLMs in general are briefly giving end-users back some agency, bringing back the whole idea of "bicycle for the mind" that was completely and intentionally destroyed when computing went mainstream. Let's not kill it so eagerly this time.
A non-exhaustive list of concerns:
- How does a consumer of a remote MCP server trust that it is not saving/modifying their data, or that it is doing something other than what it said it would?
- How does a consumer of a local MCP server trust that it won't wreck their machine or delete data?
- How do servers authorize and authenticate end users? How do we create servers which give different permissions to different users?
These are examples of things which must be done right, and sacrificing user security in order to achieve market dominance is ethically bankrupt. Pedestrians don't know exactly which regulations serve them when a bridge is built, so we don't expect pedestrians to be able to stop corruption and laziness in civil engineering. The same should be true for mass infrastructure; we have a duty as engineers to make the right call.
> MCP, vibe coding, and LLMs in general are briefly giving end-users back some agency, bringing back the whole idea of "bicycle for the mind"
I love what software might look like in 15 years. I don't plan to kill that. I want to protect it, and also protect everyone involved.
would love your thoughts on this: https://blog.cloudflare.com/remote-model-context-protocol-se...
It’s pretty astounding to me that this aspect of MCP is not mentioned more. You’re putting a LOT of trust in both the model and the system prompt when you start attaching MCPs that provide unfettered access to your file system, or connect up to your REST API’s POST endpoints.
(That being said, I have to admit I’ve been writing my own powerful but extremely dangerous tools as an experiment (e.g. run arbitrary Python code on my machine, unsandboxed) and I have to admit the results have been incredibly compelling.)
I tend to agree with this.
No, MCP's have NOT Won (Yet) https://newsletter.victordibia.com/p/no-mcps-have-not-won-ye...
agreed. this sounds useless at the moment unless you’re sand boxing it in a throw-away VM lol. Scary!
I really enjoyed both your blog posts. You've clearly thought about this a lot and explained things well. I'd love to subscribe to be updated on your next post (even if it's not for months/years). Any chance you could add an RSS feed to your blog?
Thanks. Added RSS, but WC3 shows some errors. I'll move to plain markdown when I have more time, then this will be easier.
the blog is hosted on substack which supports feeds.
https://newsletter.victordibia.com/feed
You might be able the say the user could "plug in" the new functionality. Or it allows them to "install" a new "application"?
So MCP to an application is like how a WebDriver interface is to a Web browser?
The full quote is better:
No, it's actually a lot worse. "USB-C port for AI applications" sounds like something written by an insane person.
I want to know in which way is USB-C applicable here. The complicated plug that's actually 30 different protocol's that's difficult understand what capabiltiies a plug/cable actually has?
Yes. 99% of that complexity is on the side of implementers - where it should be - and for actual use, approximately everything works well with everything else; specifics matter mostly when you're trying to plug devices that exercise the limits of advanced capabilities. Which sucks, yes, but mostly because implementers/vendors made it this way (would it hurt y'all to label your cables and devices properly, correctly and visibly?!).
Maybe they used an LLM to explain it. Gemini in particular is obsessed with these utterly useless analogies for everything, when I would prefer something closer to Wikipedia with more context. (Needless to say, I currently don't find LLMs useful for learning about things. That's a shame because that use case feels promising.)
I saw this ChatGPT-created analogy on a JS subreddit the other day:
> Imagine you have a robot in a room, and this robot can perform actions like turning on a light, opening a door, or picking up objects. Now, if you want to tell the robot to do something, you usually say something like, "Robot, pick up the pen!" or "Robot, open the door."
> In JavaScript, ‘this’ is like the "robot" in the room
Terrible.
LLMs are like an unlimited, poorly written encyclopedia. Often inaccurate or not entirely helpful, but will get you enough of an idea to find better sources. Sort of solving the "I don't know what I don't know" gap.
In this regard, they have been extraordinarily fruitful for my research and studies.
I thought this was a "your mom is compatible with everyone" joke
[flagged]
I don't know whether to laugh at the joke or be triggered that USB takes three turns to insert.
It's trying to say "you can plug lots of things into this in a standardized way."
https://norahsakal.com/blog/mcp-vs-api-model-context-protoco...
The closest software analogy I’ve heard is like passing around a callable/function with a standard interface. An LLM can call the callable and work with the returned data without needing to go back and forth between your application logic.
The weather data example in their documentation makes it really simple to grasp how it works as an interface for models:
https://modelcontextprotocol.io/quickstart/server
I don't think it's terribly difficult to drill down into their GitHub to see what's happening under the hood if you need that level of detail.
Well its directly from the documentation written by the SWEs that built the protocol...
https://modelcontextprotocol.io/introduction
MCP is very similar in protocol to LSP.
In LSP, you have editor (vscode, neovim), and language servers (rust, typescript, python).
In MCP, you have the client (chat window), and servers (providing context, tools, and prompts).
I prefer this interpretation:
MCP Isn’t the USB-C of AI — It’s Just a USB-C(laude) Dongle
https://dev.to/internationale/mcp-is-not-ai-usb-c-its-usb-cl...
The illustrations are on their official website.
I find it hard to respect a company that invented dongle and claims to have invented USB
> MCP, despite its open-source claim, heavily relies on proprietary interfaces from Anthropic's Claude model. Thus, the proclaimed openness is surface-level at best, creating subtle but significant barriers within the ecosystem.
This strikes me as fundamentally untrue, but I'd love to see an example of this in the source code or documentation.
What’s wrong with this analogy?
It’s a common set of APIs/protocols that includes a way to share data, capabilities, etc.
That’s pretty much exactly what USB is.
This is what we used to just call "standards", but apparently we need analogies now in order to explain standards to new developers.
but it’s technically not a standard yet. Or not blessed as one by any neutral body or consortium etc.
It’s quickly becoming a de facto standard though, now that OpenAI has added it to their SDK.
It’s likely to be used to create a standard though (like with QUIC and HTTP3)
This is just an ontological issue. Is it a standard because it is designed to be one, or is it only a standard once it actually fulfills its role and is recognized as a standard? That's something we could debate all night. :)
Not only that, the P for "protocol" already gives that.
they probably mean it’s going to be difficult early on to find standards compliant implementations. and then always very annoying to make sure all involved components support the correct feature set.
A good analogy I think for those in Trading might be FIX or FpML. Those protocols and standards have revolutionized electronic trading.
That's the same analogy anthropic uses to describe it.
I see it as service discovery for AI applications
Because everyone knows the usb-c protocol
Do they? Like actually, know it cover-to-cover, or do they just know of it? Because the first thing to point out is that USB-C isn't a protocol, it's a connector standard.
Thinking in terms of MCP, will change your thought process to design your application in different way.
What's so hard for them to just say "it's a standard"? Why do we need to mention USB? Or USB-C at that, which just confuses the message even more?
Do modern developers not know what "standards" means? Is this marketing slop or did an engineer seriously write that for other engineers?
It's a beautiful and deep analogy, and works for both software engineer and their mom.
Mom-level: ChatGPT ("or that other ChatGPT with a human name, Klaus I think? No, it was Claude.") can use software that says it supports MCP. If it says "MCP", I can use it with my AI.
Software dev level: MCP servers and MCP clients should just work, like USB. I don't really have to care about this, I expect them to connect just fine. Like with USB, there's a crap ton of complexity dumped on implementers of the spec to make it work reliably and cheaply - as it should be. That's literally their job: to take all the "secret sauce" that makes their product "special" and hide it behind a standard, because they're not special and nobody cares.
As another software engineer: if it ain't USB, I ain't buying, because I'm too old to deal with the proprietary per-device unique connectors bullshit. The standard exists so I don't have to think about it.
Honestly I’m now even more confused
It's got an open socket at the bottom, that accepts many different plugs.
I don't know if GP understands that his phrasing might not be so flattering for his mother ))
You spend time with some weirdly technical moms.
I am really struggling with what the value-add is with MCP. It feels like another distraction in the shell game of contemporary AI tech.
> MCP is an open protocol that standardizes how applications provide context to LLMs.
What is there to standardize? Last I checked, we are using a text-to-text transformer that operates on arbitrary, tokenized strings. Anything that seems fancier than tokens-to-tokens is an illusion constructed by the marketing wizards at these companies. Even things like tool/function calling are clever heuristics over plain-ass text.
> Currently, the MCP spec defines two kinds of servers, based on the transport mechanism they use: ...
This looks like micro services crossed with AI. I don't think many are going to have a happy time at the end of this adventure.
If you're interested, I'd encourage you to implement an MCP integration and see if you change your mind.
For instance, I have a little 'software team in a box' tool. v1 integrated github and three different llms manually (react + python backend). This is fine. You can call github commands via CLI on the backend, and add functionality somewhat easily, depending on the LLM's knowledge.
Pain points -- if you want workflow to depend on multiple outputs from these pieces, (e.g. see that there's a pull request, and assess it, or see that a pull request is signed off on / merged, and update something) -- you must code most of these workflows manually.
v2, I wiped that out and have a simple git, github and architect MCP protocol written up. Now I can have claude as a sort of mastermind, and just tell it "here are all the things you can do, please XXX". It wipes out most of the custom workflow coding and lets me just tell Claude what I'd look to do -- on the backend, my non-LLM MCP server can deal with things it's good at, API calls, security checks, etc.
So is the MCP server acting like a middleman between the llm and the application you want to control?
Like, could I give the MCP server the ability to say exec Unix code on my machine and then tell the LLM "here's the MCP server, this function can execute Unix code and get back the response".
Then I can tell the LLM, "create an application using the MCP server that will listen to a GitHub webhook and git pull when the webhook hits and have it running" then the LLM would generate the commands necessary to do that and run them through the MCP server which just executed the Unix code. And viola?
I've gotten an llm to create files and run system commands for me.
Is that the most barebones application?
That sounds like v1 was "tool calls llm", while v2 is "llm calls tool"?
The fact that the tool call is via mcp and not in-process function call seems to be an implementation detail?
first sentence sounds right to me.
“Implementation detail” is doing a lot of work in the second sentence, though. There are whole startups like langchain that were trying to build out a reasonable agent framework integrated in such a way that the LLMs can drive. MCP makes that really easy — LLM training just has to happen once, against MCP spec, and I get client and LLM support for an iterative tool use scenario right in the LLM.
Do you have the code available anywhere? I'm working on the same thing to learn how to utilize MCP, I'd love to see how someone else went about it.
this will break, kill your computer and probably result in loss of life. Just saying. :)
That said, here's a gist: https://gist.github.com/vessenes/ec43b76965eed1b36b3467c598b...
> What is there to standardize?
At a high level, the request format and endpoints. Instead of needing to write a bespoke connector for every type of context that matches their preferred API standards, I just tell my client that the server exists and the standard takes care of the rest.
Do you have similar doubts about something like gRPC?
> This looks like micro services crossed with AI.
Seems like a cynical take with no substance to me. What about a standard request protocol implies anything about separation of concerns, scaling, etc?
> At a high level, the request format and endpoints.
I think we fundamentally disagree on what "request format" means in context of a large language model.
Because it's not a request format for LLMs, it's a request format for client software that is instrumenting LLMs. If you make a connector to say HomeAssistant to turn on/off your lights you're exposing a tool definition which is really just a JSON schema. The agent will present that tool to the LLM as one it's allowed to use, validate that the LLM matched your change_light_state tool schema and send off the appropriate API call to your server.
The spec is genuinely a hot fucking mess that looks like a hobby project by an overeager junior dev but conceptually it's just a set of JSON schemas to represent common LLM things (prompts, tools, files) and some verbs.
The useful content of the spec is literally just https://github.com/modelcontextprotocol/specification/blob/m... and even then it's a bit much.
Literally every protocol ever written is “clever heuristics over plain-ass {bits|bytes|text|etc}”
I would think of MCP as a "plugin" for AI.
Right now your typical interaction in chat is limited with some exceptions of out of box tooling that most current platforms provide: file attachment, web search, etc.
MCP is a way to extend this toolbox, but the cooler thing is AI will be able to determine _at inference time_ what tools to use to fulfill the user's prompt.
Hope this helped!
More like a "plugin system" than a "plugin"
Well, you should check again, because it hasn't been text to text for a while. There are multimodal models now.
If we want to get pedantic, in context of practical transformer models it has never been text to text. It has always been tokens to tokens. The tokens can represent anything. "multimodal" is a marketing term.
You could say the same thing about almost any protocol, e.g. HTTP, which runs on arbitrary streams of bytes over TCP; and the headers, methods and status codes are just illusions on top of that.
Big question in my mind was if OpenAI was going to formally endorse this (since it was created by Anthropic) but we have our answer.
MCP is now the industry standard for connecting LLMs to external tools.
> MCP is now the industry standard for connecting LLMs to external tools.
No it isn't. We're still five or ten years away from real standards.
(Anyways it's clear that the future is smaller self-hosted LLMs, so whatever standard eventually emerges will be based on that paradigm.)
Sure, like how we all self-host our own email servers and photo albums? Honestly, I think you’re about as wrong as you could possibly be, both on timelines, and in that I’d argue the arc of consumer tech adoption bends towards centralisation most often.
Standards are already emerging, including MCP, and to say that simply because they’ll evolve and be replaced over time means they’re not ‘real’ now is ridiculous. Look at the early internet and web as examples.
Local models, even accounting for reasonable progress and device performance improvements, will always, inherently, be behind the eight ball compared to SOTA models. While they may be sufficient for the low hanging fruit, I’d not bet against the frontier models being every bit as compelling relatively speaking.
Using weasel words like ‘real’ and ‘x is the future’ is astoundingly arrogant, and anyone claiming with confidence that they’ve got any idea where we’re heading is almost assuredly wrong.
1) It isn't a standard yet, but what else apart from filesystem-mcp can be used for prompts like "write me README.md for this repo" (like really produce the file)
2) For me it is not clear the future is smaller self-hosted LLMs. As of today, most useful for me is to use best models, and those are not self-hosted.
Once we get used to the fact that LLMs exist they won't be sold on the gee-whiz "wow, a talking assistant just like in my sci-fi movies!" factor.
They'll be used for particular language classification and search tasks, and for that you'd want several lighter, faster, cheaper and more specialized models. Not one with an arbitrary "best" score that's based on tricking the Turing test.
so we no longer need langchain and stuff like that, that's a win. But MCP also feels a bit overrated:https://www.lycee.ai/blog/why-mcp-is-mostly-bullshit
I feel like that article doesn't really live up to its title. At the end, its basic point is that MCP isn't a magic bullet (I don't think anyone claimed it was?) and that it has a lot of hype. It also makes it clear why MCP is good (ie don't need to rely on LangChain). Feels like its title should be "Why MCP is a Good Step but Doesn't Solve Agents" or something. But then, it wouldn't enable the millenial urge to use "shit".
I could not find the actual criticism in that article. What's the problem with MCP again? It's the first standard for agents.
http endpoint + function calling can do what MCP do, this extra bad named layer is just jargon festish
Okay, but we should have a standard around that, right? Something like... a protocol?
the problem of agents is not the lack of standards, but reliability (reliability of tool use and reliability of outcomes). MCP does not solve any of that.
Standards might not have been _the_ problem, but they were _a_ problem. Before MCP I couldn't distribute a tool call that could be configured by end-users to be used with multiple mainstream clients.
That is not mentioned in the article. I am just becoming familiar with MCP myself so I suggest raising the issue: https://github.com/orgs/modelcontextprotocol/discussions
This is just moving the goalposts, MCP is not supposed to solve every problem with agents. It's meant to make it easier to provide easier, standardised ways for LLMs to interact with external tools, which it has done. Reliability is a completely different problem.
That article seems to miss the point by being incurious about _why_ there is hype around MCP instead of LangChain, LangGrah, SmolAgents, LlamaIndex, etc.
We've had tool call frameworks before, but we haven't had a way of making tools that our clients actually talked to. There was no way to build tools that other people could download and run locally without getting them to switch to a client that baked those tools in. It's like the difference between static linking and dynamic linking, but for tool calls.
Tool calls in any of the agent frameworks are just wrappers around native functions.
MCP let's you handle the processing outside of the agent context, redistribute tools independently, and provide them as either private or public hosted services.
Basically, add an HTTP layer on the existing concept of tools. It is not a replacement for a framework, it is an enhancement of a well established pattern.
> That article seems to miss the point by being incurious about _why_ there is hype around MCP instead of LangChain, LangGrah, SmolAgents, LlamaIndex, etc.
The VCs that were invested in AI companies (like Cursor) would of course need to hype something up like MCPs to get us to build them as little of those tools did not exist.
Cursor already makes $100M+. So why not get behind and integrate this chosen standard to make even more money with more MCP servers.
The last ingredient is to hype it all up on the internet to get everyone building.
A win for the VCs regardless even though it was suspiciously orchestrated as soon as Cursor integrated it.
MCPs aren't specific to Cursor. Rather, they enable any IDE to become a Cursor competitor.
Example: JetBrains released an MCP server plugin for their IDEs recently and it enables Claude Desktop to seamlessly use the IDE for reading and writing files and even compiling or running tests against it.
And that's just one example; there are MCP servers for anything from VSCode to Emacs already. That means almost anyone can now use LLMs to generate code in their IDE of choice, just as they would do with Cursor.
In fact, MCPs are posing a threat to many startups, especially the "wrapper" ones.
I too feel it's bad that companies take VC money and build open standards which let me build faster and target more providers. Seriously, what? I struggle to understand the mindset of someone frequenting HN who can say unironically that "getting everyone building" is a bad outcome.
I'd like some more of that getting everyone building please.
> But MCP also feels a bit overrated:
VCs invested in AI and agentic companies needed a way to get you guys to accelerate agents this year.
So why not "create" artificial hype for MCPs on the internet, since there were little to no MCP servers for LLMs to use despite it being several months old (November 2024) until Cursor integrated it.
This is the true reason why you see them screaming about MCPs everywhere.
So the main criticism is a borderline conspiracy theory about VC's creating artificial hype for it?
Hype isn’t free. Maybe the benefit is mutual, but I can’t tell how Anthropic gets paid.
Anthropic subsidizes an open standard, but proprietary extensions later emerge that lock you into servers from their marketplace or something? I need a sociopath to help me understand this.
The Anthropic models are running underneath everything (Claude Code, Windsurf, Cursor, etc). Whenever someone is using MCP they (in the generalized case, until now) ultimately end up using Anthropic as their LLM and Anthropic gets paid whenever someone does that.
This is literally not true. You can leverage MCP using any model. Even some of the IDEs you mention let you leverage MCP using many model providers.
There's already like a half dozen such "marketplaces" and they all ultimately point to open source repos. If the goal was to lock people in, they did a bad job of it.
there's a reason there's MCP plugins for LangChain. Some companies will need massively customized workflows that LangChain is appropriate for, where it only needs to dig into a couple potentially publically accessed MCPS for things.
I could see a future where companies have their developer portal where now they have their APIs document, the pretty in swagger, the samples, etc, but they'll have a MCP endpoint (potentially), where they're safely exposing the data to an LLM. Your langchain node step to to get context, could call out to some of these hosted/shared mcps where you do standard stuff, like post to a Slack channel, grab some data from a SFDC instance, etc....
I hoped OpenAI would support OpenAPI for connecting to tools. Having created a couple of MCP servers, it feels like a less flexible and worse documented API to me. I can’t really see anything that is made better by MCP over OpenAPI. It’s a little bit less code for a lot less options. Give it some time and it will also get Swagger built in.
It’s solving a problem that was already robustly solved. So get we go with another standard.
> I can’t really see anything that is made better by MCP over OpenAPI
Well it’s transport agnostic, for one.
I think a big part of it is defining a stateful connection and codifying the concepts of prompts and tools.
Another issue with OpenAPI / swagger is that you still need to create a client per API, but with MCP it’s all uniform.
transport argument is irrelevat when http can be both TCP and UDP, and even if you wanna do one protocol, it can be proxied/tunneled via another protocol transparently via VPN/wireguard/proxy.
so transport protocol is moot, especially from latency perspective when most time is spent doing AI inference (seconds) rather than passing packets (milliseconds).
I really wish OpenAI just embraced OpenAPI and that would have instantly gained millions of existing sites available to ChatGPT with zero code change.
It's transport-agnostic in the sense that it works locally (over stdout), not just remotely. It's not just for web-services. That's why HTTP isn't baked into this.
HTTP also works locally(over local files including stdin/stdout), not just remotely.
I feel like we should have transport agnostic RPC by now, GRPC? And MCP is stateless too. And you don't have to create a client per API, it's up to implementation.
Are we reading the same documents? MCP implementations are all websockets so it's not really transport agnostic. They try to talk about how you can use other transports but its just that it's JSON-RPC and if you're willing to code both ends you can do whatever… which is always true. And MCP is explicitly a stateful protocol [1].
https://spec.modelcontextprotocol.io/specification/2025-03-2...
* JSON-RPC message format
* Stateful connections
* Server and client capability negotiation
There's a draft [1] maybe about resolving this.
https://github.com/modelcontextprotocol/specification/pull/2...
https://spec.modelcontextprotocol.io/specification/2025-03-2...
They mention stdio specifically under the transport section of the spec.
Most protocols are transport agnostic, but http APIs tend to require HTTP methods. Http itself is transport agnostic, but truthfully all we’re doing is shuffling bytes around.
If you look at the stateless examples in that PR, they both assume some state (specifically the capabilities) and just behave accordingly.
To get the full features of the protocol (like notifications) a stateful connection would still be required.
I think MCP is a layer higher than grpc. MCP can be implemented on gRPC
Mcp is definitely not stateless. It’s explicitly stateful…
See the 2nd bullet where it says “stateful connections” [1]
And I was saying that with OpenAPI, you need a client per API, or at least a series of http api calls.
1. https://spec.modelcontextprotocol.io/specification/2025-03-2...
Higher in what way?
But HOW is it stateful? That "mandate" the only occurence of that string "state" in that document.
Also
> Higher in what way?
Higher as in at a higher level in the network stack (not exactly, I don’t think, but lower on the same level)
Higher as in you can implement MCP on top of grpc.
You can’t implement grpc in mcp, that doesn’t make sense, because grpc is at a lower level, so to speak, in the network stack.
“That document” is the MCP spec. What is says _is_ MCP, regardless of your understanding of it.
It’s not a “mandate” it’s a specification for how the protocol works. If the connection isn’t stateful, then it isn’t adhering to the specification.
I mean also like… how is it stateless? For both example transports (stdio and SSE) a connection must be maintained.
ANY connection must be initialized via an MCP message and both server and client must negotiate capabilities.
Those capabilities must be honored through the entire lifetime of the connection.
That alone is state.
I suggest you read the spec…
Whatever the current state, if everyone throws their shoulders behind a common interface, we all win.
There's already swagger MCP service out there, I don't know how production ready it is, but I saw something the other day when searching through GitHu. One of several implementations: https://github.com/dcolley/swagger-mcp
Emcee is a good implementation of this.
https://github.com/loopwork-ai/emcee
GraphQL looks like an even better choice - it really looks like they re-invented the wheel here.
Can't I do function calling in OpenAPI? I also feel like MCP is reinventing the wheel.
I have been converting OpenAPI documents into function calling schemas and doing tool calling since function calling first came out in 2023, but it's not easy to recreate a backend server to fit MCP.
Also, these days, I'm making a compiler-driven function calling specialized framework, but I'm a little cautious about whether MCP will support it. It enables zero-cost tool calling for TypeScript classes based on the compiler, and it also supports OpenAPI.
However, in the case of MCP, in order to fit this to the compiler-driven philosophy, I need to create a backend framework for MCP development first, or create an add-on library for a famous framework like NestJS. I can do the development, but there's so much more to do compared to OpenAPI tool calling, so it's a bit like that.
How should an MCP server like git work in your opinion? Should it then be written as a FastAPI server so that you have an openapi spec instead of just a CLI?
https://github.com/modelcontextprotocol/servers/blob/main/sr...
You’re way over thinking the use cases for MCPs. That tells me you should stick to functions.
> That tells me you should stick to functions.
probably we all should ¯\_(ツ)_/¯
[dead]
They’re all in. They announced they’ll add support for it in the desktop app and the API in the coming months: https://x.com/OpenAIDevs/status/1904957755829481737
I'm surprised this was announced in a random tweet instead of a blog post with a release roadmap or something like that.
because its a lil embarrassing oai didnt come up with it
"Think of MCP like a USB-C port for AI applications."
Given the enormous amounts of pain I've heard are involved in actually implementing any form of USB, I think the MCP community may want to find a different analogy!
Since I've worked with the official MCP SDK, I find this analogy quite accurate
I assume they're (for now at least) targeting the old HTTP+SSE version of MCP, and not the new Streaming HTTP version? https://github.com/modelcontextprotocol/specification/pull/2...
There's some other goodies too. OAuth 2.1 support, JSON-RPC Batching... https://github.com/modelcontextprotocol/specification/blob/m...
What are people using MCPs for? I search on youtube and see a lot of videos explaining how MCPs work, but none showing practical uses for a programmer (aside from getting the weather via cursor).
I have two that I use a lot: - Postgres one connected to my local db - A browser (Playwright) That way I can ask cursor something like: "Find an object with xxx property in the db, open its page in the browser, fix console errors" And it's able to query my db, find relevant object, open the browser, check logs, fix the code based on errors.
Even simpler stuff: - copying pasting a broken local url in cursor, and asking it to fix all console errors. Works really well. - or when you have a complex schema, and need to find some kind of specific record, you can just ask cursor "find me a user that has X transactions, matches Y condition, etc..". I found it much faster than me at finding relevant records
I only use one regularly, but I use it a lot. (Supabase)
Example use case: https://news.ycombinator.com/item?id=43466434
I think I’m starting to see the potential.. So I could MPC cursor to my local Postgres (or, after some practice to build confidence, prod Postgres). Then use cursor to help debug.
This sounds risky but very useful if it works as intended!
Yes, I have used that workflow to fix a tricky data corruption issue earlier this week.
A buggy feature left DB in invalid state, I described the issue to Claude + Postgres MCP to both query the DB to analyze and then generate SQL scripts to fix, and validation and rollback scripts. Easy enough to do without the tooling... but with the tooling, it took probably a quarter or less of the time.
Is this not just hiding the "complexity" of SQL behind an LLM and hoping for the best?
If you know SQL and know what you're trying to find, what can the LLM do quickly that you couldn't just constructing a query to get what you want?
Alternatively if you don't know SQL, aren't you never going to learn it if every opportunity you have you bust out an LLM and hope for the best?
AS far as risk, I cannot imagine using an MCP with write capabilities to a DB, the Supabase one is read-only, which is perfect.
I mainly use simple integrations:
- fetch, essentially curl any webpage or endpoint
- filesystem, read(and occasionally write) to local disk
- mcp-perplexity, so I can essentially have Claude sample from perplexity's various models and/or use it for web search. Somewhat superseded by Claude's own new web search capability, but perplexity's is generally better.
If you want to try out mcp (model context protocol) with little to no setup:
I built https://skeet.build/mcp where anyone can try out mcp for cursor and now OpenAI agents!
We did this because of a painpoint I experienced as an engineer having to deal with crummy mcp setup, lack of support and complexity trying to stand up your own.
Mostly for workflows 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 * Find a bug a create a linear issue to 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 code * Postgres or MySQL schemas for rapid model development
Everyone seems to go for the hype but ease of use, practical pragmatic developer workflows, and high quality polished mcp servers are what we’re focused on
Lmk what you think!
This looks super cool and I can see myself using this!
Although the name is a bit unfortunate.
my favorite is implementing issues from linear
Call it a protocol and suddenly it sounds like a foundational technology. Nah, it's just a fancy JSON schema that lets LLMs play hot potato with metadata.
Shamelessly promoting in here, I created an architecture that allows an AI agent to have those so called "tools" available locally (under the user control), and works with any kind of LLMs, and with any kind of LLM server (in theory). I've been showing demos about it for months now. Works as a middle-ware, in stream, between the LLM server and the chat client, and works very well. The project is open source, even the repo is outdated, but simply because no one is expressing interest in looking into the code. But here is the repo: https://github.com/khromalabs/Ainara. There's a link to a video in there. Yesterday just recorded a video showcasing DeepSeek V3 as the LLM backend (but could be any from OpenAI as well, or Anthropic, whatever).
The lack of interest may be from the crypto aspect:
> While the project will always remain open-source and aims to be a universal AI assistant tool, the officially developed 'skills' and 'recipes' (allowing AI to interact with the external world through Ainara's Orakle server) will primarily focus on cryptocurrency integrations. The project's official token will serve as the payment method for all related services.
Thank you for the feedback... actually I need to update that, the crypto part of my project will be closed source (an specific remote server) but the idea behind the project itself is universal and open since the very beginning, I already developed dozens of skills including a meta-search engine (searches in several engines at once and combines results dynamically, all balanced by the AI) which are open source as well. Crypto just kind of showed itself as way of funding project, with no strings attached, and till this very day no one else showed up.
I'm new to "MCP"... It says here that even IDE plug into this MCP server [1], as in you don't edit files directly anymore but go through a client/server?
It wasn't bad enough that we now run servers locally to constantly compile code and tell us via json we made a typo... Soon we won't even be editing files on a disk, but accessing them through a json-rpc client/server? Am I getting this wrong?
[1] https://modelcontextprotocol.io/introduction
I think you are getting it wrong. Some IDEs like Cursor and VS Code extensions like Cline support MCP servers, meaning you can give them access to your databases, Jira tickets, Notion notes, Slack messages, etc.
Claude is like years ahead of everyone else with tools and agentic caps.
Can't be. "It was launched by Anthropic back in November 2024," about MCP
That's a few decades in AI time.
This is great, I was debating whether I should do my latest project using the new OpenAI Responses API (optimized for agent workflows) or using MCP, but now it seems even more obvious that MCP is the way to go.
I was able to make a pretty complex MCP server in 2 days for LLM task delegation:
https://github.com/Dicklesworthstone/llm_gateway_mcp_server
claude needed these those tools in 2024, so having the community contribute for free was actually a smart move.
service providers get more traffic, so they’re into it. makes sense.
claude 3.5 was great at the time, especially for stuff like web dev. but now deepseek v3 (0324) is way better value. gemini's my default for multimodal. openai still feels smartest overall. i’ve got qwq running locally. for deep research, free grok 3 and perplexity work fine. funny enough, claude 3.7 being down these two days didn’t affect me at all.
i checked mcp since i contribute to open source, but decided to wait. few reasons:
- setup’s kind of a mess. it’s like running a local python or node bridge, forwarding stuff via sse or stdio. feels more like bridging than protocol innovation
- I think eventually we need all the app to be somehow built-in AI-first protocol. I think only Apple (maybe Google) have that kind of influence. Think about the lightening vs usb-c.
- performance might be a bottleneck later, especially for multimodal.
- same logic as no.2 but the question is that do you really want every app to be AI-first?
main issue for me: tools that really improve productivity are rare. a lot of mcp use cases sound cool, but i'll never give full github access to a black box. same for other stuff. so yeah—interesting idea, but hard ceiling.
You should take a look at how Claude Code does its permissioning. It's totally fine to connect it right up to your GitHub MCP server because it'll ask each time it wants to take an action (and you can choose "don't ask again for this tool" if it's an obviously safe operation like searching your PRs).
First, I don't want to pay Claude Code at all...
Second, isn't that doable with API calling :)
I know Cloudflare has been talking about remote MCP for a while, does anyone have a solid example of this in practice?
Does anyone have any prior art for an MCP server "message bus" with an agent framework like Mastra?
E.g. suppose I want my agent to operate as Discord bot listening on channel via an MCP server subscribed to the messages. i.e. the MCP server itself is driving the loop, not the framework, with the agent doing the processing.
I can see how this could be implemented using MCP resource pubsub, with the plugin and agent being aware of this protocol and how to pump the message bus loop, but I'd rather not reinvent it.
Is there a standard way of doing this already? Is it considered user logic that's "out of scope" for the MCP specification?
EDIT: added an example here https://github.com/avaer/mcp-message-bus
https://inngest.com and agentkit. disclaimer is I work on it.
Does all of the event stuff and state stuff for you. Plus the orchestration.
Big fan of Inngest! Most of http://glama.ai/mcp logic is built on top of Inngest.
MCP is basically commoditizing SaaS and software by abstracting them away behind the AI agent interface.
It benefits MCP clients (ChatGPT, Claude, Cursor, Goose) more than the MCP servers and the service behind the MCP servers (GitHub, Figma, Slack).
I'm curious what the revenue plan is for MCP authors. I mean, I can see wanting to add support for existing products (like an code/text editor, image/sound/video editor, etc.)
But is there a market for stand-alone paid MCP services? It seems these will mostly be usurped by the models themselves sooner or later. I mean if you create a MCP popular enough to actually make money, the foundation model will soon be able to just do it without your service. Almost like you are doing experimentation on high-value agent features for free.
Also, something about the format just reeks of SOAP to me. It feels over-engineered. Time will tell, obviously.
Most MCP servers are thin wrappers around an API, I don't think there will be a big paid market. I imagine they will be released like SDKs are now, either by companies themselves, or by individuals when there's no official implementation. A few dev agents can even write MCP servers for themselves.
https://www.reddit.com/r/ClaudeAI/comments/1hcrxl6/cline_can...
Not asked contentiously, why does a MCP revenue plan need to exist?
It feels like any kind of api-client work any organization or project would build to make users/customers happy and sticky.
Right, that is why I said it makes sense for existing products. I mentioned desktop apps, but it would apply to any existing project. Like JIRA, or HubSpot, Wordpress, or Figma, etc.
But there is hype around MCP as if independent devs could do something with it. And some will just for fun, some will for open source cred. But it is my experience that longevity is usually the result of stable revenue.
I guess what I predict happening here is a few people will build some useful MCPs, realize there is no way to monetize despite generating a lot of interest and the most useful/popular MCPs will be integrated directly into the offerings of the foundational AI companies. And in a few years we won't even remember the acronym unless you happen to work for some big corp that wants to integrate your existing service into LLMs.
The revenue plan for hosted services is that every user with an MCP client will count as a billable user.
What is the revenue plan for 99% of open source library authors?
The currently-dominant open source paradigm (i.e. motivated and well-meaning developers work themselves to the bone under pressure from tech giants who will never pay them) is clearly not sustainable. Moreover, many are probably not happy with their code being used (without permission) to train machines whose putative intent is to replace those self-same developers. Now the question is, how many will want to do something similar, again?
Is what you are insinuating that the only licensing model for independent MCP authors is open source? Are you assuming that MCPs are only viable as free (as in beer) projects?
I feel like software license and business revenue models are only very loosely correlated. I guess if you are assuming there is no money at all to be made in MCP then my question wouldn't make sense.
MCP is great. But what i'd like to understand is whats the difference between MCP and manually prompting the model a list of tools with description and calling the specific function based on the llm response ?
1. it makes tool discovery and use happen elsewhere so programs become more portable
2. it standardizes the method so every LLM doesn't need to do it differently
3. it creates a space for further shared development beyond tool use and discovery
4. it begins to open up hosted tool usage across LLMs for publicly hosted tools
5. for better or worse, it continues to drive the opinion that 'everything is a tool' so that even more functionality like memory and web searching can be developed across different LLMs
6. it offers a standard way to set up persistent connections to things like databases instead of handling them ad-hoc inside of each LLM or library
If you are looking for anything more, you won't find it. This just standardizes the existing tool use / function calling concept while adding minimal overhead. People shouldn't be booing this so much, but nor should they be dramatically cheering it.
Great breakdown, appreciate it.
I think most of the hype around MCP is just excitement that tool use can actually work and seeing lots of little examples where it does.
Watching Claude build something in Blender was pure magic, even if it is rough around the edges.
You can build all the tools yourself, or you can just go to a "tools store", install it and use it. MCP is just the standard everyone can use to build, share and use these tools.
Just like an app store, a chrome extension store, we can have a LLM tools store.
None. Kind of like the difference of using a REST api or inventing your own api format. Both will work. One is standard.
Where are the community-created server APIs for your format? Why would you re-invent the wheel and rewrite them all yourself?
Was wondering if this would ever happen. I wrote an MCP server that hooked up Azure Monitor (or whatever the hell microsoft is calling it) via Microsoft's python SDK so I could get it to query our logs without using command line tools. Took about half a day, mostly due to writing against the wrong Microsoft SDK. It will be nice to let ChatGPT have a crack a this too!
Does anyone know how MCP servers would be used via the API?
I thought they ran locally only, so how would the OpenAI API connect to them when handing a request?
You'd use a client which runs locally to coordinate between the LLM/agent and the available tools, similarly to how it's described here https://modelcontextprotocol.io/quickstart/client
There are a variety of available clients documented here https://modelcontextprotocol.io/clients
If you haven't tried any of these yet, the first place to start is Claude Desktop. If you'd like to write your own agents, consider https://github.com/evalstate/fast-agent
EDIT: I may have misunderstood your question. If you're asking "how can I make an API call to OpenAI, and have OpenAI call an MCP server I'm running as part of generating its response to me", the answer is "you can't". You'll want a proxy API that you call which is actually an MCP client, responsible for coordinating between the MCP servers and the OpenAI API upstream agent.
You can run remote MCP servers and configure whatever client to use them. This should work even via OpenAI's API(perhaps not yet, but it's just another 'tool' to call)
https://blog.cloudflare.com/remote-model-context-protocol-se...
command mode is for local, and SSE for remote
That makes it table stakes for any agent framework.
This seems to be just implementing tools functionality, no resources or prompts, roots or sampling. I can't blame them.
I'm wondering though about progress notifications and pagination. Especially the latter should be supported as otherwise some servers might not return the full list of tools. Has anyone tested this?
Ideally in the future we won't need an MCP server when the AI can just write Unix terminal code to do anything it needs to get the job done? It seems using an MCP server and having the AI know about its "tools" is more of training wheels approach.
Master Control Program?
Someone at Anthropic might've had a sense of humor when they named integrating LLMs with the outside world... after a pop-culture evil AI.
https://tron.fandom.com/wiki/Master_Control_Program
Don't hook up the MCP to any lab equipment:
https://www.youtube.com/watch?v=lAcYUt2QbAo
Who does he calculate he is?!?
The real benefit I see from mcp is that we are now writing programs for users and ai assistants/agents.
By writing mcp servers for our services/apps we are allowing a standardized way for ai assistants to integrate with tools and services across apps.
If you have a clean, well-documented API that can be understood in under 30 minutes by a decent software engineer, congrats: you are MCP ready. I wonder how many discussions there will be about "adding MCP support" to software without this prerequisite.
Kinda naive question. All you need is a way to convince the LLM to output json according to your schema, then call the function. So what is the use of MCP servers? Why complicate things by adding another layer?
JSON-RPC over HTTP just to make a tool call? At some point, MCP starts to feel like a wrapper around a wrapper.
hopefully they integrate it with their customGPT approach! I think they already work fantastically especially since the addition of the @ sign and automatic completion to easily include them in normal conversations. the only thing that was missing was access to the local machine.
Awesome. I'm preparing an AI course and it looks like the APIs are starting to converge finally...
We need to also add Tron support, otherwise who's going to fight for the users?
Impressive move by OpenAI. MCP support in Agents SDK will greatly enhance AI agent capabilities. Can't wait to see how developers leverage it.
So we’re back to programming?
is this the new langchain?
MCP is now the standard everyone must conform to. Couldn't possibly have predicted that 2 months ago.
We launched mcp.run in December ‘24 with that prediction (err, gamble ;) )
Wait two more months and there will be a different the standard.
Amazing how fast things are happening atm
context: a future I'd want re:coding experience is receiving pull requests for the issues I have in my code repo
...based on code generated from an agent that understands it.
...I think cursor editor gets closer to this experience but for a single task
[dead]
[dead]