Comment by upghost
8 hours ago
So I don't disagree with any of the criticisms of MCPs but no one here has mentioned why they are useful, and I'm not sure that everyone is aware that MCP is actually just a wrapper over existing cli/API:
1. Claude Code is aware of what MCPs it has access to at all times.
2. Adding an MCP is like adding to the agent's actuators/vocabulary/tools because unlike cli tools or APIs you don't have to constantly remind it what MCPs it has available and "hey you have access to X" and "hey make an MCP for X" take the same level of effort on the part of the user.
3. This effect is _significantly_ stronger than putting info about available API/cli into CLAUDE.md.
4. You can almost trivially create an MCP that does X by asking the agent to create an MCP that does X. This saves you from having to constantly remind an agent it can do X.
NOTE: I cannot stress enough that this property of MCPs is COMPLETELY ORTHOGONAL to the nutty way they are implemented, and I am IN NO WAY defending the implementation. But currently we are talking past the primary value prop.
I would personally prefer some other method but having a way to make agents extensible is extremely useful.
EXAMPLE:
"Make a bash script that does X."
<test manually to make sure it works>
"Now make an MCP called Xtool that uses X."
<restart claude>
<claude is now aware it can do Xtool>
>This effect is _significantly_ stronger than putting info about available API/cli into CLAUDE.md.
No it's not.
Honestly this conversation is extremely weird to me because somehow people are gravely misunderstanding what MCP even purports to do, let alone what it actually CAN do in the most ideal situation.
It is a protocol and while the merits of that protocol is certainly under active discussion it's irrelevant because you keep adding qualities about the protocol that it cannot deliver on.
Just same facts to help steer this conversation correctly, and maybe help your understanding on what is actually going:
* All LLM's/major models have function & tool calling built in.
* Your LLMs/models do not have any knowledge on MCP, nor have they been trained on it.
* MCP exists, at least the claim, is to help standardize the LIFECYCLE of the tool call.
* MCP does not augment or enhance the ability of LLM's in any form.
* MCP does not allow you to extend agents. That's an implicit feature.
* If you have access to "X" (using your example), you don't need anything that obeys the MCP standard.
MCP at best is for developers and tool developers. Your model does not need an MCP server or client or anything else MCP related to do what is already been trained to do.
>I would personally prefer some other method but having a way to make agents extensible is extremely useful.
They already are. MCP does not help with this.
Three facts to consider:
1. CLAUDE.md is not part of the system prompt
2. The Claude Code system prompt almost certainly gives directions about how to deal with MCP tools, and may also include the list of tools
3. Instruction adherence is higher when the instructions are placed in the system prompt
If you put these three facts together then it’s quite likely that Claude Code usage of a particular tool (in the generic sense) is higher as an MCP server than as a CLI command.
But why let this be a limitation? Make an MCP server that calls your bash commands. Claude Code will happily vibe code this for you, if you don’t switch to a coding tool that gives better direct control of your system prompt.
>is higher as an MCP server than as a CLI command.
What do you mean by "higher"?
This response is spot on. People seem very confused about what MCP actually is. It's just a standard way to provide an LLM with tools. And even how that happens is up to the agent implementation. There are some other less common features, but the core is just about providing tool definitions and handling the tool_call. Useful but basically just OpenAPI for LLM
Also not disagreeing with your argument. Just want to point out that you can achieve the same by putting minimal info about your CLI tools in your global or project specific CLAUDE.md.
The only downside here is that it's more work than `claude mcp add x -- npx x@latest`. But you get composability in return, as well as the intermediate tool outputs not having to pass through the model's context.
1.) Awareness doesn’t mean they will use it. And in practice they often don’t use them.
2.) “ unlike cli tools or APIs you don't have to constantly remind it what MCPs it has available” - this doesn’t match my experience. In fact, bash commands are substantially more discoverable.
3.) Again, this doesn’t match my experience and the major providers recommend including available MCP tools in system prompts/CLAUDE.md/whatever.
4.) Can’t speak to this as it’s not part of my workflow for the previous reasons.
The only useful MCP for me is Playwright for front end work.
Chrome Devtools is similarly an extremely high value MCP for me.
I would agree that if you don't find they add discoverability then MCPs would have no value for you and be worse than cli tools. It sounds like we have had very opposite experiences here.
Interesting. Perhaps it comes down to which platforms we're working on. I don't want to be outright dismissive of it. My primary platform is Claude Code. Are you working with another driver e.g. OpenAI Codex?
> 3. This effect is _significantly_ stronger than putting info about available API/cli into CLAUDE.md.
What? Why?
> unlike cli tools or APIs you don't have to constantly remind it what MCPs it has available
I think I'm missing something, because I thought this is what MCP does, literally. It just injects the instructions about what tools it has and how to use them into the context window. With MCP it just does it for you rather than you having to add a bit to your CLAUDE.md. What am I misunderstanding?
MCP is simply a standardized RPC protocol for LLMs.
That's it.
The value is in all the usual features of standardization -- plug-and-play, observability, pass-through modifications, etc.
>observability
Which MCP does the opposite of. It hides information.