What breaks when pagination is flattened into a single MCP tool call instead of being designed explicitly?

Pagination is where OpenAPI to MCP conversion most often loses meaning. If a tool only exposes the first page, agents may act on partial data and miss records. If the server fetches all pages automatically, latency and cost rise. A separate next-page tool can help when cursor semantics are complex, but it increases tool surface area.

Why This Matters for Security Teams

Pagination looks like a transport detail, but in MCP it changes the meaning of the tool itself. A flattened single call can hide whether the agent is seeing a complete dataset, a partial slice, or a server-expanded aggregate that arrived after expensive backend work. That matters because agents do not behave like human users with predictable reading patterns; they chain tool calls, make decisions from incomplete context, and may treat a first page as the full answer. This is exactly the kind of ambiguity that the OWASP Top 10 for Agentic Applications 2026 warns about when tool boundaries are underspecified.

For NHI and agent governance, the issue is not just completeness. Flattening pagination can also destroy auditability, because investigators cannot easily tell whether missing records were never returned or simply not requested. NHIMG research on the AI Agents: The New Attack Surface report shows how quickly agentic systems outgrow basic oversight when access and behaviour are not explicitly governed. In practice, many security teams encounter missing records only after an agent has already made a downstream decision on partial data, rather than through intentional validation.

How It Works in Practice

Pagination should be designed as part of the tool contract, not hidden behind one generic fetch operation. When an MCP tool returns only the first page, the agent needs an explicit next-page cursor or page token to continue. That makes completeness visible, lets the runtime enforce limits, and creates a cleaner audit trail. When the server auto-follows pages internally, the agent sees a simpler interface, but the server inherits the burden of aggregation, timeout handling, and result shaping. Those tradeoffs are real, and there is no universal standard for this yet.

A practical design usually follows three rules. First, return page metadata every time: cursor, total hints when available, and a clear indicator that more records exist. Second, make the continuation action explicit, either as a separate next-page tool or as a parameterized repeat call with the prior cursor. Third, apply policy checks per page, not just once at the beginning, so access changes or data classification rules can be enforced in real time. That approach aligns with the direction of least-privilege tool use described in the OWASP Agentic Applications Top 10 and with control-oriented guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls.

• Use explicit cursors or tokens so the agent can prove which slice it has already processed.
• Cap page size and total pages to reduce runaway cost and accidental mass retrieval.
• Log each continuation request separately for forensic traceability.
• Prefer server-side aggregation only when latency and data consistency are more important than transparency.

This guidance breaks down when cursor semantics are unstable across backends, such as federated search, eventually consistent indexes, or live datasets that reorder between page requests, because the agent can no longer rely on page order as a stable control boundary.

Common Variations and Edge Cases

Tighter pagination controls often increase implementation overhead, requiring organisations to balance simpler agent experience against stronger correctness and auditability. The biggest edge case is when “flattened” pagination is used for convenience in low-risk read-only tools, but the same pattern later gets reused for sensitive datasets. Best practice is evolving here: current guidance suggests that convenience wrappers should not silently change the semantic meaning of the underlying source.

Another common failure mode appears when pagination intersects with filtering, sorting, or permission trimming. A server that auto-fetches all pages may unintentionally mix records from different policy states, while a client-side agent that stops after the first page may miss exactly the records that matter most. This is especially risky for search, tickets, logs, and entitlement data. NHIMG’s analysis in Analysis of Claude Code Security reinforces a broader point: agentic systems fail when tool boundaries are made too helpful and not explicit enough.

For security teams, the decision is not “single call versus multiple calls” in the abstract. It is whether the tool contract preserves completeness, auditability, and runtime policy enforcement. If those properties cannot be guaranteed, flattening pagination usually trades short-term convenience for long-term blind spots.

Related resources from NHI Mgmt Group

• What breaks when organisations rely on standard DLP controls instead of MCP-layer inspection for AI agent tool calls?
• What breaks when Postgres MCP access is not governed at the tool-call layer?
• What breaks when authentication is still designed around a single browser session?
• What breaks when an MCP tool is compromised inside an automation workflow?