Skip to content

add_issue_comment, update_issue, and get_issue reject valid integer issue_number #2807

Open
#3411
#2808
Open
add_issue_comment, update_issue, and get_issue reject valid integer issue_number#2807
#3411
#2808
Labels
bugSomething isn't workingrequest ai review

Description

@chriszhang08
chriszhang08
opened on Jul 2, 2026

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.

Activity

  1. chriszhang08
    added
    bugSomething isn't working
    on Jul 2, 2026
  2. github-actions
    added
    request ai review
    on Jul 2, 2026

  3. rpelevin commented on Jul 3, 2026

    @rpelevin
    rpelevin
    on Jul 3, 2026

    This looks like an operation-identity boundary bug, not just a parameter type mismatch.

    The invariant I would want is:

    • the schema-accepted issue_number value should have one canonical representation from tool input through URL construction
    • path interpolation must happen after validation, or it must preserve the typed value used for validation
    • any coercion from number to path string should be recorded as transport serialization, not fed back into schema validation
    • add_issue_comment, update_issue, and get_issue should share the same issue identity normalization contract
    • rejection should produce a typed client-visible error that identifies schema stage vs path-construction stage without exposing token or repo secrets

    Tests I would add:

    • integer issue_number accepted for get_issue, update_issue, and add_issue_comment
    • numeric-looking string rejected or normalized according to one documented rule, not depending on endpoint
    • path-bound issue_number and query/body integer params use the same canonicalization test fixture
    • failing validation returns no-effect evidence: no REST call made and no issue mutation
    • retries with the same input produce the same request digest and error stage

    That keeps MCP tool schemas honest while making issue mutations auditable before any GitHub write is attempted.

    Boundary: architecture and conformance feedback only; no claim about GitHub/MCP Server alignment, implementation correctness, acceptance, partnership, integration, customer interest, official alignment, GitHub MCP usage, or Neura usage.

  4. syf2211
    added 2 commits that reference this issue on Jul 8, 2026

    fix(issues): rebase native integer issue_number validation onto main

    505c6ec

    fix(issues): rebase native integer issue_number validation onto main

    35a5d50

  5. CAOShurong commented on Aug 24, 2026

    @CAOShurong
    CAOShurong
    on Aug 24, 2026

    Verified against current main — this appears to be already fixed.

    I built the server from main (64a49f3, go1.26.7) and drove it over stdio JSON-RPC with a real token:

    • issue_read (the modern replacement of get_issue) with "issue_number": 2807 passed as a JSON integer returns the issue normally — no parameter error.
    • Unit-level, the shared coercion helper RequiredInt → toInt in pkg/github/params.go now accepts both float64 and numeric-string representations and rejects NaN/Inf/fractional/out-of-range values, with tests covering the numeric-string path.

    The reporter's hypothesis about URL-path templating was reasonable, but the actual root cause looks like the pre-refactor parameter handling: since the params-helper refactor (commit 21c5a6f, which introduced pkg/github/params.go with the tolerant toInt), integer inputs are coerced correctly on all three tools named here. Note the tool surface has also changed: get_issue/update_issue are now the method-parameterized issue_read/issue_write.

    Suggest closing as fixed; happy to re-check with a specific version if anyone still reproduces this on a release built after 2026-08-17.

  6. harish-gaggar
    added a commit that references this issue on Oct 4, 2026

    fix(params): accept native integer types for numeric tool parameters

    c042498
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingrequest ai review

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions