How Many Tools Should an MCP Server Have? What 690 Servers Expose
Client tool limits (Cursor warns past 40, VS Code stops at 128) against what 690 real MCP servers actually expose: median 7, and how many cross each limit.
Fewer than you think, and almost every server already agrees. Clients put a ceiling on how many tools they will send a model, and the ceiling sits well above what most servers expose. This page sets the limits next to what 690 real servers listed when we called them, so you can see where yours falls.
TL;DR:
- The median MCP server exposes 7 tools. Half of the 690 servers that listed tools in our registry census on 20 August 2026 had 7 or fewer.
- 38 of 690 (5.5%) exposed more than 40, the count past which Cursor warns that some models may not respect the rest.
- 3 of 690 (0.4%) exposed more than 128, VS Code's hard limit per chat request [1].
- Every tool costs context on every request, whether the model uses it or not. That cost, not the limit, is the reason to keep the count down.
The client limits
| Client | Limit | What happens past it |
|---|---|---|
| VS Code (GitHub Copilot chat) | 128 tools per request | The request is refused: "Cannot have more than 128 tools per request." You deselect tools or servers in the tools picker [1] |
| Cursor | 40 tools | Its MCP settings warn that "some models may not respect more than 40 tools". This comes from the in-app warning as users and vendors have quoted it [2][3]; we did not find it in Cursor's own docs |
The limit is across all enabled servers together, not per server. A user with five servers of 10 tools each is already past Cursor's 40 before your server adds anything, so a server that is small on its own still competes for room.
What servers actually expose
We called the remote servers in the official MCP registry once each on 20 August 2026. 694 completed a handshake, 4 of them listed no tools, and 690 listed at least one. Their tool counts, following nextCursor to the last page:
| Tools listed | Servers | Share |
|---|---|---|
| 1 | 54 | 7.8% |
| 5 or fewer | 206 | 29.9% |
| More than 20 | 205 | 29.7% |
| More than 40 | 38 | 5.5% |
| More than 100 | 8 | 1.2% |
| More than 128 | 3 | 0.4% |
The median is 7 and the largest is 163. A quarter of servers expose 5 or fewer, and a quarter expose 27 or more. About 1 server in 18 crosses Cursor's 40 on its own.
So the limit is rarely what a single server hits. What users hit is the sum: a handful of ordinary servers installed side by side.
Why the count matters below the limit
A client sends the model every enabled tool's name, description and input schema so the model can choose between them. That happens on every request, whether or not a tool is used, so each tool you add costs every user context on every turn. Long schemas cost more than short ones.
Past a point, more tools also mean worse choices. With many similar tools in front of it, a model picks the wrong one more often or calls none. Speakeasy's guidance attributes the failures it saw with smaller models to that confusion rather than to the context window filling up [2].
How to keep the count down
- Merge near-duplicates.
get_user,get_user_by_emailandget_user_by_idcan be one tool with a parameter. - Split by job, not by endpoint. A server that mirrors a REST API one route per tool will land in the 40-plus group. Expose the tasks a user asks for, and let one tool call several routes.
- Ship a second server for rare work. Admin and bulk operations most users never touch can live in a separate server that only the people who need them install.
- Write the descriptions well. A model that can tell your tools apart needs fewer of them. Writing MCP tool descriptions covers what a good one contains.
Count your own
Call tools/list and follow nextCursor until it stops: a count from the first page alone is the most common way to under-report. The tools/list reference shows the request and every field in the answer, and our MCP connection test does the paging for you and reports the total, the tool names and whether each has a description.