3 ms·

One of the MCP Core Maintainers here, so take this with a boulder of salt if you're skeptical of my biases. The debate around "MCP vs. CLI" is somewhat pointle

by dend 7mo ago

One of the MCP Core Maintainers here, so take this with a boulder of salt if you're skeptical of my biases. The debate around "MCP vs. CLI" is somewhat pointless to me personally. Use whatever gets the job done. MCP is much more than just tool calling - it also happens to provide a set of consistent rails for an agent to follow. Besides, we as developers often forget that the things we build are also consumed by non-technical folks - I have no desire to teach my parents to install random CLIs to get things done instead of plugging a URI to a hosted MCP server with a well-defined impact radius. The entire security posture of "Install this CLI with access to everything on your box" terrifies me. The context window argument is also an agent harness challenge more than anything else - modern MCP clients do smart tool search that obviates the entire "I am sending the full list of tools back and forth" mode of operation. At this point it's just a trope that is repeated from blog post to blog post. This blog post too alludes to this and talks about the need for infrastructure to make it work, but it just isn't the case. It's a pattern that's being adopted broadly as we speak.

o_____________o 7mo ago
> modern MCP clients do smart tool search that obviates the entire "I am sending the full list of tools back and forth" mode of operation How, "Dynamic Tool Discovery"? Has this been codified anywhere? I've only see somewhat hacky implementations of this idea https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1821#issuecomment-3709687415 https://github.com/modelcontextprotocol/modelcontextprotocol... Or are you talking about the pressure being on the client/harnesses as in, https://platform.claude.com/docs/en/agents-and-tools/tool-use/tool-search-tool#mcp-integration https://platform.claude.com/docs/en/agents-and-tools/tool-us...
- dend 7mo ago
  More of the latter than the former. The protocol itself is constrained to a set of well-defined primitives, but clients can do a bunch of pre-processing before invoking any of them.
amzil 7mo ago
The post isn't MCP vs CLI. It covers where MCP wins. > The entire security posture of "Install this CLI with access to everything on your box" terrifies me This is fair for hosted MCPs, However I'm not claiming the CLI is universally more secure. users needs to know what they're doing. Honestly though, after 20 years of this, the whole thread is debating the wrong layer. A well-designed API works through CLI, MCP, whatever. A bad one won't be saved by typed schemas. > At this point it's just a trope that is repeated from blog post to blog post Well, "Use whatever gets the job done" and "it's just a trope" can't both be true. If the CLI gets the job done for some use cases, it's not a trope. It's an option. And I'd argue what's happening is the opposite of a trope. Nobody's hyping CLIs because they're exciting. There's no protocol foundation, no spec committee, no ecosystem to sell into. CLIs are 40-year-old boring technology. When multiple teams independently reach for the boring tool, that's a signal, not a meme. > This blog post too alludes to this and talks about the need for infrastructure to make it work When tool search is baked into Claude Code, that's Anthropic building and maintaining the infrastructure for you. The search index, ranking, retrieval pipeline, caching. It didn't disappear. It moved. And it only works in clients that support it. Try using tool search from a custom Python agent, a bash script, or a CI/CD pipeline. You're back to loading everything. A CLI doesn't need the client to do anything special. `--help` works everywhere. That's the difference between infrastructure that's been abstracted away for some users and infrastructure that's genuinely not needed.
stavros 7mo ago
How come there isn't an mcp://add?url=https://username:password@mcpserver.com/path https://username:password@mcpserver.com/path URL so my browser can open my client to auto-install the MCP yet? I shouldn't have to mess with config files to install an MCP, I should be able to just click a button on the site and have my client pop up and ask if I want to install it.
JyB 7mo ago
> modern MCP clients do smart tool search that obviates the entire "I am sending the full list of tools back and forth" mode of operation This has always surprised me as this always comes up in MCP discussions. To me, it just seem like a matter of updating the protocol to not have that context hungry behaviour. Doesn't seem like an insurmountable problem technically. Glad you say it has already been addressed. Was the protocol itself updated to reflect that? Or are you just referring to off-spec implementations?
- tylerburnam 7mo ago
  Anthropic solved this problem like 3 AI years ago: https://www.anthropic.com/engineering/code-execution-with-mcp https://www.anthropic.com/engineering/code-execution-with-mc...
