alt Hacker NewsIf you have an API with thousands of endpoints, that MCP description is going to totally rot your context and make your model dumb, and there's no mechanism for progressive disclosure of parts of the tool's abilities, like there is for CLIs where you can do something like:
tool --help
tool subcommand1 --help
tool subcommand2 --help
man tool | grep "thing I care about"
As for stateful behavior, say you have the google docs or email mcp. You want to search org-wide for docs or emails that match some filter, make it a data set, then do analysis. To do this with MCP, the model has to write the files manually after reading however many KB of input from the MCP. With a cli it's just "tool >> starting_data_set.csv"
Replies
>here's no mechanism for progressive disclosure of parts of the tool's abilities
In fact there is: https://platform.claude.com/docs/en/agents-and-tools/tool-us...
If the special tool search tool is available, then a client would not load the descriptions of the tools in advance, but only for the ones found via the search tool. But it's not widely supported yet.
> that MCP description is going to totally rot your context and make your model dumb, and there's no mechanism for progressive disclosure of parts of the tool's abilities,
Completely false. I was dealing with this problem recently (a few tools, consuming too many tokens on each request). MCP has a mechanism for dynamically updating the tools (or tool descriptions):
https://code.claude.com/docs/en/mcp#dynamic-tool-updates
We solved it by providing a single, bare bones tool: It provides a very brief description of the types of tools available (1-2 lines). When the LLM executes that tool, all the tools become available. One of the tools is to go back to the "quiet" state.
That first tool consumes only about 60 tokens. As long as the LLM doesn't need the tools, it takes almost no space.
As others have pointed out, there are other solutions (e.g. having all the tools - each with a 1 line description, but having a "help" tool to get the detailed help for any given tool).
Nobody said anything about an API with thousands of endpoints. Does that even exist? I've never seen it. Wouldn't work on it if I had seen it. Such is the life of a strawman argument.
Further, isn't a decorator in Python (like @mcp.tool) the easy way to expose what is needed to an API, if even if all we are doing is building a bridge to another API? That becomes a simple abstraction layer, which most people (and LLMs) get.
Writing a CLI for an existing API is a fool's errand.
>man tool | grep "thing I care about"
Isn't the same true of filtering tools available thru mcp?
The mcp argument to me really seems like people arguing about tabs and spaces. It's all whitespace my friends.
> like there is for CLIs where you can do something like
Well, these will fail for a large amount of cli tools. Any and all combinations of the following are possible, and not all of them will be available, or work at all:
tool some tools may output usage when no arguments are supplied
tool -h some tools may have a short switch for help
tool --help some tools may have a long switch for help
tool help some tools may have help as a subcommand
tool command some tools may output usage for a command with no arguments
tool command -h some tools may have a short switch for command help
tool command --help some tools may have a long switch for command help
tool help command some tools may have a help command
man tool some tools may have man pages
grep one-line usage and "type grep --help"
grep -h one-line usage and "type grep --help"
grep --help extended usage docs
man grep very extended usage docs
python starts interactive python shell
python -h
python --help equivalent help output
ps short list of processes
ps -h longer list of processes
ps --help short help saying you can do, for example, `ps --help a`
ps --help a gives an extended help, nothing about a
erl
erl -h
erl --help all three start Erlang shell
man erl No manual entry for erl
Not to say that MCPs are any better. They are written by people, after all. So they are as messy.
This is a design problem, and not something necessarily solved by CLI --help commands.
You can implement progressive disclosure in MCP as well by implementing those same help commands as tools. The MCP should not be providing thousands of tools, but the minimum set of tools to help the AI use the service. If your service is small, you can probably distill the entire API into MCP tools. If you're AWS then you provide tools that then document the API progressively.
Technically, you could have an AWS MCP provide one tool that guides the AI on how to use specific AWS services through search/keywords and some kind of cursor logic.
The entire point of MCP is inherent knowledge of a tool for agentic use.