fetch_manifest_over_mcp: un-cursored resources/list (single-page tools/list, ignores nextCursor)

[mortonanalytics]

Real, out-of-scope for PR #11 (#12–#20) — recording with a re-entry gate.

Defect

src/routes/peers.rs:465 fetch_manifest_over_mcp issues a single tools/list (and the manifest path more broadly a single un-cursored resources/list) and takes result.tools verbatim, never following nextCursor. A peer whose manifest paginates has its tools silently truncated at the allowlist/manifest step.

Contract v1 §8.1 requires IONe to follow nextCursor. The panel paths already do this via src/services/peer_panels.rs:31 (paginated_list with a page cap) — the manifest/allowlist path does not.

Fix direction

Route fetch_manifest_over_mcp (and any peer resources/list/tools/list that reads a full set) through the existing cursor-following helper (peer_panels::paginated_list or equivalent), honoring the same MAX_PAGINATION_PAGES cap and truncation warning. Add a test with a two-page fixture peer asserting all pages are collected.

[mortonanalytics]

Related: the conformance kit itself still fails a conforming peer on pagination — same bug class, same file family as the panel-path pagination it was fixed for. Both the manifest path here and the conformance-kit pagination gap are being fixed in the current PR #11 hardening wave; will close with that PR.

[mortonanalytics]

Fixed in PR #23 (follow-up F10).

fetch_manifest_over_mcp (src/routes/peers.rs:493-530) now follows the cursor, reusing peer_panels::next_cursor rather than adding a third copy of the helper, and honouring the same 50-page cap and truncation warning. The sibling un-cursored site, mcp_client::default_streams, was fixed too — it reuses federation::next_cursor.

That call site also swallowed a JSON-RPC error into {"tools": []} with HTTP 200 — an error path reporting success, which meant a failing peer looked to the operator like a peer with no tools. It now surfaces the error.

One correction to this issue's premise: it describes the manifest path as issuing 'a single un-cursored resources/list'. fetch_manifest_over_mcp never calls resources/list at all — it sends tools/list. Every resources/list call site in the repo already paginated. The two genuinely un-cursored calls were both tools/list. Contract v1 §8.2 has been corrected accordingly, since it repeated the same mistake.

Tests: peer_join_followups_integration asserts all pages are reflected in GET /api/v1/peers/:id/manifest and that a JSON-RPC error surfaces rather than returning 200 with an empty list; mcp_session_integration::default_streams_follows_tools_list_pagination covers the connector path.