Describe the bug
Some clearly non-destructive/additive GitHub MCP tools set ReadOnlyHint: false but omit DestructiveHint: false.
Under the MCP ToolAnnotations contract, destructiveHint defaults to true when omitted for a non-read-only tool. Clients that honor the conservative default can therefore treat routine additive operations as potentially destructive and require additional confirmation.
This is observable with ChatGPT using the official github-mcp-server over Streamable HTTP / Secure MCP Tunnel: read tools execute automatically when the app is configured with elevated / "Allow all actions" permissions, while routine write tools such as creating a branch or opening a pull request still trigger confirmation.
On desktop, the user can approve for the conversation. On mobile, the same workflow can require repeated per-call approvals.
Examples in the current server
create_branch currently advertises:
Annotations: &mcp.ToolAnnotations{
Title: t("TOOL_CREATE_BRANCH_USER_TITLE", "Create branch"),
ReadOnlyHint: false,
},
create_pull_request currently advertises:
Annotations: &mcp.ToolAnnotations{
Title: t("TOOL_CREATE_PULL_REQUEST_USER_TITLE", "Open new pull request"),
ReadOnlyHint: false,
},
Both operations are additive and appear to be good candidates for an explicit:
DestructiveHint: jsonschema.Ptr(false),
There is already precedent in the codebase: create_pull_request_review explicitly sets DestructiveHint: false, while genuinely destructive tools such as delete_file explicitly set DestructiveHint: true.
Expected behavior
Clearly additive write tools should explicitly advertise DestructiveHint: false instead of inheriting the MCP default of true.
It may also be worth auditing other write tools and explicitly classifying them rather than relying on the default. Tools whose behavior depends on the requested method or which can overwrite/delete existing state should remain conservative.
Why this matters
This does not change security enforcement; MCP annotations are hints. But clients use those hints to drive confirmation UX.
Missing destructiveHint: false makes safe additive operations indistinguishable from potentially destructive writes to conservative clients, which creates significant approval friction in agentic workflows.
Environment
github-mcp-server v1.12.1
- Streamable HTTP transport
- ChatGPT custom MCP app over OpenAI Secure MCP Tunnel
- App permission set to elevated / Allow all actions
- Read operations do not prompt; routine write operations do
Related issues
Describe the bug
Some clearly non-destructive/additive GitHub MCP tools set
ReadOnlyHint: falsebut omitDestructiveHint: false.Under the MCP
ToolAnnotationscontract,destructiveHintdefaults totruewhen omitted for a non-read-only tool. Clients that honor the conservative default can therefore treat routine additive operations as potentially destructive and require additional confirmation.This is observable with ChatGPT using the official
github-mcp-serverover Streamable HTTP / Secure MCP Tunnel: read tools execute automatically when the app is configured with elevated / "Allow all actions" permissions, while routine write tools such as creating a branch or opening a pull request still trigger confirmation.On desktop, the user can approve for the conversation. On mobile, the same workflow can require repeated per-call approvals.
Examples in the current server
create_branchcurrently advertises:create_pull_requestcurrently advertises:Both operations are additive and appear to be good candidates for an explicit:
There is already precedent in the codebase:
create_pull_request_reviewexplicitly setsDestructiveHint: false, while genuinely destructive tools such asdelete_fileexplicitly setDestructiveHint: true.Expected behavior
Clearly additive write tools should explicitly advertise
DestructiveHint: falseinstead of inheriting the MCP default oftrue.It may also be worth auditing other write tools and explicitly classifying them rather than relying on the default. Tools whose behavior depends on the requested method or which can overwrite/delete existing state should remain conservative.
Why this matters
This does not change security enforcement; MCP annotations are hints. But clients use those hints to drive confirmation UX.
Missing
destructiveHint: falsemakes safe additive operations indistinguishable from potentially destructive writes to conservative clients, which creates significant approval friction in agentic workflows.Environment
github-mcp-serverv1.12.1Related issues
label_writedelete is missingDestructiveHint: trueannotation #2723 —label_writedelete missingDestructiveHint: true