3 ms·

What do MCPs do that the CLI cannot? i.e. assuming your agent has access to the terminal, and therefore CLIs, what additional value do MCPs provide?

by nomilk 9mo ago

nomilk 9mo ago
Out of curiosity, I put this exact question to claude [0]. Here's a tl;dr of its answer with my refutations: > MCPs expose tools with defined schemas, parameters, and return types. CLIs do exactly the same thing > Stateful Connections A chat session with an LLM is exactly that! > MCPs can return structured data (JSON, complex objects) So can an agent with a CLI. E.g. they can just take output and > file.json - now they have a json file. > MCPs can expose "resources" - like file contents, database schemas, or API documentation - that I can read directly If you mention these in your prompt to an agent, then they know where to look and can access them too (and use keys etc as necessary)! > MCPs can send progress updates, ask for clarification, or stream results. So can a chat session with an agent. > MCPs can implement fine-grained permission controls and rate limiting at the protocol level. Rate limiting is easy for an agent. Fine-grained permission could be limited by the user of the agent (e.g. by giving a restricted key for the agent to use), so possible if desired. tl;dr no added benefit whatsoever. [0] https://claude.ai/share/4b339fbd-a6db-4fcb-86cd-0e8493aab663 https://claude.ai/share/4b339fbd-a6db-4fcb-86cd-0e8493aab663
formerly_proven 9mo ago
MCP can wrap things which have stateful processes, debuggers for example. Agents will use batch mode but it is quite limited and due to tool calls always being implemented as synchronous invocations, non-batch mode doesn’t work for tool calls. MCP solves this by giving the agent a handle it can use to refer to in multiple invocations. Burns a lot of tokens though and if you need more than batch-mode gdb to debug something the chances of an agent solving it today are very slim.
- vidarh 9mo ago
  > and due to tool calls always being implemented as synchronous invocations Claude Code wil happily start long-running processes and put in the background, and is able to refer back to them. You don't need MCP for that - you can hand the model handles to refer to background jobs just fine with just tool-calling.

What do MCPs do that the CLI cannot? i.e. assuming your agent has access to the terminal, and therefore CLIs, what additional value do MCPs provide?

by nomilk 9mo ago

What do MCPs do that the CLI cannot? i.e. assuming your agent has access to the terminal, and therefore CLIs, what additional value do MCPs provide?

nomilk 9mo ago

Out of curiosity, I put this exact question to claude [0]. Here's a tl;dr of its answer with my refutations: > MCPs expose tools with defined schemas, parameters, and return types. CLIs do exactly the same thing > Stateful Connections A chat session with an LLM is exactly that! > MCPs can return structured data (JSON, complex objects) So can an agent with a CLI. E.g. they can just take output and > file.json - now they have a json file. > MCPs can expose "resources" - like file contents, database schemas, or API documentation - that I can read directly If you mention these in your prompt to an agent, then they know where to look and can access them too (and use keys etc as necessary)! > MCPs can send progress updates, ask for clarification, or stream results. So can a chat session with an agent. > MCPs can implement fine-grained permission controls and rate limiting at the protocol level. Rate limiting is easy for an agent. Fine-grained permission could be limited by the user of the agent (e.g. by giving a restricted key for the agent to use), so possible if desired. tl;dr no added benefit whatsoever. [0] https://claude.ai/share/4b339fbd-a6db-4fcb-86cd-0e8493aab663 https://claude.ai/share/4b339fbd-a6db-4fcb-86cd-0e8493aab663

formerly_proven 9mo ago

MCP can wrap things which have stateful processes, debuggers for example. Agents will use batch mode but it is quite limited and due to tool calls always being implemented as synchronous invocations, non-batch mode doesn’t work for tool calls. MCP solves this by giving the agent a handle it can use to refer to in multiple invocations. Burns a lot of tokens though and if you need more than batch-mode gdb to debug something the chances of an agent solving it today are very slim.

vidarh 9mo ago
> and due to tool calls always being implemented as synchronous invocations Claude Code wil happily start long-running processes and put in the background, and is able to refer back to them. You don't need MCP for that - you can hand the model handles to refer to background jobs just fine with just tool-calling.