Model Context Protocol (MCP) servers are rapidly becoming an essential part of agentic LLM usage.

Rightfully so, to be honest: Giving LLMs access to tools and external data frees them from their rather narrow roles as “just a better search engine” or “source code tumblers” quite a bit.

However, as a relatively new technology (Anthropic announced the MC protocol roughly 7 months ago), there are still a lot of things to adjust and figure out.

In this post, I’d like to discuss one of those problems:

What happens when you provide your LLM with access to too many tools and resources?

The Problem: “Too many tools” leads to cognitive overload.

An MCP server acts as an interface between the LLM and external capabilities (e.g. web search, database queries). However, increasing the number of available tools doesn’t necessarily improve results but instead make LLMs struggle with selecting the “right tool for the job” when given too many options. LLMs may then potentially choose the wrong tool or fail to utilize the most appropriate one.

That’s basically a form of decision paralysis for LLMs!

But is there anything we can we do about it?

Well, maybe. Let’s talk about two possible approaches here:

Solution no 1: “Divide and Conquer”

One of the most important strategies in software development is the principle of “divide and conquer”. Applied to our problem, this means that instead of a single MCP server comprising dozens of tools, we build multiple small, specialized MCP servers each of which can be used independently. Think of it like adopting the Unix philosophy for MCPs: “Write programs MCP servers that do one thing and do it well.”

Now, if you’re already using REST APIs as a base for your MCP servers, consider refactoring them into independent, more focused APIs:

Apart from reducing “cognitive load” for LLMs, I’d argue that there’s another big benefit to this strategy: easier deployment and scaling. Putting these servers into containers and letting them run in the cloud (Docker Swarm, Kubernetes etc.) should be pretty straightforward.

However, be warned: refactoring existing, monolithic REST APIs is far from easy. It’s error-prone and you’ll need to be meticulous to avoid breaking things. Plus, the time and resource cost can be significant, especially for complex APIs.

Solution no. 2: Configurable API Endpoints

Instead of refactoring your existing APIs, you can take a, in my opinion, simpler approach: make your API endpoints configurable in the sense that they can be enabled or disabled (i.e. “switched on or off”) dynamically.

This strategy is also “non-invasive”: You don’t need to tear apart your existing REST APIs - you just add a (preferably thin) layer of control on top and configure and deploy them depending on the use cases for your LLMs:

Speed and simplicity are the main benefits here: You can easily play around with different tool selections and see how well your models perform; and I’d argue that it’s also great option for prototyping and iterative development regarding new uses cases or applications for LLMs.

As a side note: I’m currently using this approach in one of my personal projects: mcp-server-collective ;)

Conclusion

• Decision Paralysis (regarding tool usage) turned out to be an issue not just for us humans but for LLMs, too
• Making lots of smaller, specialized MCP servers instead of one giant monolith give you more control, but they’re a lot of work to set up, especially at the beginning and especially if you already have a large, existing API that you want to turn into MCP servers
• Configurable API / MCP endpoints provide a simpler, more flexible solution that also lends itself well to experimentation and prototyping
• Which approach you choose depends, of course, on what you already have and how complex your toolset is (i.e. how long your list of tools is)

However, I want to stress that this is just my humble take on a rather difficult and complex problem. Regardless of the chosen strategy, the following points should also be part of the final solution:

• Monitoring tool selection performance
• Choosing names and descriptions for tools that clearly reflect their intended use