Comment by whoknowsidont
3 months ago
MCP was a really shitty attempt at building a plugin framework that was vague enough to lure people into and then allow other companies to build plugin platforms to take care of the MCP non-sense.
"What is MCP, what does it bring to the table? Who knows. What does it do? The LLM stuff! Pay us $10 a month thanks!"
LLM's have function / tool calling built into them. No major models have any direct knowledge of MCP.
Not only do you not need MCP, but you should actively avoid using it.
Stick with tried and proven API standards that are actually observable and secure and let your models/agents directly interact with those API endpoints.
> LLM's have function / tool calling built into them. No major models have any direct knowledge of MCP.
but the major user interfaces for operating LLMs do and that's what matters
> Not only do you not need MCP, but you should actively avoid using it.
> Stick with tried and proven API standards that are actually observable and secure and let your models/agents directly interact with those API endpoints.
so what's the proven and standard API I can use to interact with ableton live? blender? unity3d? photoshop?
[flagged]
What do all of the links below have in common? Do you know of another way you can control all of those applications via LLMs? Computer use?
https://github.com/ahujasid/ableton-mcp
https://github.com/ahujasid/blender-mcp
https://github.com/CoplayDev/unity-mcp
https://github.com/mikechambers/adb-mcp
9 replies →
> MCP was a really shitty attempt at building a plugin framework
Can you go more in depth? The protocol is relatively simple, what about it you feel is "shitty" as a plugin framework?
The hate for MCP here is absurd.
It's JSON-RPC, with some descriptors.
And some comments about OAuth 2.
The value is in the consensus. You can make a tool that agents can connect to with no apriori knowledge.
Actually, MCP wastes a lot of tokens when compared to regular tool calling. You might not notice it on more trendy models with large contexts, but for those of us trying to use locked down/local/cheap models it makes very little sense.
Also, MCP creates a new problem: providing the model with too much context when trying to combine tools across multiple servers. It works OK with small, very focused servers (like helpers for a specific data set), but if you try to mix and match servers things get out of hand really quickly and the entire workflow becomes very unreliable—too many options to digest and pursue, just like humans.
8 replies →
>It's JSON-RPC, with some descriptors.
That's not even true. It defines the lifecycle of tool calling.
JSON-RPC with some descriptors would have been fine and amazing.
4 replies →
Things like OpenAPI have existed for 15 years now and they also offer standarization.
The value on MCP is not on its features or innovation, but on the rate of adoption it has had. Companies have now an incentive to open, document and standarize their APIs to enable this new distribution channel.
Perhaps you haven't used many MCP server, but those that I have used (GitHub, Atlassian, Glean, BuildKite, Figma, Google Workspace, etc) work very well. They teach an LLM how to do exactly what you're saying - "use the API standards...your models/agents directly interact with those API endpoints." Most MCP severs don't sit in between the LLM and the API endpoints, they just teach them how to use the tools and then the LLM calls the APIs directly as any HTTP client would. I find it works quite well and seems far better than manually maintaining rules or pointing at docs and installing CLI tools (like "gh" for GitHub) or using curl to interact with APIs from a terminal within a chat session.
> but those that I have used (GitHub, [...])
> Most MCP severs don't sit in between the LLM and the API endpoints [...]
Your first example certainly isn't an example of that: https://github.com/github/github-mcp-server
I suppose someone could try to abuse MCP by stuffing information about REST API endpoints into a the prompt/descriptions in a small MCP "skeleton" service, but I don't know of any. Can you provide examples?
> they just teach them how to use the tools and then the LLM calls the APIs directly as any HTTP client would.
I suspect you might have some deep misunderstandings about MCP.
>, they just teach them how to use the tools and then the LLM calls the APIs directly as any HTTP client would.
No. MCP does not do this. Function & tool calling is built into the LLM. MCP is not augmenting this ability in ANY way.
> No major models have any direct knowledge of MCP.
Claude and ChatGPT both support MCP, as does the OpenAI Agents SDK.
(If you mean the LLM itself, it is "known" at least as much as any other protocol. For whatever that means.)
>it is "known" at least as much as any other protocol.
No. It is not. Please understand what the LLM's are doing. Claude nor ChatGPT nor any major model knows what MCP is.
They know how to function & tool call. They have zero trained data on MCP.
That is a factual statement, not an opinion.
This is probably a semantics problem. You’re right. The models don’t know how to mcp. The harness they run in does though (Claude code, Claude desktop, etc), and dynamically exposes mcp tools as tool calls.
2 replies →
That is an easily falsifiable statement. If I ask ChatGPT or Claude what MCP is Model Context Protocol comes up, and furthermore it can clearly explain what MCP does. That seems unlikely to be a coincidental hallucination.
5 replies →
> That is a factual statement,
I think most people, even most devs, don't actually know how crappy an MCP client is built, and that it's essentially an MITM approach and that the client sends the LLM on the other end a crappy pretext of what tools are mounted and how to call their methods in a JSON, and then tries to intelligently guess what response was a tool call.
And that intelligent guess is where it gets interesting for pentesting, because you cannot guess anything failsafe.
> They have zero trained data on MCP.
They have significant data trained on MCP.
> They know how to function & tool call.
Right. You can either use MCP to transmit those tool calls, or you can create some other interface.
4 replies →
(pedantry)it's something humans are talking about a lot, so up-to-date models do know about it...
1 reply →
probably easier to just tell people: You want MCP? Add a "description" field to your rest API that describes how to call it.
That's all it's doing. Just plain ole context pollution. World could be better served by continuing to build out the APIs that exist.
Sometimes the actions you want to perform does not map cleanly into one or two API calls, or would be too messy to assume correct parsing. Maybe your UI is fine POSTing to /users and PUTing to /groups or whatever but giving the LLM a direct CreateUserAndAddToGroup action simplifies the task and keeps context cleaner.
This is very true. But why stop there?
Imagine a future where we have an evolved version of MCP -- call it MCP++.
In MCP++, instead of having to implement a finite list of specialized variants like CreateUserAndAddToGroup, imagine MCP++ has a way to to feed the desired logic (create user, then add that user to $GROUP) directly to the endpoint. So there would be something like a POST /exec endpoint. And then the /exec endpoint can run the code (maybe it's WASM for something)...
Wait a minute! We already have this. It's called programming.
You could have the LLM write code, so that any pipelining (like your example), aggregation, filtering, or other transformation happens in that code, and the LLM only needs to spend the output tokens to write the code, and the only input tokens consumed is the final result.
I definitely am not the first person to suggest this:
https://www.anthropic.com/engineering/code-execution-with-mc...
https://blog.cloudflare.com/code-mode/
... but I can say that, as soon as I read about MCP, my first thought was "why?"
MCP is wasteful.
If you want LLMs to interact with your software/service, write a library, let the scrapers scrape that code so that future LLM revisions have the library "baked into it" (so you no longer need to spam the context with MCP tool descriptions), and let the LLM write code, which it already "knows" how to do.
What if your library is too new, or has a revision, though?
That's already a solved problem -- you do what you'd do in any other case where you want the LLM to write code for you: point it at the docs / codebase.
yesss, and OpenAI tried this first when they were going to do a “GPT store”. But REST APIs tend to be complicated because they’re supporting apps. MCP, when it works, is very simple functions
in practice it seems like command line tools work better than either of those approaches
Command line tools are my preference just because they're also very useful to humans. I think providing agents function libraries and letting them compose in a repl works about as well but is higher friction due env management.
> Add a "description" field to your rest API that describes how to call it.
Isn't that swagger\grpc etc?
> Just plain ole context pollution.
It would normally be a second context window to figure out what tool / agent to run.
My only quibble with MCP is in the usual AI bandwagon people are implementing for FOMO than business value. My experience is likely anecdotal though.
Also, keep your api small as all the tool call, DTOs and user messages (e.g. workflow recipes) add up to big context windows and accuracy confusion, at least in the latest models. I hope that gets resolved.
> World could be better served by continuing to build out the APIs that exist.
before LLM's and MCP the world was depreciating or locking down APIs
MCP is an example of "worse is better". Everyone knows that it's not very good, but it gets the job done.
Yeah there's no there there when it comes to MCP. It's crazy to me that the world bought into the idea when the "spec" literally boils down to "have your server give the LLM some json". Just illustrates how powerful it is to attach names to things, especially in a hypestorm in which everyone is already frothing at the mouth and reason is hard to come by. Give people some word they can utter to help them sound like they're on the "bleeding edge" and they'll buy into it even if it's totally pointless.
"Have your XYZ give the LLM some JSON" is pretty close to how all tool calling works with or without MCP.
What next you are going to tell me rest and async are implemented in code?! And not just willed into existence by the compiler!
Markdown is for output too.
It gave everyone a reason to think about the usability of the interfaces they were exposing.
Many endpoints have tons of fields irrelevant to 95% of external users. Now those are gone.
Or they implemented higher level abstractions for the actual tasks instead of making developers compose a bunch of little pieces.
And it has a standardized manifest.
Execs, PMs, and customers having that word to utter as part of the AI hype train created the opportunity for that industry-wide cleanup to happen. Calling it pointless is very naive. It's actually kind of extraordinary.
Thanks for offering another perspective on it. I can buy into this partially.
At the same time, I'm skeptical that this won't just become yet another dead protocol once the hype abates, at which point all of the perceived benefits were for naught.
Fully agree, however we need to reach our KPIs and OKRs regarding AI adoption.