How so? The protocol doesn't obfuscate things. Your agent can easily expose the entire MCP conversation, but generally just exposes the call and response. This is no different than any other method of providing a tool for the LLM to call.
You have some weird bone to pick with MCP which is making you irrationally unreceptive to any good-faith attempt to help you understand.
If you want to expose tools to the LLM you have to provide a tool definition to the LLM for each tool and you have to map the LLM's tool calls into the agent executing the tools and returning the results. That's universal for all agent-side tools.
The whole purpose behind MCP was to provide a low-impedance standard where some set of tools could be plugged into an existing agent with no pre-knowledge and all the needed metadata was provided to facilitate linking the tools to the agent. The initial version was clearly focused on local agents running local tools over stdio. The idea of remote tools was clearly an afterthought if you read the specification.
If you want your agent to speak OpenAPI, you are *more* than welcome to make it do so. It'll probably be fine if it's a well-specified API. The context issues won't go away, I guarantee you. OpenAPI specs for APIs with lots of endpoint will result in large tool definitions for the LLM, just like they do with MCP.
A core issue I see with MCP, as someone using it every day, is that most MCP Server developers clearly are missing the point and simply using MCP as a thin translation layer over some existing APIs. The biggest value with MCP is when you realize that an MCP Server should be a *curated* experience for the LLM to interact with and the output should be purposefully designed for the LLM, not just a raw data dump from an API endpoint. Sure, some calls are more like raw data dumps and should have minimal curation, but many other MCP tools should be more like what the OP of this post is doing. The OP is defining a local multi-step workflow where steps feed into other steps and *don't* need LLM mediation. That should be a *single* MCP Server Tool. They could wrap the local bash scripts up into a simple single tool stdio MCP Server and now that tool is easily portable across any agent that speaks MCP, even if the agent doesn't have the ability to directly run local CLI commands.
Anyway, maybe take a breath and be objective about what MCP is and is not meant to do and disconnect what MCP is from how people are *currently* using (and frequently misusing) MCP.
There are tons of articles detailing the problems if you are genuinely interested.
Notice you couldn't technically point to anything to support your statements, but instead had to revert to religious zealotry and apologetics -- which has no place on this forum.
>be objective about what MCP is and is not meant to do and disconnect what MCP is from how people are currently using (and frequently misusing) MCP.
Please re-read what you wrote.
You wrote all of that just to counter your own stated position, because I think at some fundamental level you realize how non-sense it is.
To get this out of the way, you are an unpleasant person, but that doesn't mean you should be ignored though, so I'll reply.
> you couldn't technically point to anything to support your statements, but instead had to revert to religious zealotry and apologetics
> You wrote all of that just to counter your own stated position, because I think at some fundamental level you realize how non-sense it is.
You need to be specific and not make a blanket assertions like that if you want and honest dialog.
I take particular offense at you claiming "religious zealotry". Nothing in my post is even remotely definable as such. Yes, I use MCP, I also recognize when it's the right tool and when it's not. I don't think MCP is the solution to all problems. I also willingly acknowledge that other tools can fill the same gap. If anyone is being a religious zealot here, it's you and your crusade against MCP.
With your lack of specificity, it's hard to formulate a proper response to whatever you see as lacking in references. I would point out that I haven't see one link in all of your railing against MCP until this very response.
So, let's look at your link.
- I agree that websockets would have been a better choice than SSE+HTTP and StreamableHTTP. Auth for WS is a little bit of a pain from the browser, but it's feasible with some common conventions.
- I agree with their characterization of "web seems to be a thing we probably should support" (pretty sure I called that out in my post already...
- Their "kind of breaks the Unix/Linux piping paradigm" is laughable though. MCP is hardly the first or only thing to wire a 'server' to and application via stdin/stdout chaining and it's *very* much in the spirit of UNIX (IMHO, as someone working with UNIX systems for the last 30+ years)
- Again, I fully agree that the current HTTP transports are... lacking and could use a better solution.
- Rant about python aside (I agree BTW), well, they are just ranting actually. Yes, the documentation could use some help. Yes, the wasn't an official Go SDK until recently.
- Given this was written a while ago, it's not worth addressing the callous on SSE+HTTP beyond saying, 100% it was a bad design that appears to have been tacked on at the last minute.
- The observations about StreamableHTTP are mostly valid. They get a few points wrong, but the essence is right.
- Their security concerns are the same ones you'd have with any API, so I'm not sure how this is unique to MCP.
- Auth is a bit of a sore subject for me as well. MCP doesn't have an ergonomic workflow for multi-tenant sets and in-band oauth credential management. Again thoug, I don't disagree with the essence of their point.
After meandering they land on "just use stdio and websockets". So the whole rant is around the protocol transport.I agree the transport protocols need some TLC, but you *can* work with them now and new transports are something that's being worked on, even a WS transport.
None of that post talks about the actual protocol behind MCP, how it's succeeding/failing at filling the needs it's meant to address, or any real viable alternative for a standard for linking tools to agents.
If you feel like calling out specific point you feel I should back up with references, I can likely provide them. As with any post, much of the information is synthesized from a lot of places so things like the assertion that remote servers were clearly an afterthought is purely from my reading of the spec and the remote transports code.
>To get this out of the way, you are an unpleasant person
You are clearly very emotional about this, for whatever reason. But again it has no place on this forum.
>I would point out that I haven't see one link in all of your railing against MCP until this very response.
Because everything I've stated are fundamental facts about the technology. If you need sources for it, that means you are missing elementary concepts.
>After meandering
They literally point out several issues with the protocol that hamper observability.
You're being very verbose but not saying much and ignoring when things are directly answered for you. That's being generous.
Your position is like someone claiming lemongrass supplements cures COVID. Everyone is rightly pointing out that it's a placebo at best. Then your position is "well point out all the ways it DOESN'T help, everyone is doing it!"
Which is a really not-smart position to hold, to say the least.
The absurdity of this response is astounding. As it's clear you have no actual interest is an honest discussion I'll just drop off here and leave you to your echo chamber.
You have some weird bone to pick with MCP which is making you irrationally unreceptive to any good-faith attempt to help you understand.
If you want to expose tools to the LLM you have to provide a tool definition to the LLM for each tool and you have to map the LLM's tool calls into the agent executing the tools and returning the results. That's universal for all agent-side tools.
The whole purpose behind MCP was to provide a low-impedance standard where some set of tools could be plugged into an existing agent with no pre-knowledge and all the needed metadata was provided to facilitate linking the tools to the agent. The initial version was clearly focused on local agents running local tools over stdio. The idea of remote tools was clearly an afterthought if you read the specification.
If you want your agent to speak OpenAPI, you are *more* than welcome to make it do so. It'll probably be fine if it's a well-specified API. The context issues won't go away, I guarantee you. OpenAPI specs for APIs with lots of endpoint will result in large tool definitions for the LLM, just like they do with MCP.
A core issue I see with MCP, as someone using it every day, is that most MCP Server developers clearly are missing the point and simply using MCP as a thin translation layer over some existing APIs. The biggest value with MCP is when you realize that an MCP Server should be a *curated* experience for the LLM to interact with and the output should be purposefully designed for the LLM, not just a raw data dump from an API endpoint. Sure, some calls are more like raw data dumps and should have minimal curation, but many other MCP tools should be more like what the OP of this post is doing. The OP is defining a local multi-step workflow where steps feed into other steps and *don't* need LLM mediation. That should be a *single* MCP Server Tool. They could wrap the local bash scripts up into a simple single tool stdio MCP Server and now that tool is easily portable across any agent that speaks MCP, even if the agent doesn't have the ability to directly run local CLI commands.
Anyway, maybe take a breath and be objective about what MCP is and is not meant to do and disconnect what MCP is from how people are *currently* using (and frequently misusing) MCP.