polynomial 7mo ago
Fully agree. If you don't change your approach but just use CLI "intead of" MCP, you'll end up with a new spin on the same problems. The guardrails MCP provides (identity, entitlement, multi-principal trust boundaries) still need to exist somewhere. https://forestmars.substack.com/p/twilight-of-the-mcp-idols https://forestmars.substack.com/p/twilight-of-the-mcp-idols
kordlessagain 7mo ago
Screw MCP. It’s not even a protocol. It’s a strongly worded suggestion at best.

by dend 7mo ago

o_____________o 7mo ago

> modern MCP clients do smart tool search that obviates the entire "I am sending the full list of tools back and forth" mode of operation How, "Dynamic Tool Discovery"? Has this been codified anywhere? I've only see somewhat hacky implementations of this idea https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1821#issuecomment-3709687415 https://github.com/modelcontextprotocol/modelcontextprotocol... Or are you talking about the pressure being on the client/harnesses as in, https://platform.claude.com/docs/en/agents-and-tools/tool-use/tool-search-tool#mcp-integration https://platform.claude.com/docs/en/agents-and-tools/tool-us...

dend 7mo ago
More of the latter than the former. The protocol itself is constrained to a set of well-defined primitives, but clients can do a bunch of pre-processing before invoking any of them.

amzil 7mo ago

The post isn't MCP vs CLI. It covers where MCP wins. > The entire security posture of "Install this CLI with access to everything on your box" terrifies me This is fair for hosted MCPs, However I'm not claiming the CLI is universally more secure. users needs to know what they're doing. Honestly though, after 20 years of this, the whole thread is debating the wrong layer. A well-designed API works through CLI, MCP, whatever. A bad one won't be saved by typed schemas. > At this point it's just a trope that is repeated from blog post to blog post Well, "Use whatever gets the job done" and "it's just a trope" can't both be true. If the CLI gets the job done for some use cases, it's not a trope. It's an option. And I'd argue what's happening is the opposite of a trope. Nobody's hyping CLIs because they're exciting. There's no protocol foundation, no spec committee, no ecosystem to sell into. CLIs are 40-year-old boring technology. When multiple teams independently reach for the boring tool, that's a signal, not a meme. > This blog post too alludes to this and talks about the need for infrastructure to make it work When tool search is baked into Claude Code, that's Anthropic building and maintaining the infrastructure for you. The search index, ranking, retrieval pipeline, caching. It didn't disappear. It moved. And it only works in clients that support it. Try using tool search from a custom Python agent, a bash script, or a CI/CD pipeline. You're back to loading everything. A CLI doesn't need the client to do anything special. `--help` works everywhere. That's the difference between infrastructure that's been abstracted away for some users and infrastructure that's genuinely not needed.

stavros 7mo ago

How come there isn't an mcp://add?url=https://username:password@mcpserver.com/path https://username:password@mcpserver.com/path URL so my browser can open my client to auto-install the MCP yet? I shouldn't have to mess with config files to install an MCP, I should be able to just click a button on the site and have my client pop up and ask if I want to install it.

JyB 7mo ago

> modern MCP clients do smart tool search that obviates the entire "I am sending the full list of tools back and forth" mode of operation This has always surprised me as this always comes up in MCP discussions. To me, it just seem like a matter of updating the protocol to not have that context hungry behaviour. Doesn't seem like an insurmountable problem technically. Glad you say it has already been addressed. Was the protocol itself updated to reflect that? Or are you just referring to off-spec implementations?

tylerburnam 7mo ago
Anthropic solved this problem like 3 AI years ago: https://www.anthropic.com/engineering/code-execution-with-mcp https://www.anthropic.com/engineering/code-execution-with-mc...

polynomial 7mo ago

Fully agree. If you don't change your approach but just use CLI "intead of" MCP, you'll end up with a new spin on the same problems. The guardrails MCP provides (identity, entitlement, multi-principal trust boundaries) still need to exist somewhere. https://forestmars.substack.com/p/twilight-of-the-mcp-idols https://forestmars.substack.com/p/twilight-of-the-mcp-idols

kordlessagain 7mo ago

Screw MCP. It’s not even a protocol. It’s a strongly worded suggestion at best.