> This is 100% a problem with the MCP spec: it does not currently provide a way to narrow what tools, and therefore context, flow into the LLM.

it's not the business of MCP spec, it should be task/job level, different task may need different tools and MCP just supply entire tools it has. The tool pickup should be the take charge by llm. moreover maybe some has `while list` to include or exclude some tools, but it should not from MCP spec.

> This is 100% a problem with the MCP spec

No, its not.

It’s a problem with the design of agentic workflows. Its on a whole different level of the atack than the MCP spec.

It is a real issue, but not one that it makes sense tor the MCP spec to be concerned with.

> OpenAPI helps, but it's not quite the same thing

I haven't dug into MCP yet, but can you give any examples as to why openapi isn't/wasn't enough?

It can, but I remain deeply unconvinced that the sub-agent architecture works as well as advertised.

The trick with any layering like this is that your end-to-end reliability is subagent_reliability * routing_agent_reliabilitty. Neither are 100% (or anywhere close to it, let's be honest), so the multiplying probabilities are still going to trash your performance.

If you get routed to the correct subagent, then subsequent performance is likely to be solid - but that's because you've taken the `routing_agent_reliability` term out of the equation.

Routing agent reliability hinges pretty heavily on the subagents themselves and how semantically or linguistically similar they are. If you have subagents that are in wildly disparate domains it may work well, but if your subagents start overlapping (or just look like they overlap) then routing accuracy is likely going straight into the dumpster. And a mis-route is catastrophic in that setup.

For very specific agents (well-established workflows that cross multiple, well-defined, non-overlapping domains) the architecture may be suitable, but in terms of the holy grail of the omni-agent (i.e., a desktop app agent suitable for general use) I suspect we'll continue running into a brick wall.

The context window is limited. Using half your context window for tools means you have a 50% smaller context window.

On a large and complex system (not even a mini ERP system or even a basic bookkeeping system, but a small inventory mgmt system) you are going to have a few dozen tools, each with a description of parameters and return values.

For anything like an ERP system you are going to have a few thousands of tools, which probably wouldn't even fit in the context before the user supplied prompt.

This is why the only use case this far for genAI is coding: with a mere 7 tools you can do everything.

> Can you elaborate on how the agents degrades from more tools?

The more context you have in the requests, the worse the performance, I think this is pretty widely established at this point. For best accuracy, you need to constantly prune the context, or just begin from the beginning.

So with that, each tool you make available to the LLM for tool calling, requires you to actually put the definition (arguments, what it's used for, the name and so on) into the context.

So if you have 3 tools available, which are all relevant to the current prompt, you'd get better responses, compared to if you had 100 tools available, where only 3 are relevant, and the rest of the definitions are just filling the context for little point.

TLDR: context grows with each tool definition, more context == worse inference, so less tool definitions == better responses.

Better if you see it for yourself. Setup GitHub MCP and enable all tools. It will start using wrong tools at wrong time, overuse it. Add languageserver-mcp, and it suddenly will start trying to use it for file edits and create a huge mess in files.

I have nixos mcp server available to search documentation and packages, but it often starts using it for entirely different things.

It's almost like when you tell someone not to think about an elephant, and they can't stop thinking - if you provide it with a tool, it will try to use it. That's why sub-agents are better because you can limit tool availability.

I use tidewave mcp and as soon as it uses a single tool from it, claude becomes obsessed with it, I saw it waste entire context running evals there without doing any file edits.

It’s not just context.

It is similar to paralysis - in that now every prompt the model has to reason over more tools to possibly decide to use - this is surely a deviation from training the more tools you add

Imagine that for every task you receive, you also received a list of all the systems and tools you had access to.

So a JIRA ticket description might be several thousand lines long now when the actual task description is a few sentences. The ratio of signal to noise is now bad, and the risk of making mistakes goes up, and the models degrade.

This is where you start to fine-tune the weights, you can get pretty great results when it comes to specific tool calls with the right data.