Ask an AI agent for 100 companies and you may get a confident summary of 60. Nothing errored, no warning appeared, and the server returned all 100. The client truncated the payload at a documented ceiling before the model ever saw it, and the model summarised what survived. This is the most common failure in agent-based prospecting and almost nobody knows the number.
The numbers, as published
Anthropic documents these in its connector docs. Verified 25 August 2026:
| Constraint | Claude.ai and Desktop | Claude Code |
|---|---|---|
| Max tool result size | ~150,000 characters | 25,000 tokens (MAX_MCP_OUTPUT_TOKENS) |
| Timeout | 300 seconds | Configurable (MCP_TOOL_TIMEOUT) |
| Sampling | Not supported | Not supported |
| Resource subscriptions | Not supported | Not supported |
Two things are worth noticing immediately.
First, the units differ. Characters on the hosted surfaces, tokens in Claude Code. Those are not interchangeable, and the Claude Code figure is the tighter of the two for the kind of dense JSON a data tool returns. Roughly speaking, 25,000 tokens of JSON is on the order of 100,000 characters, and structured data tokenises worse than prose because every brace, quote and field name costs you.
Second, these are client limits. The same MCP server behaves differently depending on which client you point at it, which means "we tested it in Claude Desktop" is not evidence that it works in Claude Code.
Why this is invisible
A normal failure has someone to report it. This one does not.
From the server's side, the exchange completed. It received a request, ran a query, serialised a full result and returned it. Its logs say success, because from where it sits that is what happened.
From the client's side, a payload arrived and was trimmed to fit a documented budget. That is the client working as designed.
From the model's side, a tool result arrived. Models are not told what was removed, because nothing was removed as far as the message it received is concerned. It reads what it has and answers.
So the question "why did it only give me 60" has no owner. Everyone behaved correctly and the answer is still wrong.
What it actually looks like in prospecting
A few shapes, in rough order of how often we see them:
The short list. You ask for a hundred accounts and get a summary of far fewer. If you never asked how many, you never find out.
The confident wrong count. You ask "how many of these are in the UK" and get a number computed over the surviving subset. It is presented as a count of your search, not of what the model could see.
The vanishing tail. Results are ranked, so truncation removes the bottom. If your ranking is good, that is the least interesting end. If your ranking is inverted, or you asked for something where the tail is the point, you lose exactly the rows you wanted.
The bloated row. One field does the damage. A signal payload carrying a full job description or a company boilerplate blows the budget in a dozen rows rather than a hundred. The cap is on total size, so verbosity per row and number of rows trade off against each other directly.
What to do about it
Ask for fewer, filtered harder. This is the whole answer and it is unsatisfying because it sounds like a workaround. It is not. Twenty accounts you can verify beats a hundred you cannot, and the reason you wanted a hundred was usually that the filters were too loose to trust twenty.
Set the limit deliberately. If a tool exposes a limit parameter, choose it. Defaults are set by someone guessing at a use case that may not be yours. Signl's search_signals defaults to 20 and accepts up to 100; the default is low on purpose, and 100 is available for when you genuinely want it and are watching for this.
Count out loud. Ask the agent how many rows the tool returned before asking it to analyse them. If that number does not match what you requested, you have your answer immediately, and it costs one sentence.
Paginate by filter, not by offset. Split a large query into several narrower ones. Three searches by country return three results you can trust; one search across all three returns one you cannot. As a bonus, the narrower query is also faster, which matters against the 300-second timeout.
Push work to the server. If you want a count, ask for a count rather than a list to count. If you want the top ten by a criterion, express the criterion as a filter rather than fetching a hundred and sorting in the model. Anything that reduces the payload reduces the exposure.
What this means for choosing a data tool
There is a design temptation, when you build an MCP server, to return everything you have. More data reads as more value in a feature comparison, and the cost of the extra fields lands on someone else's budget.
The limits above are why that is wrong. A tool that returns 40 fields per company will fit a third as many companies into a result as one that returns 12, and the reader will never know which trade they got. When you evaluate a data MCP server, the useful questions are what a single row weighs, whether the tool lets you cap the row count, and whether it will tell you how many rows it found rather than only handing you rows.
We built Signl's signal projection deliberately small for this reason: identifiers, company, signal type, score, two timestamps, and a highlights object. The full enrichment record is available through enrich_lead when you ask for one contact, which is exactly the point at which paying for the extra bytes makes sense.
The wider version of this problem
Result size is the limit people hit first, but it is not the only one, and the pattern generalises: the client decides what your agent can actually do, and clients differ.
As of 25 August 2026, Claude supports the 2025-03-26, 2025-06-18 and 2025-11-25 authorization specifications, while the current protocol revision is 2026-07-28. It supports tools, prompts and resources, and does not support sampling or resource subscriptions at all. Those are all client decisions that constrain what any server can offer you through it.
"MCP-compatible" is a floor, not a specification of capability. Before you commit a workflow to a client, read its own documentation for the number that will bite you. It is usually published, it is usually short, and almost nobody reads it until something quietly returns 60 of 100.
Sources
- Anthropic, Building custom connectors. Verified 25 August 2026. Source of the size limits, timeouts, supported auth specs and unsupported features.
- Model Context Protocol, Versioning. Verified 25 August 2026. Source of the current protocol revision.