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.
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...
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.
(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.
[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.
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!
or is there more to it?
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...
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.
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
Well said.
> 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.
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?
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.
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.
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.
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.
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.
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!
- 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