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?
https://github.com/ahujasid/ableton-mcp
https://github.com/ahujasid/blender-mcp
This is pretty well established. See for example:
https://www.anthropic.com/engineering/code-execution-with-mc...
https://blog.cloudflare.com/code-mode/
Code (including shell scripting) allows the LLM to manipulate the results programmatically, which allows for filtering, aggregation and other logic to occur without multiple round trips between the agent and tool(s). This results in substantially less token usage, which means less compute waste, less cost, and less confusion/"hallucination" on the LLM's part.
If one comes to the same conclusion that many others have (including CloudFlare) that code should be the means by which LLMs interface with the world, then why not skip writing an MCP server and instead just write a command-line program and/or library (as well as any public API necessary)?
I've actually taken to both approaches recently, using the mcp-client package to give me an interface to a wide array of prebuilt tools in my non-LLM application. I could have written or sourced 10 different connectors, or I can write one client interface and any tool I plug in shares the same standard interface as all the others.
I mean you just took some examples and went "See MCP!" without any actual understanding of what that code is doing.
All of these have underlying API's that have exactly ZERO need for MCP. All of this functionality already exists and can be used with LLM's.
* https://help.ableton.com/hc/en-us/articles/209072009-Install...
* https://docs.blender.org/api/current/info_quickstart.html
* https://docs.unity3d.com/6000.2/Documentation/ScriptReferenc...
The most hilarious quote from one of those projects:
>The proxy server is required because the public facing API for UXP Based JavaScript plugin does not allow it to listen on a socket connection (as a server) for the MCP Server to connect to (it can only connect to a socket as a client).
Maybe that should have been the sign that this was completely unnecessary and stupid?
>Do you know of another way you can control all of those applications via LLMs?
Seriously. This becoming a bad joke. I mean conceptually, what did you think was happening here? MCP was just magically doing something that didn't already exist before?
It's a waste of effort and time. Do not use MCP.
Let's forget about LLMs completely as they are only tangentially relevant to the benefits of MCP. I want to write 15 lines of python that - no matter the software - is going to trigger the "play" button/action in that software. E.g. I want to hit "play" in both Ableton, Unity and Blender without having to write three times the code, without having to manually write them each an extension plug-ins. How do you do that, today, 2025-11-17 ?
No one looks at MCP and sees "magic", they just see "finished integration". Something you can pretty much use straight away. That's the point.
Can you go more in depth? The protocol is relatively simple, what about it you feel is "shitty" as a plugin framework?
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.
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.
I noticed your second issue, but to me it's just from bad implementation. For some reason people keep exposing generic overlapping tools from multiple MCP servers.
I don't know that MCP causes this issue, any vendor offering a "tools API" if they shove to many APIs it would bloat things up.
How wouldn't it be wasteful?
I'll try to summarize a couple sources:
https://www.anthropic.com/engineering/code-execution-with-mc...
https://blog.cloudflare.com/code-mode/
Here's what Anthropic has to say about it: As MCP usage scales, there are two common patterns that can increase agent cost and latency:
Tool definitions overload the context window;
Intermediate tool results consume additional tokens.
[...]
Tool descriptions occupy more context window space, increasing response time and costs. In cases where agents are connected to thousands of tools, they’ll need to process hundreds of thousands of tokens before reading a request.
[...]
Most MCP clients allow models to directly call MCP tools. For example, you might ask your agent: "Download my meeting transcript from Google Drive and attach it to the Salesforce lead."
The model will make calls like:
TOOL CALL: gdrive.getDocument(documentId: "abc123")
→ returns "Discussed Q4 goals...\n[full transcript text]"
(loaded into model context)
TOOL CALL: salesforce.updateRecord(
objectType: "SalesMeeting",
recordId: "00Q5f000001abcXYZ",
data: { "Notes": "Discussed Q4 goals...\n[full transcript text written out]" }
)
(model needs to write entire transcript into context again)
Every intermediate result must pass through the model. In this example, the full call transcript flows through twice. For a 2-hour sales meeting, that could mean processing an additional 50,000 tokens. Even larger documents may exceed context window limits, breaking the workflow.
With large documents or complex data structures, models may be more likely to make mistakes when copying data between tool calls.
That's not even true. It defines the lifecycle of tool calling.
JSON-RPC with some descriptors would have been fine and amazing.
So, are you agreeing with me?
Respectfully I think I've engaged with you before and you just seem generally confused about nuanced concepts.
The base protocol is just JSON-RPC, and then you have to implement initialize. Everything else is optional.
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.
> 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.
No. MCP does not do this. Function & tool calling is built into the LLM. MCP is not augmenting this ability in ANY way.
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.)
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.
It doesn't even do that. It's not magic.
Both ChatGPT and Claude will perform web searches when you ask them a question, which the fact that you got this confused is ironically topical.
But you're still misunderstanding the principle point because at some point these models will undoubtedly have access to that data and be trained on it.
But they didn't need to be, because LLM function & tool calling is already trained on these models and MCP does not augment this functionality in any way.
I think you're making a weird semantic argument. How is MCP use not a tool call?
OP is saying that the models have not been trained on particular MCP use, which is why MCP servers serve up tool descriptions, which are fed to the LLM just like any other text -- that is, these descriptions consume tokens and take up precious context.
Here's a representative example, taken from a real world need I had a week ago. I want to port a code base from one language to another (ReasonML to TypeScript, for various reasons). I figure the best way to go about this would be to topologically sort the files by their dependencies, so I can start with porting files with absolutely zero imports, then port files where the only dependencies are on files I've already ported, and so on. Let's suppose I want to use Claude Code to help with this, just to make the choice of agent concrete.
How should I go about this?
The overhead of the MCP approach would be analogous to trying to cram all of the relevant files into the context, and asking Claude to sort them. Even if the context window is sufficient, that doesn't matter because I don't want Claude to "try its best" to give me the topological sort straight from its nondeterministic LLM "head".
So what did I do?
I gave it enough information about how to consult build metadata files to derive the dependency graph, and then had it write a Python script. The LLM is already trained on a massive corpus of Python code, so there's no need to spoon feed it "here's such and such standard library function", or "here's the basic Python syntax", etc -- it already "knows" that. No MCP tool descriptions required.
And then Claude code spits out a script that, yes, I could have written myself, but it does it in maybe 1 minute total of my time. I can skim the script and make sure that it does exactly what it should be doing. Given that this is code, and not nondeterministic wishy washy LLM "reasoning", I know that the result is both deterministic and correct. The total token usage is tiny.
If you look at what Anthropic and CloudFlare have to say on the matter (see https://www.anthropic.com/engineering/code-execution-with-mc... and https://blog.cloudflare.com/code-mode/), it's basically what I've described, but without explicitly telling the LLM to write a script / reviewing that script.
If you have the LLM write code to interface with the world, it can leverage its training in that code, and the code itself will do what code does (precisely what it was configured to do), and the only tokens consumed will be the final result.
MCP is incredibly wasteful and provides more opportunities for LLMs to make mistakes and/or get confused.
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 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.
No they don't lol.
MCP has been popular for well over a year.
To filter it out of the training data would be laughable.
But the point is that function & tool calling was already built in. If you take a model from before "MCP" was even referenced on the web it will still _PERFECTLY_ interact with not only other MCP servers and clients but any other API as well.
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.
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.
in practice it seems like command line tools work better than either of those approaches
Isn't that swagger\grpc etc?
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.
before LLM's and MCP the world was depreciating or locking down APIs
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.
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.
"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.