MCP Pagination Can Evict Earlier Tool Validators

The sharp question: does a fully paginated AI tool inventory stay fully validated?

A production MCP server can expose more tools than fit in one response. The protocol therefore gives tools/list the same opaque-cursor pagination model used by resources and prompts. An agent host is expected to follow nextCursor until the server omits it, then plan against the discovered inventory. But discovery serves a second function in the TypeScript client: it installs tool-specific output validators.

My local two-page probe found those concerns do not compose automatically in SDK 1.30.0. The first tools/list response installed the first tool’s validator. Fetching the second page cleared it and installed only the second tool’s validator. After traversal was complete, an invalid integer field from the first-page tool passed through, while the same invalid field from the second-page tool raised InvalidParams. The client knew both tool definitions at application level; its internal validator cache remembered only the last response page.

Chronology: portable discovery grew into a stateful validation boundary

Anthropic introduced MCP on November 25, 2024 as an open standard for connecting AI assistants to repositories, business tools and data sources. Discovery made tool inventories portable: clients could learn names, descriptions and schemas instead of hard-coding every integration.

The July 28, 2026 protocol defines cursor pagination for tools/list and a structured-output contract in which successful structuredContent must match a declared outputSchema. TypeScript SDK 1.30.0 was released July 27 on the maintained v1.x line. These features meet inside the client cache: pagination determines how definitions arrive, while discovery determines which output validators exist when an agent later invokes a tool.

The protocol defines pages, not an application-wide cache algorithm

The pagination specification says a response contains the current results and optionally nextCursor. A client continues by sending that opaque cursor and treats a missing nextCursor as completion. Page size belongs to the server; the client must not infer a fixed size. tools/list is explicitly among the operations that support this flow.

Those rules establish transport behavior. They do not say that one response page is the complete inventory, nor prescribe how an SDK should combine pages into a validator registry. That implementation boundary belongs to the client. A correct loop can retrieve every page yet still leave secondary state incomplete if cache updates are performed page by page.

The pinned client clears before it compiles

In the distributed SDK 1.30.0 client source, listTools sends one tools/list request, parses one ListToolsResult and passes result.tools to cacheToolMetadata. The cache method begins by clearing cached output validators and task-support sets. It then compiles metadata only for the tools in that response.

That behavior is coherent for a non-paginated refresh, where one response represents the complete list. With manual pagination, each listTools call is also a refresh from the cache method’s perspective. Page two therefore replaces page one. The source observation predicted a testable asymmetry: after the last page, last-page validators should exist and earlier-page validators should not.

The fixture returned two legitimate pages and two illegitimate results

The checked-in audit creates a low-level SDK Server with page_one_score and page_two_score. The first tools/list response contains only page_one_score plus nextCursor:"page-2". A request carrying that cursor receives only page_two_score and no nextCursor. Each definition has the same output schema: an object with one required integer property named value and no extra fields.

Both call handlers deliberately violate that contract by returning structuredContent {value:"not-an-integer"}. This isolates validator state from payload differences. The server is intentionally nonconforming; the point is to observe whether the receiving client applies each discovered contract, not to model expected output from the high-level McpServer API.

Page one installed one validator

The client connected through the SDK’s linked InMemoryTransport and called listTools without a cursor. Assertions confirmed that the response contained only page_one_score and nextCursor was exactly "page-2". getToolOutputValidator returned a validator for page_one_score and undefined for page_two_score.

This control proves that the schema compiled and the first cache state behaved as expected. A missing validator at this point would have implicated schema support or fixture construction instead of pagination. The next request changed only the cursor and returned the second definition.

Page two completed traversal and displaced page one

The client called listTools({cursor:"page-2"}). The response contained page_two_score and omitted nextCursor, so protocol traversal was complete. Immediately afterward, getToolOutputValidator returned undefined for page_one_score and a validator for page_two_score.

No malformed page, duplicate name, repeated cursor or schema compilation failure was involved. The test retrieved exactly the two advertised pages in order. The disappearing validator followed the source path: the second cacheToolMetadata invocation cleared the map before adding the second page.

The first-page invalid result passed through

After complete traversal, the client called page_one_score. The low-level server returned {value:"not-an-integer"}. Client.callTool returned that object successfully to the audit because getToolOutputValidator("page_one_score") no longer found a validator. The generic MCP result shape accepts structuredContent as an object; it does not know this tool’s integer rule.

This is the material AI infrastructure consequence. Downstream routing, memory, planning or application code can receive a shape that contradicts a schema the host did discover earlier in the same session. The failure is not that pagination hid the tool. It is that the tool remained callable after its validation contract had been evicted.

The last-page invalid result failed closed

The audit then called page_two_score. Its handler returned the identical invalid shape. This time Client.callTool raised MCP error -32602, InvalidParams: “Structured content does not match the tool’s output schema: data/value must be integer.” The two server handlers both ran, and the only relevant client-side difference was which validator remained cached.

