pull_request_read silently ignores pagination parameters that don't apply to the selected method
維護者通常 1 天內回覆
還沒有人認領這個 Issue。
評估
研究方向
Start in pullrequests.go at the pull_request_read dispatch and review the existing method validation before dispatching. Use utils.NewToolResultError for unsupported pagination parameters, naming the selected method and parameter; done means mismatched page/perPage or after inputs return clear validation errors instead of being ignored.
由索引模型根據 Issue 內容生成。
描述
Describe the bug
pull_request_read exposes two pagination mechanisms in one schema:
page/perPage— used byget_files,get_commits,get_reviews,get_comments,get_check_runsafter(cursor) — used only byget_review_comments
When a caller passes a parameter the selected method doesn't use, the
server silently drops it and returns results as if it were never sent.
There is no error, warning, or hint in the response.
The schema description for after does say "used only by the
get_review_comments method", and the code comment confirms other methods
"ignore after" — but for an LLM caller a description is guidance, not
enforcement. The model sees a pagination cursor in the schema, receives a
page of files, and passes after to fetch the next page. It gets the first
page again and has no signal that anything was ignored.
The symmetric case also applies: passing page to get_review_comments
is silently ignored.
Steps to reproduce
- Call
pull_request_readwithmethod: "get_files"on a PR with more
than one page of changed files,perPage: 10. - Take any non-empty string as
afterand call again with the same
method,perPage: 10,after: "<value>". - Observe: the response is identical to step 1. No error.
Or:
- Call with
method: "get_review_comments",page: 2. - Observe:
pageis ignored, first page is returned.
Expected behavior
A pagination parameter that the selected method cannot honour should
produce a validation error naming the method and the parameter, e.g.
method "get_files" uses page/perPage pagination; "after" is not supported. This is consistent with how the tool already rejects an
unknown method.
Why this matters
Silent parameter drops are worst-case for agentic callers: the tool reports
success with a plausible payload, so the model has no reason to retry.
This is the same failure class as #2347 (silent truncation), and a
follow-up to #2489, which added after to the schema but did not add the
guard.
Suggested fix
Before dispatching on method, check whether the caller supplied a
pagination parameter the method doesn't use, and return
utils.NewToolResultError with a clear message. A small helper in
pullrequests.go covers all nine methods.
Happy to open a PR.
- 主要語言
- Go
- 星號
- 33.1k
- 分支
- 5k
- 平均合併
- 2 天 3 小時
- 30 天內合併 PR
- 18
環境準備
從這裡開始
- 先讀完整個 Issue，再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫，在一個分支上完成修改。
- 送出 Pull Request，並在描述裡引用這個 Issue 編號。
github/github-mcp-server 的其他 Issue
-
bug
難度 2/5 1-3 小時 新手友好度 84/100
github/github-mcp-server#3235 · 1 則留言 ·
維護者通常 1 天內回覆
-
enhancement
難度 1/5 1 小時以內 新手友好度 88/100
github/github-mcp-server#3042 · 2 則留言 ·
維護者通常 1 天內回覆
-
bug
難度 2/5 1-3 小時 新手友好度 72/100
github/github-mcp-server#3032 · 1 個 reaction ·
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 74/100
github/github-mcp-server#2803 · 1 則留言 ·
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 76/100
github/github-mcp-server#2740 ·
維護者通常 1 天內回覆
查看 github/github-mcp-server 的全部 Issue
相似的 Issue
-
難度 2/5 1-3 小時 新手友好度 78/100
siderolabs/terraform-provider-talos#414 ·
維護者通常 1 天內回覆
-
bug
難度 2/5 1-3 小時 新手友好度 78/100
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 70/100
JuliaComputing/jh#63 · 1 則留言 ·
-
area/proxy kind/bug priority/backlog triage/accepted
難度 2/5 1-3 小時 新手友好度 68/100
lexfrei/cloudflare-tunnel-gateway-controller#840 ·
維護者通常 1 天內回覆
-
Priority: Normal Type: Bug
難度 2/5 1-3 小時 新手友好度 78/100
cloudflare/cloudflared#1747 ·