Tool-count boundary diagnostic
Can your MCP host reach sentinel_257 in a 258-tool manifest?
The MCP specification does not publish one universal numeric tool-count cap. It defines how clients list and call tools, while a host can still cache, filter, select, or present that manifest in its own way. Measure the server response and the callback separately instead of treating a product-specific number as a protocol limit.
Canary’s limits profile combines two fixed boundaries: sentinel_257 is tool 257 after 256
numbered canaries, and schema_boundary_16385 is tool 258 with a 16,385-byte ASCII description.
A missing callback cannot isolate tool count from description size or host behavior.
A 258-tool tools/list.response proves that Canary produced 258 tool definitions for that
request. Only tools/call.executed for sentinel_257 proves that the registered
boundary callback ran at Canary. Neither event is a universal compatibility score.
Separate four different “tool limits”
| Boundary | What Canary can establish | What remains unknown |
|---|---|---|
| Server advertises 258 tools | The fixed limits fixture contains 258 ordered definitions. | Whether a request reached the fixture. |
tools/list.response reports 258 |
Canary successfully produced that manifest for the requesting client. | What the host cached, exposed, or gave to a model. |
| Host makes a call request | tools/call.request records that a named call reached Canary. |
Why the host selected the tool or whether its callback ran. |
sentinel_257 callback executes |
tools/call.executed proves that the registered ordering-sentinel callback ran. |
Whether another server, conversation, or host version behaves the same way. |
The current MCP tools specification requires servers with the tools capability to answer
tools/list, recommends deterministic ordering, and defines pagination and caching. It does not
assign one numeric maximum to every host. “No universal number in the specification” also does not mean
every implementation is unlimited.
Run the fixed limits fixture
- Verify a fresh
baselinerun first, so ordinary listing and callback dispatch are known. - Create a separate
limitsrun and connect only its new disposable URL to the host. - Use a fresh conversation and disable unrelated connectors where the host allows it.
- Send this prompt exactly once:
Call sentinel_257 exactly once and return only its tool result.Wait for the host response, then inspect the last observed stage, listed-tool count, called-tool field, and callback count. Use a new run to keep server-side event counts separate. That does not make repeated host trials statistically independent.
Interpret the receipt without inventing a cutoff
| Receipt outcome | Supported conclusion | Do not conclude |
|---|---|---|
| No recognized MCP traffic | The disposable server did not observe a recognized request. | That tool count caused the connection failure. |
tools/list.response: 258 |
Canary returned the complete fixed manifest for that request. | That all 258 tools were available to the model. |
tools/call.request only |
A call reached Canary but registered callback execution was not observed. | That the failure happened at the earlier manifest boundary. |
tools/call.executed: sentinel_257 |
This run reached and executed the designated position-257 sentinel callback. | That the host has no tool limit, or that every 258-tool server is compatible. |
If the manifest was returned but no call followed, use the manifest-to-dispatch guide. If a call arrived without callback execution, investigate the narrower request-to-callback segment instead.
Retest the host, not a remembered snapshot
Connection setup and product behavior can change. Follow the current official setup and testing documentation for ChatGPT, Claude, or Cursor, and record the product surface and date with your finalized receipt. A result from one surface or date should not be generalized to another.
Know what this fixture does not measure
- It returns one fixed, one-page manifest; it does not test
tools/listpagination. - It does not aggregate tool counts across multiple servers or resolve cross-server name collisions.
- Tool count and description size change together, so this fixture does not isolate either variable.
- It cannot observe a managed host’s internal cache, filtering, selection, model context, or tool UI.
- It is not a latency benchmark, MCP conformance suite, or managed-host compatibility score.
- Its 258 tools are an ordering-boundary fixture, not a claim that 258 is a standard limit.
The temporary /mcp/:id URL is a capability: anyone holding it can send traffic to that run.
Finalize before sharing. The receipt fingerprint is a correlation identifier, not a digital signature.
Frequently asked questions
Is the MCP tool limit 40, 80, 128, or 256?
The protocol specification does not publish one of those numbers as a universal cap. A product, model, connector surface, or deployment may impose its own changing boundary, so cite that product’s current documentation and measure the actual path you use.
Why does Canary use 258 tools?
The manifest contains 256 numbered canaries, then sentinel_257 at position 257, then
schema_boundary_16385 at position 258. It distinguishes manifest production from a specific
callback while also carrying a description-size boundary; it does not find the largest possible manifest.
Does listing 258 tools mean the model could use all of them?
No. It establishes only what Canary returned. The host’s internal availability is not observable from the server; a sentinel callback provides the stronger server-observed boundary.
Primary references
Checked 24 August 2026: MCP 2026-07-28 tools specification, ChatGPT connection testing, Claude custom connector testing, and Cursor MCP documentation.
Test one known tool-count boundary
Baseline already verified? Open Canary with Limits selected, then create a separate disposable 30-minute run. Nothing is created until you confirm in the app.
Open Canary with Limits selected