← Back to context

Comment by jswny

9 days ago

MCP loads all tools immediately. CLI does not because it’s not auto exposed to the agent, got have more control of how the context of which tools exist, and how to deliver that context.

11 comments

jswny

Reply
algis-hn  8 days ago

Accurate for naive MCP client implementations, but a proxy layer with inference-time routing solves exactly this control problem. BM25 semantic matching on each incoming query exposes only 3-5 relevant tool schemas to the agent rather than loading everything upfront - the 44K token cold-start cost that the article cites mostly disappears because the routing layer is doing selection work. MCPProxy (https://github.com/smart-mcp-proxy/mcpproxy-go) implements this pattern: structured schemas stay for validation and security quarantine, but the agent only sees what's relevant per query rather than the full catalog. The tradeoff isn't MCP vs CLI - it's routing-aware MCP vs naive MCP, and the former competes with CLI on token efficiency while retaining the organizational benefits the article argues for.

jabber86  8 days ago

It does not have to load all tools. As you are able to hide the details in CLI you can implement the same in MCP server and client.

Just follow the widely accepted pattern (all you need 3 tools in front): - listTools - List/search tools - getToolDetails - Get input arguments for the given tool name - execTool - Execute given tool name with input arguments

HasMCP - Remote MCP framework follows/allows this pattern.

CharlieDigital  9 days ago

You can solve the same problem by giving subsets of MCP tools to subagents so each subagent is responsible for only a subset of tools.

Or...just don't slam 100 tools into your agent in the first place.

  • simianwords  9 days ago

    >Or...just don't slam 100 tools into your agent in the first place.

    But I can do them with CLI so that's a negative for MCP?

    • CharlieDigital  9 days ago

      You've missed the point and hyperfocused on the story around context and not why an org would want to have centralized servers exposing MCP endpoints instead of CLIs

      3 replies →