Four numbers decide whether a server behaves well inside a client, and none of them are in the protocol. They are client policy, documented separately by each vendor, read on 2026-09-08.
| Limit | Value | Client |
|---|---|---|
| Tool description and server instructions | truncated at 2KB each | Claude Code |
| Tool output warning | 10,000 tokens | Claude Code |
| Tool output maximum | 25,000 tokens, MAX_MCP_OUTPUT_TOKENS to change | Claude Code |
| Tools available at once | 100 | Windsurf, Cascade |
Claude Code truncates tool descriptions and server instructions at 2KB each, and its guidance is to put critical details near the start. That is a hard constraint on the only text the model reads before deciding whether to call your tool. Everything that matters, and particularly what the tool must not be used for, goes in the first sentence.
With tool search enabled, only tool names and server instructions load at session start, and the full definitions are fetched when needed. That makes the server instructions field more important, not less: it is what the model searches against. Claude Code's own advice to server authors is to say what category of tasks the tools handle, when to search for them, and the key capabilities.
A tool returning a whole CSV, a full PDF text extraction or an unbounded list will meet 25,000 tokens before it meets any limit of yours, and the result looks to the user like your server truncating. It is not; it is documented client behaviour, and it does not appear in any log.
The fixes, in the order worth trying: return a summary with a count and offer detail on request; paginate with an explicit cursor argument; write the full result to a file and return the path. The third is underused and often the right answer, because the user wanted the file more than they wanted the bytes in the conversation.
Two escape hatches exist on the client side. MAX_MCP_OUTPUT_TOKENS raises the ceiling
for a session. A tool that sets anthropic/maxResultSizeChars uses that value instead for
text content regardless of the environment variable, though tools returning image data stay subject to
the token limit.
Windsurf's Cascade reaches at most 100 tools at once and every enabled server spends from it. Claude Code imposes no fixed per-server cap; its documentation says the practical limit is the context window budget.
The number that makes this concrete: one tools/list against the office-suite bundle in
this repository on 2026-09-07 returned 292 tools from 31 child servers. That single
entry is nearly three times Windsurf's ceiling on its own. Convenient when you do not know in advance
what you will need, and unusable as a default.
A model also chooses worse from a longer list, which is the cost nobody bills you for. Two servers you use daily beat twenty you installed because they were free.
claude mcp list # every entry here spends budget in every conversationSources: docs.claude.com/en/docs/claude-code/mcp for the 2KB, 10,000 and 25,000 figures and the tool search behaviour, docs.devin.ai/desktop/cascade/mcp for the 100-tool ceiling, both read 2026-09-08. The 292-tool measurement is from this repository's own bundle.
No. The specification does not bound a result's size, so every number here is a client policy that can differ between clients and change between versions. Design for the tightest one you know about rather than for the protocol.
Few enough that a person could read the list. The servers in this repository run from 6 to 15 tools each, which sits comfortably inside every documented ceiling when three or four are installed together.
The model sees the first 2KB. Nothing errors and nothing warns, so a long description simply loses its ending, which is where people tend to put the caveats.
Barely, which is the point. A path is a few dozen characters and the content stays on disk where the user can open it with a tool that is better at it than a chat window.
All MCP servers and prices · All guides · Buy the bundle $39