René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"`pull_request_read` methods return unbounded payloads that crash IDE clients; `get_review_comments` pagination is broken (`after` param missing from schema)","articleBody":"## Problem\n\nSeveral `pull_request_read` methods return responses large enough to crash IDE-based MCP clients (Cursor, VS Code). The root causes are:\n\n1. **`get_review_comments` advertises cursor-based pagination but doesn't expose the `after` parameter in its schema**, making pagination impossible\n2. **Three methods (`get`, `get_diff`, `get_reviews`) have no pagination support at all**, returning arbitrarily large payloads\n3. **There is no way for the client to control response size** for these methods — `perPage` and `page` are accepted but silently ignored\n\n### Impact\n\nMCP tool responses are loaded entirely into the AI agent's context memory. When a single response exceeds ~50-100 KB, IDE clients like Cursor spike to 100% CPU, become unresponsive, and require a hard restart. This is reproducible and happens consistently on PRs with CodeRabbit or similar AI reviewer comments.\n\nThis effectively makes `pull_request_read` unsafe to call from IDE-based MCP clients for any non-trivial PR.\n\n## Detailed breakdown\n\n### 1. `get_review_comments`: `after` parameter missing from schema\n\nThe method description says:\n\n\u003e Use cursor-based pagination (perPage, after) to control results.\n\nBut the tool's `inputSchema` only exposes:\n\n```json\n\"page\": { \"type\": \"number\", \"description\": \"Page number for pagination (min 1)\", \"minimum\": 1 },\n\"perPage\": { \"type\": \"number\", \"description\": \"Results per page for pagination (min 1, max 100)\", \"minimum\": 1, \"maximum\": 100 }\n```\n\nThere is no `after` parameter. As a result:\n\n- `perPage: 1` returns only the first thread — and there's no way to advance to the next\n- `page: 2, 3, ...` is silently ignored — every page returns the same first thread\n- The only way to get more than one thread is to increase `perPage`, which risks returning a payload large enough to crash the client\n- Agents discover this at runtime, then rationalize increasing `perPage` (\"there are only 5 threads, it should be fine\"), which triggers the crash\n\n### 2. `method: \"get\"` — no pagination, unbounded payload\n\nReturns the entire PR object including body, labels, and all metadata. A PR with a CodeRabbit review summary in the body alone can exceed 100 KB. There are no parameters to limit the response. This is often the first call an agent makes and is enough to crash Cursor by itself.\n\n### 3. `method: \"get_diff\"` — no pagination, unbounded payload\n\nReturns the full diff. Already reported in #625.\n\n### 4. `method: \"get_reviews\"` — no pagination, unbounded payload\n\nReturns full review bodies. A single CodeRabbit review can contain a full summary of all findings, code suggestions, and walkthrough — easily 50+ KB.\n\n## Reproduction\n\n1. Open Cursor IDE with the GitHub MCP server configured\n2. Open a PR that has 5+ CodeRabbit review comment threads\n3. Ask the agent: \"Resolve the PR comments on this branch\"\n4. The agent will call `pull_request_read` with `method: \"get_review_comments\"`\n5. On receiving the response, Cursor spikes to 100% CPU and becomes unresponsive\n\nAlternatively, calling `pull_request_read` with `method: \"get\"` on any PR with a long body (CodeRabbit review summary) is sufficient to trigger the hang.\n\n## Proposed fixes\n\n### Fix 1: Expose the `after` parameter for `get_review_comments`\n\nAdd `after` (string, optional) to the tool's `inputSchema` so cursor-based pagination actually works as documented. This would allow agents to safely fetch one thread at a time.\n\n### Fix 2: Add pagination to `get`, `get_reviews`, and `get_diff`\n\nThese methods currently return unbounded payloads. Options:\n\n- **`get`**: Add a `fields` parameter to select which PR properties to return (e.g., `number,title,state,headRefName` without `body`)\n- **`get_reviews`**: Support `perPage`/`page` pagination like `get_comments` does\n- **`get_diff`**: Support file-based or chunk-based pagination (as proposed in #625)\n\n### Fix 3: Response size limit with truncation\n\nAs a safety net, the MCP server could enforce a maximum response size (e.g., 25 KB) and truncate with a clear indicator:\n\n```json\n{\n  \"truncated\": true,\n  \"truncatedAt\": 25000,\n  \"message\": \"Response truncated. Use pagination parameters to retrieve remaining results.\"\n}\n```\n\nThis would prevent any single response from crashing the client, regardless of which method is called.\n\n## Related issues\n\n- #567 — PR review comments too large, need pagination (open)\n- #625 — `get_pull_request_diff` needs pagination (open)\n- #1286 — Excessive context usage for tools (closed)\n\n## Environment\n\n- **MCP Server**: GitHub MCP via `https://api.githubcopilot.com/mcp/`\n- **Client**: Cursor IDE (v0.48+)\n- **OS**: macOS\n\n---\n\nThat's the full issue. It references the existing issues (#567, #625, #1286) so the maintainers can see the pattern, but frames the problem more broadly — it's not just \"pagination would be nice,\" it's \"your tool actively crashes IDE clients because of unbounded responses and a broken schema.\" The three proposed fixes give them options at different levels: schema fix, pagination support, and a safety-net truncation mechanism.","author":{"url":"https://github.com/NielsKSchjoedt","@type":"Person","name":"NielsKSchjoedt"},"datePublished":"2026-03-02T15:29:36.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":1},"url":"https://github.com/2122/github-mcp-server/issues/2122"}