Summary
Fixes a fundamental contradiction in MCP Apps: show_ui=false caused the server to execute a PR/issue creation up-front, but the host still rendered the MCP App form (because it renders for any tool carrying _meta.ui.resourceUri). The result was a form shown on top of an already-completed action.
Fix has two parts:
- UI Views driven by result:
completedToolResult() helper checks the actual tool result from the host; write Views show success card when the result shows a completed action (not a deferral sentinel), so the form is only rendered while the action is genuinely pending
- Remove
show_ui entirely: Drop the parameter from create_pull_request and issue_write, remove the form-param allowlist entry, delete now-unused ConditionalSchemaPropertyDescriptions, stripUIOnlySchemaProperties, and uiOnlySchemaProperties machinery in pkg/inventory
- Centralize in
ui_capability.go: Extract shared shouldDeferToForm(ctx, deps, req, args, formParams) and hasNonFormParams(args, formParams) replacing three near-identical per-tool functions
Upstream reference
Fork conflict
Mild note. The fork is at v1.4.0 which introduced show_ui (PR github#2601). This backport removes it. The fork's custom tools (issue_graph, set_project_item_status, add_issue_to_project) don't use MCP Apps UI, so no conflict at the tool level — but any caller relying on show_ui behavior on issue_write or create_pull_request will see the parameter silently ignored.
Context
show_ui was broken by design: the MCP Apps 2026-01-26 spec has no per-call opt-out of rendering — the host renders whenever _meta.ui.resourceUri is present. The fix removes the misleading parameter and ensures the View state machine is driven by the actual tool result, not in-app form state.
Summary
Fixes a fundamental contradiction in MCP Apps:
show_ui=falsecaused the server to execute a PR/issue creation up-front, but the host still rendered the MCP App form (because it renders for any tool carrying_meta.ui.resourceUri). The result was a form shown on top of an already-completed action.Fix has two parts:
completedToolResult()helper checks the actual tool result from the host; write Views show success card when the result shows a completed action (not a deferral sentinel), so the form is only rendered while the action is genuinely pendingshow_uientirely: Drop the parameter fromcreate_pull_requestandissue_write, remove the form-param allowlist entry, delete now-unusedConditionalSchemaPropertyDescriptions,stripUIOnlySchemaProperties, anduiOnlySchemaPropertiesmachinery inpkg/inventoryui_capability.go: Extract sharedshouldDeferToForm(ctx, deps, req, args, formParams)andhasNonFormParams(args, formParams)replacing three near-identical per-tool functionsUpstream reference
Fork conflict
Mild note. The fork is at v1.4.0 which introduced
show_ui(PR github#2601). This backport removes it. The fork's custom tools (issue_graph,set_project_item_status,add_issue_to_project) don't use MCP Apps UI, so no conflict at the tool level — but any caller relying onshow_uibehavior onissue_writeorcreate_pull_requestwill see the parameter silently ignored.Context
show_uiwas broken by design: the MCP Apps 2026-01-26 spec has no per-call opt-out of rendering — the host renders whenever_meta.ui.resourceUriis present. The fix removes the misleading parameter and ensures the View state machine is driven by the actual tool result, not in-app form state.