If you use the Claude desktop app with MCP servers, you have probably noticed a new constraint. Anthropic introduced a limit on the number of tools that can be active in a single session. Hit it, and new tools stop registering. The app does not crash. It just silently ignores the overflow.

What the Limit Actually Is

The cap applies to the total number of tool definitions loaded from all connected MCP servers combined. This is not a limit per server. It is cumulative. If you have four servers each exposing 30 tools, you are going to run into it.

The practical consequence is that if you have been stacking MCP servers, some tools near the bottom of your config may not be available. You would only know this if you tried to call one and nothing happened, or if you checked the tool list in the app and noticed something missing.

The limit does not throw an error. It does not tell you which tools failed to register. The app loads what it can, in the order your config lists them, and silently drops the rest. If you have recently added a new MCP server and it seems to be doing nothing, this is the first thing worth checking.

How to Work Within It

The fix is to be deliberate about which servers you load. Most people connect every MCP server they have ever installed and forget about it. That is fine until the cumulative tool count crosses the threshold.

  • Audit your active servers. Open your MCP config file and count how many tools each server actually exposes. Remove servers you do not use regularly.
  • Split your configs. If you work across different contexts (client work vs personal projects), maintain separate MCP config files and swap them. The desktop app reads from a config file you can swap out without reinstalling anything.
  • Prioritise general tools. File access, terminal, and web tools tend to be used across everything. Niche servers for specific tasks can be added when you need them and removed when you do not.
  • Put high-priority servers first. Since the app loads servers in config order and drops overflow silently, list your most critical servers at the top of the config. If you hit the limit, it will be the lower-priority servers that fall off rather than your core tooling.

If you are using Claude for development work, a practical setup is to maintain a base config with your file, terminal, and git tools always loaded, and a secondary config that adds project-specific servers when you are actively working on something that needs them. Switching between configs is a 30-second task once you have the files set up.

Finding Your MCP Config File

On macOS, the config lives at ~/Library/Application Support/Claude/claude_desktop_config.json. On Windows, it is at %APPDATA%\Claude\claude_desktop_config.json. Open it in any text editor to see which servers are connected and in what order.

The MCP Inspector is a useful tool for checking which servers are actually active and what tools each one exposes. It connects to your running servers and shows you the full tool list, which makes auditing much easier than counting manually.

Why It Exists

The model context window has a finite amount of space. Every tool definition is text that gets loaded into the system prompt, describing what each tool does and what parameters it accepts. The more tools you load, the more space they consume before a single word of your actual task is processed. The limit is less about compute and more about keeping the system prompt from bloating to the point where it degrades response quality.

There is also a practical reason beyond context: a model that has access to 200 tools behaves differently from one with 20. When the available tool list is large and unrelated to the current task, the model can make unexpected tool selection decisions. Keeping the tool set focused to what is relevant for the work at hand tends to produce better results anyway, independent of the cap.

If you are building AI workflows that need a large number of tools, the cleaner approach is to build purpose-specific agents with only the tools they actually need, rather than giving one agent access to everything. We do this when we build custom AI automations for businesses — each agent in a workflow has a tight tool set matched to its specific task, which makes the whole system more reliable and easier to debug.

The tool limit in the desktop app is essentially forcing the same good practice. It is frustrating to hit unexpectedly, but the pattern it is nudging you toward — deliberate, minimal tool loading — produces better AI behaviour in the long run.

If you are trying to work out the right tool and model setup for your team's workflow, we are happy to talk through it.