`add_issue_comment`, `update_issue`, and `get_issue` reject valid integer `issue_number`

Bắt đầu với các phần triển khai và các luồng xác thực request của add_issue_comment, update_issue và get_issue, tập trung vào việc nội suy issue_number vào các đường dẫn URL. Tái hiện các lệnh gọi với một số nguyên và so sánh chúng với một tham số số nguyên đang hoạt động như milestone. Được xem là hoàn tất khi các giá trị issue_number dạng số nguyên vượt qua bước xác thực và đến được các endpoint GitHub REST tương ứng, với phạm vi kiểm thử hồi quy cho cả ba công cụ.

Summary

Three endpoints that take issue_number as a required parameter consistently fail when invoked with an integer, even though the tool schema declares issue_number as number. Other endpoints on the same server that take integer parameters work correctly, and the failure survives reconnecting the MCP server.

Affected tools

• add_issue_comment
• update_issue
• get_issue

Unaffected tools (for comparison, same session, same repo, same auth)

• create_issue — succeeds (does not take issue_number)
• list_issues, search_issues — succeed
• create_branch, create_or_update_file, push_files, create_pull_request — all succeed, including calls with integer fields like milestone

Reproduction

1. Any repo the caller can write issues on.
2. Call, e.g.:

   {
     "tool": "add_issue_comment",
     "arguments": {
       "owner": "<owner>",
       "repo": "<repo>",
       "issue_number": 11,
       "body": "test"
     }
   }
   

3. Call fails. Retrying multiple times, including after fully reconnecting the MCP server, reproduces the failure.
4. create_issue against the same repo in the same session succeeds, ruling out auth, permissions, and rate limiting.
5. Reproduced across at least two independent sessions on the same day.

Expected

Comment is posted / issue is updated / issue is fetched, matching a direct REST call to POST /repos/{owner}/{repo}/issues/{issue_number}/comments (etc.).

Actual

Call is rejected before it reaches GitHub. The failure pattern is consistent with issue_number being serialised as a string somewhere in the request pipeline and then rejected by the server's own integer validation.

[TODO fill in with error string on next occurrence]

Hypothesis

The three broken endpoints are exactly the ones where issue_number is templated into a URL path segment (/repos/{owner}/{repo}/issues/{issue_number}[/comments]), whereas the working endpoints pass their integers in the request body or query string. Likely culprits:

• A path-parameter substitution step stringifies the value before an internal validator runs.
• A schema-validation layer runs after path substitution and sees a string where a number is required.

Anywhere issue_number is interpolated into a URL is worth checking first.

Affected version

• MCP server: GitHub MCP http server
• Transport: stdio.
• Client: custom provider

Please run docker run -i --rm ghcr.io/github/github-mcp-server ./github-mcp-server --version and paste the output below

Workaround

None from the client side; the caller cannot influence how the server serialises the parameter. Affected users have to fall back to the GitHub REST API directly or edit the issue in the web UI.