{"slug": "how-many-tools-should-an-mcp-server-have", "title": "How many tools should an MCP server have?", "summary": "A developer analyzed the tool schemas of 4,951 public MCP servers, covering 87,146 tools and 270,487 parameters, to determine how many tools a server should expose. The study found that description collisions rise monotonically with server size, with nearly one in three tools on servers exceeding 60 tools having no distinguishing words, and that roughly 20-25% of parameters lack descriptions regardless of server size. The analysis suggests around thirty tools is a practical ceiling before models struggle to tell tools apart.", "body_md": "If you maintain an MCP server, at some point you ask this. You've got twenty tools, you're about to add five more, and something feels wrong about it — but you can't say what, and there's no guidance anywhere.\n\nI read the tool schemas of 4,951 public MCP servers to answer it. 87,146 tools, 270,487 parameters.\n\nThe short answer: around thirty. Past that, the thing that breaks isn't your server. It's whether a model can tell your tools apart.\n\nFor every tool, I took the content words in its description and counted how many appear in no other tool's description on the same server. Call it the tool's distinctive share.\n\nIf that number is zero, every word in the description is a word its siblings also use. A model choosing between your tools has nothing in the descriptions to choose on — the names are doing all the work.\n\nThen I split the corpus by how many tools each server publishes.\n\n| Tools on the server | Servers | Zero-distinctive tools | Parameters with no description | \n|---|---|---|---|\n| 1–3 | 1,256 | 0.5% | 14.8% | \n| 4–7 | 1,292 | 1.6% | 22.4% | \n| 8–15 | 1,044 | 4.3% | 21.9% | \n| 16–30 | 767 | 7.7% | 24.8% | \n| 31–60 | 377 | 16.3% | 22.2% | \n| 61+ | 215 | 31.3% | 20.5% | \n\nA factor of sixty, rising monotonically. On servers with more than sixty tools, nearly one tool in three has no distinguishing word at all.\n\nPart of it is arithmetic. More tools means more chances that two of them collide, and that would happen even if every author wrote carefully.\n\nBut the curve steepens around thirty, and arithmetic alone doesn't explain that. What happens around thirty is that authors stop writing descriptions one at a time and start generating them from a pattern. A template is a machine for producing tools that read alike.\n\nThe most extreme case in the corpus: one server appends the same 51-word context block to all 275 of its tools.\n\n```\n3land_createCollection   \"Create a new NFT collection on 3.Land marketplace.\n                          SAP MCP context: Protocol 3land; operation class\n                          write. Use for 3.Land NFT collection, minting,\n                          listing, cancellation, and purchase flows…\"\n\n3land_buyNFT             \"Purchase an NFT from a 3.Land listing.\n                          SAP MCP context: Protocol 3land; operation class\n                          write. Use for 3.Land NFT collection, minting,\n                          listing, cancellation, and purchase flows…\"\n```\n\nCreating a collection and buying one are different operations, and the opening sentence says so — in 8 words out of 59. The other 51 are identical across both, and across all 275.\n\nThat block was added deliberately, to help.\n\nThis is the part worth internalising, because it's counterintuitive.\n\nFour tools from a widely-installed Gmail server:\n\n```\nGmail_DeleteDraftEmail   \"Delete a draft email using the Gmail API.\"\nGmail_SendDraftEmail     \"Send a draft email using the Gmail API.\"\nGmail_ListLabels         \"List all the labels in the user's mailbox.\"\nGmail_SearchThreads      \"Search for threads in the user's mailbox.\"\n```\n\nEvery one of those is clear, correct English. No reviewer would flag them. Every one is also built entirely out of words the other tools use — delete, draft, email, gmail, api, list, search, threads, mailbox all recur across the set.\n\nThe description tells you what the tool does. It doesn't tell you what *this* tool does and the others don't. That second thing is what a model needs at the moment it's choosing, and it's a different question from \"is this description good.\"\n\nLook at the right-hand column again. Parameters with no description at all sit between 20% and 25% at every size above the smallest bucket. It doesn't improve as servers get smaller.\n\nA two-tool server has the habit about as much as a two-hundred-tool one.\n\nSo the two failures are independent. Splitting a large server reduces your description collisions and does nothing whatsoever for your undescribed parameters. They need separate fixes, and the split only buys you one of them.\n\nSplit when the collisions are real, not because you crossed a number.\n\nThe threshold in the data is around thirty, but that's a population average and your server isn't the population. A server with forty tools that all do genuinely different things to genuinely different objects may be fine. A server with twelve tools where four of them are variations on \"search\" is not.\n\nThe test that actually tells you: read your tool list as one block, the way a model receives it. Nothing else. No README, no repo, no memory of what you meant. Then ask which tool you'd pick for a request that could plausibly go to two of them.\n\nThree options when the answer is \"I can't tell\":\n\n**Rewrite for contrast rather than clarity.** Not \"is this description clear\" but \"is it clear which of my tools this is.\" If you have a shared preamble on every tool, it's costing more than it's buying — the distinguishing sentence shouldn't be a seventh of the text.\n\n**Collapse near-identical tools into one with a mode parameter.** Four search variants become one `search` with a `scope` enum. Fewer things to choose between, and the choice the model has to make moves from \"which tool\" to \"which value,\" which an enum can constrain and a description can't.\n\n**Split the server.** Fewer tools per connection, more servers to maintain. Worth it when the tools genuinely belong to different domains, less so when you're just cutting an arbitrary list in half.\n\nThis is static analysis. I never ran a model against any of these servers, so I can't tell you how often collisions actually cost anything. A zero-distinctive description might be harmless when the tool name is unambiguous, and expensive when it isn't. Ranking these signals by how well they predict a real mistake needs a model in the loop, which is the next study.\n\nOne more hole, found by a server author after I published: the undescribed-parameter figure measures *absence* only. A parameter described as `\"query: The query\"` counts as described and passes. Restating the parameter name is arguably the more common failure and it passes every linter, so 21.8% is a floor.\n\nData and analysis scripts: [https://github.com/getmcpulse/mcp-schema-study](https://github.com/getmcpulse/mcp-schema-study)\n\nIf you want your own numbers rather than the corpus averages, there's a free checker at [https://getmcpulse.com/check](https://getmcpulse.com/check) — paste your `tools/list` JSON and it scores your distinctive share, undescribed parameters, and token cost against all 4,951 servers. Browser only, nothing uploaded.\n\nI'm building [MCPulse](https://getmcpulse.com), an SDK that reports what models actually do with your tools once real traffic arrives. Everything above came from outside the server, which is exactly its limit: a schema can tell you a model has nothing to choose on, but only traffic tells you whether it chose wrong.\n\n*Originally published at [getmcpulse.com](https://getmcpulse.com/blog/should-you-split-a-large-mcp-server).*", "url": "https://wpnews.pro/news/how-many-tools-should-an-mcp-server-have", "canonical_source": "https://dev.to/getmcpulse/how-many-tools-should-an-mcp-server-have-2ang", "published_at": "2026-09-14 06:52:52+00:00", "updated_at": "2026-09-14 07:02:01.230543+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools", "large-language-models"], "entities": ["MCP", "Gmail", "3.Land"], "alternates": {"html": "https://wpnews.pro/news/how-many-tools-should-an-mcp-server-have", "markdown": "https://wpnews.pro/news/how-many-tools-should-an-mcp-server-have.md", "text": "https://wpnews.pro/news/how-many-tools-should-an-mcp-server-have.txt", "jsonld": "https://wpnews.pro/news/how-many-tools-should-an-mcp-server-have.jsonld"}}