mcp-paginationlisted

# MCP Pagination Guardrails (Internal) ## Why this skill exists MCP tools that return lists or search results have no built-in safety net against unbounded responses. Calling `list_issues`, `search_code`, or any similar tool without a limit parameter can return hundreds or thousands of items, consuming 10-100x more tokens than needed, slowing responses, and inflating API costs. Naive implementations skip pagination because the tool "works" without it — this guardrail enforces limits before that mistake reaches production. This skill is invoked by `mcp-builder` via `Skill("mcp-pagination")` when list/search operations appear in an MCP server design. It is not user-facing — users should run `mcp-builder` instead. ## When mcp-builder invokes this skill | mcp-builder phase | Why | |-------------------|-----| | **Phase 1.3** — after cataloging collection endpoints | Set pagination strategy before any tool schemas | | **Phase 3.0** — before each `list_*` / `search_*` / SQL tool | Apply limits and cursor mapping per tool | | **Phase 4.1** — after Inspector testing | Run quick-reference checklist against implemented tools | | **Phase 5** — eval design | Confirm evals use caller-driven pagination, not full scans | If `mcp-builder` passes planned tool names or API pagination params, use them as input for Steps 1–3 below. ## Workflow **Step 1 — Identify list/search operations in the MCP server design.** Any tool whose name matches these patterns needs a limit strategy: - `list_