About limitation of the number of MCP tools

According to my understanding, during MCP initialization, the client receives a list of tools from various MCP servers.

Then, when a user makes a request, I think the LLM decides the order of MCP calls using the list of tools by providing them like headers, which requires more tokens (and decision time).
And I think this is why Cursor limits the number of MCP tools.

If there were another AI agent that decides the list of possibly required tools and delivers it to the main LLM or AI agent, would it be possible to get more accurate results without limiting the number of MCP tools?

1 Like

Does it mean the number of MCP tools set in Cursor, or just the number of tool calls?

1 Like

Cursor currently has a hard limit of 40 tools total. I use 2 MCP servers that expose 41 tools in total. Cursor cannot see the 41st tool.

Before this limit was imposed cursor would fill the context window with tool details and ■■■■ out before producing any output.

Hey, you can also disable individual MCP tools for each MCP server to ensure you don’t exceed the limit of 40 tools.

The question was about a software architectural approach to get a better user experience, not about the disable option.

The disable option for MCP servers requires the user to select some MCP servers for the user prompt.
But without that process, the LLM could select MCP tools to respond to the user prompt, and may be able to select a better way than the user’s consideration.