How Many Tools Should an MCP Server Expose?

If you are building a server for the Model Context Protocol (MCP), the right number of tools depends on what a client and its AI model need to do. An MCP server gives AI clients tools, which are named actions the model can request, such as searching records or changing a setting. Each tool has a description and an input schema that defines the information the client must provide.

There is no evidence-backed ideal count for every server. Start with a focused set that supports common user tasks, then measure how well the intended client and model use it. A server can offer many capabilities overall while showing the model only the relevant subset at a given time.

Count the definitions the model sees

Every tool definition takes space in the model’s context, the information the model receives while answering a request. Definitions also give the model options to compare when choosing an action. The number of tools matters, but so do the length of their descriptions, the complexity of their input schemas, and how much their purposes overlap.

A tool count alone does not show how much context the definitions use or how they affect model performance. Anthropic reported that one setup with 58 tools used about 55,000 tokens for tool definitions; tokens are units of text processed by a model. That figure describes a particular setup, not a standard cost per tool. Microsoft Research also found that some models performed much worse when choosing from large sets of tools. The results varied by model. Neither result establishes one tool count at which performance falls across models and setups.

Tool definitions and tool results also consume context separately. A small catalogue can return a very large result, while a larger catalogue can contain short, distinct definitions. Measure both when diagnosing context use.

As a starting point, fewer than 10 distinct tools can be reasonable to show in full. Around 10 or more, measure definition size and test whether the model selects the right tool. AWS Prescriptive Guidance recommends considering a split when one server has more than 50 tools. AWS presents this as a way to organize a large catalogue. It does not set a protocol limit or prove that performance fails above 50 tools.

Design tools around user tasks

Mapping every API operation to its own tool is easy to implement, but it often exposes choices that reflect backend structure rather than user intent. The model then has to figure out which operations to combine and in what order.

Instead, begin with common tasks. If users routinely need several API calls for one task, one tool can make those calls in sequence. AWS recommends considering this approach when a common workflow requires three or more API calls. Keep separate tools for distinct user intents, and split a tool when its many parameters make it hard to choose the right inputs. AWS identifies more than eight parameters as a reason to consider decomposition, while advising designers to prioritize simplifying common workflows.

For example, a support system might offer one tool to create a case with the relevant customer details, rather than separate tools for creating a record and adding information that users routinely provide together. But a broad tool that handles unrelated tasks through a large set of optional parameters can be just as difficult to use as a long list of narrow tools. Test the tool boundaries with real requests.

Keep a large catalogue out of the active set

A server does not have to show the model every tool at once. A client can filter the tools it shows or search a large catalogue and load only the definitions relevant to a user or task.

A client can filter tools at configuration time. OpenAI documents an allowed_tools option for importing only selected tools. The GitHub MCP Server also supports selecting toolsets or individual tools. When a server covers separate areas or duties, operators can split it into smaller servers to make those boundaries clearer. AWS describes domain-based organization and separate read and write servers as possible approaches.

For larger catalogues, progressive discovery means searching for relevant tools and loading their definitions when needed, instead of sending every definition at the start. The MCP client best-practices guidance describes ways to find tools, including keyword search and embedding-based search, which matches tools to requests by meaning. Anthropic reports that its Tool Search Tool reduced tool-definition token use by 85% in its example. That result is specific to Anthropic’s setup and does not guarantee the same savings elsewhere.

Discovery adds a selection step, and that step can miss the needed tool. Research on tool retrieval found that even strong standard search methods performed poorly on some large tool-search tasks. Weak search also hurt overall task results. Test whether discovery finds the right tool for representative requests before relying on it.

Test the active set in your deployment

Using the model and client you plan to deploy, compare the full tool list with a selected smaller set or a discovery approach. Use realistic requests, including requests that require less common capabilities. Record whether the right tool was available, whether the model chose it, whether it supplied valid inputs, and whether the task completed. Track token use and response time too. A shorter active list helps only if it still supports the tasks people need.

Check how your specific client handles tool definitions. Do not assume it filters or loads tools on demand; some clients send all configured definitions to the model. If you use discovery, check whether it fails to find the needed tool as carefully as you check for tool-call errors. A concise catalogue that hides the required capability can fail just as surely as an oversized one that confuses the model.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com