github_issue_write silently drops labels when caller lacks AddLabelsToLabelable permission

[HaleTom]

Describe the bug

github_issue_write with method: "create" (and method: "update") silently drops the labels argument when the calling user lacks AddLabelsToLabelable permission on the target repository. The API returns success (issue created/updated, no error), but no label is applied. The failure is only detectable by reading back the issue's labels.

Observed against an upstream repo where the caller is not a maintainer, using a label that verifiably exists in the repository (enhancement, applied via the repo's issue template):

1. github_issue_write create with labels: ["enhancement"] → returns success + issue URL.
2. github_issue_read with get_labels on the created issue → [] (empty).
3. Retried via github_issue_write update with labels: ["enhancement"] → again success, still empty.
4. The label exists in the repo: GitHub_get_label returns the label (color a2eeef, description "New feature or request").
5. The equivalent CLI operation fails loudly: gh issue edit <n> --add-label enhancement exits 1 with a GraphQL permission error (see Logs).

So the MCP tool succeeds silently where the CLI surfaces the permission boundary — the labels field is dropped without any error or warning.

Affected version

Could not capture the server version: the docker daemon is not running in this environment (docker run -i --rm ghcr.io/github/github-mcp-server ./github-mcp-server --version failed with failed to connect to the docker API at unix:///var/run/docker.sock; check if the path is correct and if the daemon is running: dial unix /var/run/docker.sock: connect: no such file or directory).

Environment used: the hosted GitHub MCP endpoint at https://api.githubcopilot.com/mcp/ (as configured by the host client).

Steps to reproduce the behavior

1. Authenticate to the MCP server as a user without AddLabelsToLabelable permission on an upstream repo (i.e. not a maintainer/collaborator).
2. Confirm a label exists in that repo (e.g. via get_label for the label the repo's issue template applies, such as enhancement).
3. Call github_issue_write with method: "create", owner, repo, title, body, and labels: ["enhancement"].
4. View the output — the tool reports success and returns the new issue URL.
5. Call github_issue_read with method: "get_labels" for that issue — the labels list is empty.
6. Repeat with method: "update" adding the same label — same silent drop.

Expected vs actual behavior

• Expected: either the label is applied, or the tool returns an error indicating the label(s) could not be applied (matching the CLI's behavior).
• Actual: the tool returns success with no error, and the label is silently not applied. The caller has no way to know the label was dropped without a read-back.

Logs

gh issue edit confirmation of the permission boundary (CLI fails loudly where the MCP tool succeeds silently):

gh issue edit 44 --add-label enhancement
GraphQL: HaleTom does not have the correct permissions to execute `AddLabelsToLabelable` (addLabelsToLabelable)

get_labels read-back on the issue created by the MCP tool with labels: ["enhancement"]: [].

[CAOShurong]

Verified against main (822c8776) — the report is accurate, and the reason for the silence is structural:

Root cause walk

1. Labels are only ever sent inside the create/PATCH request body: CreateIssue builds github.CreateIssueRequest{Labels: ...} (pkg/github/issues.go ~L2672), UpdateIssue sets issueRequest.Labels when LabelsProvided (~L2758). There is no separate add-labels call anywhere in the codebase (no AddLabelsToIssue usage).
2. Both paths return a MinimalResponse{ID, URL} built from the returned issue and discard everything else (~L2702, ~L2931). The REST response actually echoes the post-write label set, but it is thrown away.
3. So when dotcom silently ignores the labels array for callers lacking AddLabelsToLabelable, the tool has no error to surface and discards the one signal that would reveal the drop.

Reproduced at package level (go1.26.7, worktree at 822c8776): mocked endpoint answering 201 Created with an empty "labels":[] array to a create carrying labels:["enhancement"] returns err == nil. Confirmed: an error-based fix alone cannot detect this class of failure; the information exists only in the returned issue.Labels, which the tool currently drops.

Design options

1. (minimal, zero extra API calls) Include the resulting labels in the tool result — e.g. extend the minimal response with requested_labels vs applied_labels taken from the returned issue. Callers (and agents driving them) immediately see the mismatch.
2. (stronger) Treat requested-but-not-applied as partial failure and warn/error, mirroring the aggregated per-field failure handling UpdateIssue already uses for fallbackDeleteFieldIDs (the "failed=..., cleared=..." pattern at ~L2849).
3. (weakest) Keep current behavior, document the permission boundary in the tool description, and recommend a get_labels read-back.

Note assignees almost certainly behaves identically (same request-body mechanism, same permission model) and would benefit from option 1 for free.

Happy to send a PR implementing option 1 plus tests if maintainers agree that is the desired shape.