`pull_request_read` methods return unbounded payloads that crash IDE clients; `get_review_comments` pagination is broken (`after` param missing from schema)

[NielsKSchjoedt]

Problem

Several pull_request_read methods return responses large enough to crash IDE-based MCP clients (Cursor, VS Code). The root causes are:

1. get_review_comments advertises cursor-based pagination but doesn't expose the after parameter in its schema, making pagination impossible
2. Three methods (get, get_diff, get_reviews) have no pagination support at all, returning arbitrarily large payloads
3. There is no way for the client to control response size for these methods — perPage and page are accepted but silently ignored

Impact

MCP 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.

This effectively makes pull_request_read unsafe to call from IDE-based MCP clients for any non-trivial PR.

Detailed breakdown

1. get_review_comments: after parameter missing from schema

The method description says:

Use cursor-based pagination (perPage, after) to control results.

But the tool's inputSchema only exposes:

"page": { "type": "number", "description": "Page number for pagination (min 1)", "minimum": 1 },
"perPage": { "type": "number", "description": "Results per page for pagination (min 1, max 100)", "minimum": 1, "maximum": 100 }

There is no after parameter. As a result:

• perPage: 1 returns only the first thread — and there's no way to advance to the next
• page: 2, 3, ... is silently ignored — every page returns the same first thread
• The only way to get more than one thread is to increase perPage, which risks returning a payload large enough to crash the client
• Agents discover this at runtime, then rationalize increasing perPage ("there are only 5 threads, it should be fine"), which triggers the crash

2. method: "get" — no pagination, unbounded payload

Returns 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.

3. method: "get_diff" — no pagination, unbounded payload

Returns the full diff. Already reported in #625.

4. method: "get_reviews" — no pagination, unbounded payload

Returns full review bodies. A single CodeRabbit review can contain a full summary of all findings, code suggestions, and walkthrough — easily 50+ KB.

Reproduction

1. Open Cursor IDE with the GitHub MCP server configured
2. Open a PR that has 5+ CodeRabbit review comment threads
3. Ask the agent: "Resolve the PR comments on this branch"
4. The agent will call pull_request_read with method: "get_review_comments"
5. On receiving the response, Cursor spikes to 100% CPU and becomes unresponsive

Alternatively, calling pull_request_read with method: "get" on any PR with a long body (CodeRabbit review summary) is sufficient to trigger the hang.

Proposed fixes

Fix 1: Expose the after parameter for get_review_comments

Add 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.

Fix 2: Add pagination to get, get_reviews, and get_diff

These methods currently return unbounded payloads. Options:

• get: Add a fields parameter to select which PR properties to return (e.g., number,title,state,headRefName without body)
• get_reviews: Support perPage/page pagination like get_comments does
• get_diff: Support file-based or chunk-based pagination (as proposed in Add pagination support for get_pull_request_diff to handle large PRs #625)

Fix 3: Response size limit with truncation

As a safety net, the MCP server could enforce a maximum response size (e.g., 25 KB) and truncate with a clear indicator:

{
  "truncated": true,
  "truncatedAt": 25000,
  "message": "Response truncated. Use pagination parameters to retrieve remaining results."
}

This would prevent any single response from crashing the client, regardless of which method is called.

Related issues

• PR Review comments too large, need to be able to paginate them #567 — PR review comments too large, need pagination (open)
• Add pagination support for get_pull_request_diff to handle large PRs #625 — get_pull_request_diff needs pagination (open)
• Excessive context usage for tools #1286 — Excessive context usage for tools (closed)

Environment

• MCP Server: GitHub MCP via https://api.githubcopilot.com/mcp/
• Client: Cursor IDE (v0.48+)
• OS: macOS

---

That'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.