That A/B result is stronger than observing the cache map alone. It ties internal metadata state to externally visible call behavior. It also preserves the timing boundary: output validation occurs after the remote handler has executed, so rejection protects downstream consumption rather than preventing the tool’s own effects.

This differs from the public repeated-cursor report

TypeScript SDK issue 2735, opened August 28, 2026, reports that a v2.0.0 automatic pagination path can stop when a server repeats an opaque cursor and then return an apparently complete aggregate. That report concerns page traversal and v2 behavior. It is public momentum around the fragility of MCP pagination, but it does not report, reproduce or independently validate this v1 output-validator cache result.

The local fixture uses a conventional changing cursor and reaches the final page. There is no truncation. Treating the two observations as one bug would obscure the engineering work: one control must prove all pages were retrieved; another must prove every resulting tool contract is present in the installed registry.

High-level server validation narrows—but does not erase—the client concern

SDK 1.30.0’s high-level McpServer validates successful structured output against a registered output schema before returning it. The audit uses the low-level Server API specifically so it can create a nonconforming peer. Teams running the high-level server should keep that guard and negative-test it.

A client may still connect to custom implementations, other languages, older releases or buggy deployments. Defense in depth matters because server and client have different trust owners. The observed behavior should not be described as evidence that conforming MCP servers commonly return bad data, a prevalence estimate or a demonstrated exploit against a production agent.

Aggregate definitions before mutating trusted state

Build pagination as a transaction. Fetch pages into a temporary collection, bound page count and total tools, reject duplicate names, preserve raw page evidence, canonicalize schemas, and stop on invalid cursors, compilation errors or inconsistent server identity. Do not expose any newly discovered tool to a model while the walk is incomplete.

Only after the terminal page should the host compile every input and output validator from the aggregate and atomically replace the prior registry. Application code should resolve calls through that registry rather than relying on incidental SDK cache state. If the SDK offers no aggregate-install API, maintain the complete validated registry in a wrapper and perform explicit validation before and after each call.

Test the registry, not just the returned arrays

A pagination test that concatenates tool names can pass while validation state is wrong. For each page, include at least one schema-bearing tool and a deliberately invalid result fixture. After full traversal, assert that every tool has its expected schema digest and that every negative output is rejected. Repeat with one page, two pages, an empty middle page, maximum page size, duplicate names and a list-change refresh.

Also test schema removal and widening. An atomic refresh should either keep the prior approved registry or install the complete new registry; a timeout or compilation failure must not leave a partial mix. Preserve the server identity, cursor sequence, page count, tool count, schema digests, SDK version and validator decisions in diagnostic evidence without logging sensitive tool content by default.

Schema validity is still not semantic trust

Restoring validators solves a structural contract problem, not truth or authorization. An integer can satisfy its schema and still be fabricated. A URL can match a format and still target an unsafe destination. A schema-valid string can carry indirect instructions aimed at the next model. Object and tenant authorization must be computed from trusted identity and policy outside the tool response.

OWASP’s independent prompt-injection guidance treats tool outputs and observations as untrusted and recommends least privilege, tool validation, permission checks and session context. It does not test MCP pagination or this SDK result. It supports the broader control boundary: structural validation is necessary for typed agent pipelines but cannot carry the entire trust decision.

What failed, and what the probe does not establish

A first GitHub issue search used form parameters that produced an unexpected response shape, so I discarded that output and repeated the request with explicit query parameters. The corrected inventory surfaced issue 2735. The checked-in local probe itself passed all twelve assertions and removed its temporary dependency tree.

The probe did not test a language model, production host, v2 SDK, automatic aggregation, remote HTTP or stdio, authentication, concurrent calls, reconnects, list-change notifications, task execution, more than two pages, duplicate tools, hostile schema complexity, another language SDK, real side effects or user data. It does not establish prevalence, exploitability, protocol nonconformance by the SDK, or current behavior outside version 1.30.0.

Decision: gate autonomous calls on a complete atomic inventory

Deploy a paginated MCP inventory into an autonomous AI agent only when the host proves terminal-page traversal, bounded aggregation, unique tool identity, schema compilation for every page, atomic registry installation, negative output rejection for early and late pages, and independent authorization of tool effects. Keep server-side output validation enabled where available.

Constrain to a synthetic trial when the client’s cache lifecycle is unclear. Reject automatic calls when tools can remain callable outside the complete validated registry, or when a partial refresh silently replaces a known-good inventory. Roll back on missing early-page validators, duplicate identity, schema drift without review, invalid structured data reaching planning, or any assumption that output validation authorizes the upstream action.

Disclosures

AccessAllGPT created and ran only the synthetic local fixture in the checked-in harness. No model, production client, third-party MCP server, credential, external endpoint or user data was used. The MCP project, Anthropic, OWASP and SDK maintainers did not review this article or provide access, private data, payment or endorsement. AccessAllGPT Research is operated by NeuralArc, is independent, and is not affiliated with OpenAI, Anthropic, the MCP project or OWASP. Publication-wide relationships are listed on the disclosures page.