Context
Claude flagged that the GitHub workflow MCP create_issue tool accepts assignees, but its OpenAPI contract does not document whether the @me alias is valid. Exploration verified the behavior is real because IssueService.createIssue() passes assignee values unchanged to gh issue create --assignee, and gh issue create --help documents @me as self-assignment.
The Problem
The MCP schema currently documents manage_issue_assignees as accepting @me, but create_issue only describes assignees as GitHub user logins. Agents can and do use @me for self-assignment, but the contract surface does not advertise that create-time alias. This creates unnecessary uncertainty and encourages re-derivation.
The Architectural Reality
ai/mcp/server/github-workflow/openapi.yaml documents manage_issue_assignees special values, including @me.- The
create_issue schema in the same file only says assignees are GitHub user logins.
ai/services/github-workflow/IssueService.mjs forwards every assignees[] value unchanged into gh issue create --assignee.gh issue create --help confirms the delegated CLI supports @me for self-assignment.
The Fix
Update the GitHub workflow MCP contract and adjacent JSDoc so create_issue.assignees explicitly documents @me as resolving to the authenticated GitHub user. Add a focused regression test that protects the OpenAPI contract from drifting back.
Contract Ledger Matrix
| Target Surface |
Source of Authority |
Proposed Behavior |
Fallback |
Docs |
Evidence |
create_issue.assignees[] |
gh issue create --assignee plus IssueService.createIssue() pass-through |
Document @me as authenticated-user self-assignment |
Literal GitHub login strings remain valid |
openapi.yaml, IssueService.createIssue() JSDoc |
gh issue create --help; source inspection |
Decision Record impact
None. This is contract documentation for an existing delegated behavior.
Acceptance Criteria
Out of Scope
- Adding
@copilot to the MCP contract. The existing MCP manage-assignees surface only advertises @me, so this ticket should not broaden the public contract by accident.
- Migrating
create_issue away from the existing CLI-backed implementation.
- Changing permission checks, ProjectV2 attachment, labels, or assignee mutation behavior.
Avoided Traps
- Do not implement custom
@me resolution in the MCP service; the current delegated CLI behavior already resolves it.
- Do not treat this as a generic assignee-management refactor. The observed friction is missing contract documentation.
Related
- Discussion #11119 (
create_issue ProjectV2 contract history)
- Issue #10426 (separate Memory Core mailbox
@me behavior; related alias concept, different subsystem)
Origin Session ID: 1578fb3e-7f5a-4b43-a6d0-ba00e66a9885
Retrieval Hint: "create_issue assignees @me GitHub workflow MCP contract"
Context
Claude flagged that the GitHub workflow MCP
create_issuetool acceptsassignees, but its OpenAPI contract does not document whether the@mealias is valid. Exploration verified the behavior is real becauseIssueService.createIssue()passes assignee values unchanged togh issue create --assignee, andgh issue create --helpdocuments@meas self-assignment.The Problem
The MCP schema currently documents
manage_issue_assigneesas accepting@me, butcreate_issueonly describes assignees as GitHub user logins. Agents can and do use@mefor self-assignment, but the contract surface does not advertise that create-time alias. This creates unnecessary uncertainty and encourages re-derivation.The Architectural Reality
ai/mcp/server/github-workflow/openapi.yamldocumentsmanage_issue_assigneesspecial values, including@me.create_issueschema in the same file only saysassigneesare GitHub user logins.ai/services/github-workflow/IssueService.mjsforwards everyassignees[]value unchanged intogh issue create --assignee.gh issue create --helpconfirms the delegated CLI supports@mefor self-assignment.The Fix
Update the GitHub workflow MCP contract and adjacent JSDoc so
create_issue.assigneesexplicitly documents@meas resolving to the authenticated GitHub user. Add a focused regression test that protects the OpenAPI contract from drifting back.Contract Ledger Matrix
create_issue.assignees[]gh issue create --assigneeplusIssueService.createIssue()pass-through@meas authenticated-user self-assignmentopenapi.yaml,IssueService.createIssue()JSDocgh issue create --help; source inspectionDecision Record impact
None. This is contract documentation for an existing delegated behavior.
Acceptance Criteria
create_issueOpenAPI description or assignee property explicitly documents@me.IssueService.createIssue()JSDoc mirrors the@mecontract.create_issue.assigneesOpenAPI contract mentions@me.Out of Scope
@copilotto the MCP contract. The existing MCP manage-assignees surface only advertises@me, so this ticket should not broaden the public contract by accident.create_issueaway from the existing CLI-backed implementation.Avoided Traps
@meresolution in the MCP service; the current delegated CLI behavior already resolves it.Related
create_issueProjectV2 contract history)@mebehavior; related alias concept, different subsystem)Origin Session ID: 1578fb3e-7f5a-4b43-a6d0-ba00e66a9885 Retrieval Hint: "create_issue assignees @me GitHub workflow MCP contract"