Repository navigation
Add a server-side option to completely disable MCP Apps #3488
Description
Describe the feature or problem you’d like to solve
Add a server-side option to completely disable MCP Apps.
Currently, --features=mcp_apps_disable_form_deferral prevents write tools from being deferred to interactive forms, but MCP Apps are still enabled and UI metadata/resources are still exposed.
This means the MCP App UI can still open after the operation. This can interrupt the agent workflow and require additional UI interaction even though the underlying write has already been applied.
What is missing is an option to disable MCP Apps entirely at the server level.
Proposed solution
Add an option such as:
--mcp-apps=falseand/or:
GITHUB_MCP_APPS=falseWhen disabled, the server should:
- not expose MCP Apps UI metadata/resources
- not use form deferral
- execute tools normally and return inline results
The default can remain enabled, so this would be fully backwards compatible.
This would complement, not replace --features=mcp_apps_disable_form_deferral
Example prompts or workflows (for tools/toolsets only)
Not applicable. This is a server configuration option rather than a new tool.
Additional context
I use the same GitHub MCP Docker image from multiple MCP clients, each with different ways of enabling or disabling MCP Apps.
A server-side opt-out would provide one deterministic configuration for Docker/headless deployments instead of requiring client-specific workarounds.
Activity
tobiasnaumann commentedon Nov 4, 2026
+1, and I'd like to add a design argument beyond the Claude rendering bug in #2823.
Since the form deferral became the default (Oct 1), every
issue_write/create_pull_requestfrom claude.ai goes through a form. In our case the form collapses after ~1s, so the connector is effectively read-only. But even if the form rendered correctly, I think the approach is wrong:Policy belongs to the user and the host, not the server. The host already has an approval layer (per-tool permissions: "ask first" / "always allow"). The server adding a second, non-configurable approval step means the user can no longer decide what they want to review. Setting the tools to "Always allow" has no effect. If I delegate work to an agent, I decide what needs confirmation, not the tool the agent happens to use.
A form is not a confirmation, it's an editing UI. It puts the user back into operating software, which defeats the point of delegating to an assistant. For low-risk, easily reversible actions like editing an issue in a private org repo, a mandatory form is disproportionate.
Failing closed makes it worse. When the form can't hydrate, nothing happens and there is no fallback.
Suggestions:
destructiveHint,openWorldHint) and let the host apply policymcp_apps_disable_form_deferraluntil then