Show issue_write MCP App form for labels/assignees/milestone/type - #2767
Merged
mattdholloway merged 1 commit intoJun 25, 2026
Merged
Show issue_write MCP App form for labels/assignees/milestone/type#2767mattdholloway merged 1 commit into
mattdholloway merged 1 commit into
Conversation
Copy link
Copy Markdown
Contributor
Sorry, something went wrong.
The issue_write form-gating logic uses issueWriteFormParams to decide whether to render the MCP App form or execute directly: a call carrying any parameter outside that allowlist bypasses the form. The form prefills and re-submits labels, assignees, milestone and type, but those four were absent from the allowlist, so passing any of them skipped the confirmation form even though the form fully supports them. Add labels, assignees, milestone and type to issueWriteFormParams so the form is shown when they are present. The allowlist now covers every input-schema property, leaving issueWriteHasNonFormParams as a forward-compatibility safety net for properties added without form support. Also correct the now-inaccurate show_ui guidance on issue_write and create_pull_request: both descriptions claimed the form "does not collect" fields it actually collects (labels/assignees/milestone/type/issue_fields, and reviewers respectively). Update unit tests and regenerate toolsnaps and docs. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copy link
Copy Markdown
Contributor
There was a problem hiding this comment.
Pull request overview
This pull request aligns the issue_write MCP App UI gating logic with what the issue-write UI form actually supports, ensuring the confirmation form is shown (and prefills/resubmits correctly) when callers provide labels/assignees/milestone/type. It also updates show_ui guidance text for both issue_write and create_pull_request to remove now-misleading “form does not collect …” examples.
Changes:
- Expand issueWriteFormParams to include labels, assignees, milestone, and type, so those inputs no longer force bypassing the MCP App form.
- Update show_ui descriptions for issue_write and create_pull_request to reflect current UI form capabilities.
- Update tests, toolsnaps, and generated docs to match the new gating behavior and updated descriptions.
| File | Description |
|---|---|
| pkg/github/pullrequests.go | Updates create_pull_request show_ui description to remove misleading “form does not collect reviewers” guidance. |
| pkg/github/issues.go | Adds labels/assignees/milestone/type to the UI allow-list and updates issue_write show_ui description + gating commentary. |
| pkg/github/issues_test.go | Adjusts UI-gating tests and schema-classification guardrails for the expanded form parameter set. |
| pkg/github/toolsnaps/issue_write.snap | Regenerated snapshot reflecting the updated show_ui description. |
| pkg/github/toolsnaps/create_pull_request.snap | Regenerated snapshot reflecting the updated show_ui description. |
| docs/insiders-features.md | Regenerated docs reflecting updated show_ui descriptions. |
| docs/feature-flags.md | Regenerated docs reflecting updated show_ui descriptions. |
Copilot's findings
- Files reviewed: 7/7 changed files
- Comments generated: 0
Sorry, something went wrong.
tommaso-moro
approved these changes
Jun 25, 2026
This was referenced Jun 27, 2026
syf2211
added a commit
to syf2211/github-mcp-server
that referenced
this pull request
Jun 27, 2026
…thub#2767) The issue_write form-gating logic uses issueWriteFormParams to decide whether to render the MCP App form or execute directly: a call carrying any parameter outside that allowlist bypasses the form. The form prefills and re-submits labels, assignees, milestone and type, but those four were absent from the allowlist, so passing any of them skipped the confirmation form even though the form fully supports them. Add labels, assignees, milestone and type to issueWriteFormParams so the form is shown when they are present. The allowlist now covers every input-schema property, leaving issueWriteHasNonFormParams as a forward-compatibility safety net for properties added without form support. Also correct the now-inaccurate show_ui guidance on issue_write and create_pull_request: both descriptions claimed the form "does not collect" fields it actually collects (labels/assignees/milestone/type/issue_fields, and reviewers respectively). Update unit tests and regenerate toolsnaps and docs. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Reviewers
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The issue_write tool decides whether to render the MCP App form or execute directly via the issueWriteFormParams allow-list: a call carrying any parameter outside that set bypasses the form (so the model-supplied values aren't silently dropped on form re-submit).
But the issue-write MCP App form actually prefills from toolInput and re-submits labels, assignees, milestone, and type (ui/src/apps/issue-write/App.tsx lines 874–957, 1012–1023). Those four were missing from issueWriteFormParams, so passing any of them made issueWriteHasNonFormParams return true and skipped the confirmation form — precisely in the cases where the form is most useful. This left the gating logic out of sync with what the UI supports (issue_fields, which the form handles identically, was already in the allow-list — the asymmetry confirms the list was simply stale).
The PR forms (create_pull_request, update_pull_request) were already aligned, so no gating change there.
Fix
Tests / generated files
No behavior change for non-UI clients or for the PR tools' execution paths.