Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

Non-destructive write tools omit `destructiveHint: false`, causing conservative approval prompts

Aberta
  • Algo errado?
#3,281 1 comentário 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
3/5
Tempo estimado
1-2 dias
Facilidade para iniciantes
72/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
github, go
Domínio
api, backend

Direção de pesquisa

Comece localizando os registros de create_branch e create_pull_request e, em seguida, compare seus ToolAnnotations com create_pull_request_review e delete_file. Audite as outras ferramentas de escrita mencionadas na issue, marcando explicitamente as operações claramente aditivas como não destrutivas, enquanto mantém uma abordagem conservadora em relação ao comportamento de sobrescrita ou exclusão. A tarefa estará concluída quando as anotações relevantes estiverem classificadas e os testes existentes das ferramentas passarem.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

bug request ai review
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
  • #798 — fine-grained confirmation settings for write actions
  • #2723 — label_write delete missing DestructiveHint: true
Linguagem predominante
Go
Estrelas
33.3k
Forks
5.1k
Merge médio
1d 1h
PRs com merge (30d)
19

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de github/github-mcp-server

Todas as issues de github/github-mcp-server

Issues semelhantes

Mais issues de Go

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.