Hardening Model Context Protocol Clients with Bounded Pagination and Conformance Tests
The dart_mcp package introduced bounded pagination helpers capped at 64 pages to prevent infinite loops from buggy or malicious Model Context Protocol servers. It also added automated weekly conformance test suites and streamable HTTP examples.
Impact: Medium
Why it matters
You can protect your autonomous agent loops from hanging by enforcing default page limits on MCP discovery calls and catching protocol regressions early.
TL;DR
- 01Set an explicit page limit (such as 64 pages) when iterating over MCP tool and resource cursors.
- 02Use bidirectional failure baselines when testing against evolving alpha protocol suites in CI.
- 03Return 400 Bad Request instead of 415 when incoming MCP protocol headers fail validation.
Key facts
- Default pagination bound
- 64 pages
- CI conformance trigger
- Weekly, manual dispatch, and PRs touching the package
- Header mismatch error code
- 400 Bad Request
Defensive Pagination for Protocol Clients
Querying an MCP server via standard list calls requires paginating through tool and resource catalogs. In naive client implementations, iterating over nextCursor can result in denial-of-service hangs if a remote server perpetually returns cursor tokens. In PR #682, dart_mcp introduced streaming helpers (listAllTools, listAllResources, listAllResourceTemplates, listAllPrompts) that enforce a default bound of 64 pages. Callers can explicitly pass null to disable the bound, making resilience the default behavior.
Weekly Conformance and Baseline Tracking
PR #675 introduced an automated workflow running the official MCP conformance test suite. To balance the volatility of the upstream alpha npm package against build stability, the maintainers configured CI with continue-on-error while maintaining a checked-in baseline file. The workflow fails in two scenarios: 1. An unlisted test scenario fails. 2. A scenario listed as an accepted failure unexpectedly passes.
This two-way baseline ensures protocol changes and fixed bugs cannot drift unnoticed.
Protocol Edge Cases: Sampling and Status Codes
Two additional pull requests addressed low-level wire compatibility. PR #685 aligned SamplingMessage.content and CreateMessageResult.content parsing with the MCP specification, accepting single content blocks as well as arrays while preserving simplified single-block serialization. PR #684 corrected media type mismatch rejections from status 415 Unsupported Media Type to 400 Bad Request in accordance with the HeaderMismatch schema definition.
Try it in 2 minutes
final toolsStream = client.listAllTools(maxPages: 64);
await for (final tool in toolsStream) {
print('Discovered tool: ${tool.name}');
}dart
✓ When to use
- When building or consuming client libraries for the Model Context Protocol.
- When querying remote or third-party MCP servers with dynamic tool and resource catalogs.
✕ When NOT to use
- When integrating MCP servers that guarantee small single-page tool inventories and lack cursor support.
- When calling external third-party APIs that do not implement the Model Context Protocol.
What to do today
- Audit internal MCP client integrations for unbounded while loops around nextCursor tokens.
- Add a max_pages parameter with a safe default (e.g. 64) to your MCP list requests.
- Set up the MCP conformance test suite in CI with baseline tracking.
Sources