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:
{
"jsonrpc": "2.0",
"id": 2,
"method": "tools/call",
"params": {
"name": "get_weather",
"arguments": {
"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...
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.
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.
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.
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.
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.
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?"
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.
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..?
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?
It’s always been a bit like this but it feels particularly bad since AI hit mainstream coding tooling. Just my 2c :)
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...
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.
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
What is the best way to connect with you? I would like to discuss ideas and protocols if you’re up for that.
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 was using this URL: https://engineapi.moonstream.to/metatx/openapi.json
The response body:
{success: false, error: "Server URL must start with https:// or http://"}`OPEN_MCP_BASE_URL="https://engineapi.moonstream.to/metatx"`
(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.
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.
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.
[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
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.
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!
2/ easy enough for people to understand
Extremely curious about this as just directly listing all tools to an agent will obviously not scale well. What does the interface look like?
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
"tools": [
{
"name": "jsonresume",
"bridge": "mcp",
"command": "npx -y @jsonresume/mcp@3.0.0",
},
{
"name": "slop_example",
"description": "Slop example",
"bridge": "slop",
"source": "https://ajax-valjs_slop_example.web.val.run"
},
{
"name": "normal_http_example",
"description": "Normal HTTP example",
"bridge": "openapi",
"source": "https:/example.com/openapi.json"
}
],
}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 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...
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.
It’s evergreen work that companies are endlessly trying to eliminate or automate yet keep running headfirst into.
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.
That analogy may be helpful for mom, but not for me as a software engineer.
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.
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.
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.
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
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.
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
Well said.
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
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 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?
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?
Feels like we've slid back into the 90s in this regard. Great time to be a security researcher!
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.
(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.)
No, MCP's have NOT Won (Yet) https://newsletter.victordibia.com/p/no-mcps-have-not-won-ye...
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
(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.)
> 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.> 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.
https://norahsakal.com/blog/mcp-vs-api-model-context-protoco...
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.
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).
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
This strikes me as fundamentally untrue, but I'd love to see an example of this in the source code or documentation.
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.
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)
Do modern developers not know what "standards" means? Is this marketing slop or did an engineer seriously write that for other engineers?
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 don't know if GP understands that his phrasing might not be so flattering for his mother ))
> 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.
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.
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?
The fact that the tool call is via mcp and not in-process function call seems to be an implementation detail?
“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.
That said, here's a gist: https://gist.github.com/vessenes/ec43b76965eed1b36b3467c598b...
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?
I think we fundamentally disagree on what "request format" means in context of a large language model.
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.
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!
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.)
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.
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.
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.
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.
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.
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.
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'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.
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.
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....
It’s solving a problem that was already robustly solved. So get we go with another standard.
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.
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.
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...
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.
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...
But HOW is it stateful? That "mandate" the only occurence of that string "state" in that document.
> 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.
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…
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.
https://github.com/modelcontextprotocol/servers/blob/main/sr...
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!
There's some other goodies too. OAuth 2.1 support, JSON-RPC Batching... https://github.com/modelcontextprotocol/specification/blob/m...
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
Example use case: https://news.ycombinator.com/item?id=43466434
This sounds risky but very useful if it works as intended!
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.
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?
- 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.
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!
Although the name is a bit unfortunate.
> 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.
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 was able to make a pretty complex MCP server in 2 days for LLM task delegation:
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.
Second, isn't that doable with API calling :)
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
Does all of the event stuff and state stuff for you. Plus the orchestration.
It benefits MCP clients (ChatGPT, Claude, Cursor, Goose) more than the MCP servers and the service behind the MCP servers (GitHub, Figma, Slack).
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.
https://www.reddit.com/r/ClaudeAI/comments/1hcrxl6/cline_can...
It feels like any kind of api-client work any organization or project would build to make users/customers happy and sticky.
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.
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.
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.
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.
Just like an app store, a chrome extension store, we can have a LLM tools store.
I thought they ran locally only, so how would the OpenAI API connect to them when handing a request?
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.
https://blog.cloudflare.com/remote-model-context-protocol-se...
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?
https://tron.fandom.com/wiki/Master_Control_Program
Don't hook up the MCP to any lab equipment:
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.
...based on code generated from an agent that understands it.
...I think cursor editor gets closer to this experience but for a single task