Comment by whoknowsidont
10 hours 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.
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.
> 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?
>so what's the proven and standard API I can use to interact with ableton live? blender? unity3d? photoshop?
Do you think MCP helps you out here? Because I can't really think of any other reason why'd you ask this.
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
4 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.
>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.
MCP is an example of "worse is better". Everyone knows that it's not very good, but it gets the job done.
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.
> 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.
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.
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.
> Add a "description" field to your rest API that describes how to call it.
Isn't that swagger\grpc etc?
> 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.
3 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.
(pedantry)it's something humans are talking about a lot, so up-to-date models do know about it...
1 reply →
> 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.
1 reply →
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.