Add manage_discussion MCP tool for GitHub Workflow server (body update support)

Context

Surfaced during the post-publication correction workflow on Discussion #10137 (MX Ideation Sandbox, 2026-04-20). Three corrections needed to land on the Discussion after @tobiu caught factual errors in the first draft — the #10119 precedent for this correction pattern is body annotations at the top (that Discussion has four annotated passes in its author's note). My MCP surface for the GitHub Workflow server has create_discussion and manage_discussion_comment (create/update) but no tool for updating the Discussion body itself. I defaulted to posting correction comments instead, which the thread reader has to reconcile back into the body to get a coherent artifact — the exact "focus window overkill" @tobiu flagged.

The gap was cheap to work around via gh api graphql updateDiscussion mutation in Bash, but that's not discoverable from the MCP tool inventory and adds friction every time a post-publication correction is needed. This ticket is MX in action — model-friction surfacing a concrete tooling gap that should feed the Golden Path.

The Problem

ai/mcp/server/github-workflow/ currently exposes:

Missing:

Symmetric to manage_issue_comment (which handles both issue and PR comments) + the implicit manage_issue for body updates (if that exists; worth checking during implementation).

Consequence of the gap:

• First-draft Discussions with factual errors accumulate correction comments instead of clean body-level annotations (the #10119 style)
• Reader has to parse main-body + N correction comments to synthesize an accurate version
• Model-authored Discussions are especially prone to this because first-draft accuracy is imperfect and correction passes are the expected pattern (per #10119 precedent: 4 annotated passes inline)

The Architectural Reality

Files involved (expected, to be verified during implementation):

• ai/mcp/server/github-workflow/services/ — likely a new method on an existing service (perhaps DiscussionService if one exists; otherwise add alongside create_discussion)
• ai/mcp/server/github-workflow/openapi.yaml — new operation registration
• ai/mcp/server/github-workflow/services/toolService.mjs — serviceMapping entry
• Underlying mutation: GraphQL updateDiscussion(input: {discussionId, body}) — already documented by GitHub API

Pattern to mirror: manage_issue_comment with its create/update action parameter. New tool would be manage_discussion with at minimum an update action (create already has its own tool, though merging them into one manage_discussion with create+update actions is a design call).

The Fix

1. Add manage_discussion tool (or extend create_discussion with a unified manage_discussion supporting create + update actions)
2. Register in ai/mcp/server/github-workflow/openapi.yaml with clear action enum
3. Wire into toolService.mjs serviceMapping
4. Implement the service method calling GitHub's updateDiscussion GraphQL mutation
5. Test via Playwright (following precedent from existing GitHub Workflow tests if any)

Design decision at implementation time: consolidate create_discussion into manage_discussion with create/update actions, or keep them separate (mirroring the distinction between create_issue and manage_issue_comment)? The consolidated form is cleaner for agents; the separate form is consistent with the issue side. Per feedback memory feedback_no_title_prefix_duplicating_labels and general repo convention, consolidation is probably preferred for new surface.

Acceptance Criteria

• manage_discussion tool exists with an update action accepting discussion_number (or node ID) + body
• Registered in github-workflow/openapi.yaml with concise description + action enum
• Wired into github-workflow/services/toolService.mjs serviceMapping
• Underlying GraphQL updateDiscussion mutation implemented correctly (authentication via existing gh token; error handling for non-owned discussions)
• Playwright unit test covering happy path (agent updates their own Discussion body) + rejection path (agent tries to update someone else's Discussion → 403)
• McpServerToolLimits.spec.mjs equivalent assertions apply (tool description ≤ 1024 chars, action descriptions concise)
• If consolidation with create_discussion is chosen: backward-compatible migration path for any callers of create_discussion (there's #10137 author note + possibly other code paths — grep first)

Out of Scope

• create_issue body updates — separate concern; the issue side of the API already has body-update affordances via gh issue edit / manage_issue_comment / manage_issue_labels; this ticket is specifically about the Discussion-body gap
• Issue comment body updates — already covered by manage_issue_comment action=update
• Locking / pinning / unlisting Discussions — separate category of operations; keep this ticket narrow
• Discussion category changes — another separate operation

Avoided Traps

• Rejected: rely on gh api graphql Bash workaround indefinitely. It works, but it's a hidden affordance. Next session's agent rediscovers the gap, burns time on it, and either files the same ticket again (duplicate waste) or suppresses the friction (MX loop broken). Filing + shipping is the right resolution.
• Rejected: silently update Discussion bodies via workaround without filing a tooling-gap ticket. That IS the friction-suppression failure mode flagged in MX Discussion #10137 Open Question #5. Not filing when caught = bug in the MX loop.

Related

• Caught during post-publication correction workflow on Discussion #10137 (MX Ideation) — MX in action, first concrete tooling-gap surfaced by the newly-published MX framing itself
• Pattern to mirror: manage_issue_comment with create/update action
• Precedent for body-annotation correction pattern: Discussion #10119 (four annotated passes inline in author's note)
• Scale impact: any future model-authored Discussion will need this tool; becomes load-bearing as the #10119-style ideation pattern scales post-v12.2

Origin Session ID: 5a521819-dc75-4549-888e-fcea818d0401