Clientes MCP: o que perguntam antes de a IA alterar os seus dados

2026-09-29

Todos os clientes MCP que importam em 2026 perguntam antes de um assistente executar uma ferramenta que altera alguma coisa. Essa parte da resposta é aborrecida e tranquilizadora. A parte útil é o que acontece depois da primeira confirmação, porque ninguém clica em «Permitir» quarenta vezes por dia durante muito tempo: cada cliente oferece uma forma de deixar de perguntar, e os clientes diferem muito na precisão dessa forma.

Em resumo: o Claude Code, o Zed, o Cursor e o Devin Desktop permitem aprovar previamente ferramentas MCP individuais pelo nome. O Codex, o motor por trás do aplicativo de desktop do ChatGPT, pode em vez disso decidir a partir das etiquetas do próprio servidor — perguntar por tudo o que não esteja marcado como só de leitura. O VS Code faz as duas coisas ao nível da caixa de diálogo e acrescenta interruptores para todo o espaço de trabalho. Nenhum destes desenhos está errado, mas falham de formas diferentes, e a falha que deve preocupá-lo depende de quem escreveu o servidor.

Esta comparação fica ao lado do nosso levantamento de que clientes MCP conseguem executar um servidor local. Esse responde a «vai arrancar?»; este responde a «o que fará quando o assistente decidir alterar alguma coisa?». Tudo o que se segue foi verificado na documentação de cada fabricante em 29 de setembro de 2026.

A resposta curta

Duas colunas concentram quase todo o significado. «Permissão permanente mais fina» diz-lhe se pode confiar em search sem confiar em share. «Decide pelas anotações?» diz-lhe se o cliente faz essa divisão por si — usando etiquetas que o servidor escreveu sobre si próprio.

O Codex e o aplicativo de desktop do ChatGPT: quatro modos e uma etiqueta

O Codex tem o desenho mais explícito e, como o aplicativo de desktop do ChatGPT, o Codex CLI e a extensão para IDE partilham um único ficheiro de configuração, cobre os três. Cada servidor MCP recebe um default_tools_approval_mode, e qualquer ferramenta pode substituí-lo com tools.<tool>.approval_mode. Os valores documentados são auto, prompt, writes e approve.

O interessante é writes. Nas palavras da OpenAI, «pergunta para ferramentas que não estão marcadas como só de leitura». As pesquisas correm em silêncio, tudo o resto para e pergunta, e uma ferramenta sem qualquer anotação conta como escrita — o padrão seguro quando um servidor não diz nada. Para além dos modos, a documentação de aprovações do Codex indica que chamadas a ferramentas MCP destrutivas exigem sempre aprovação quando a ferramenta anuncia uma anotação destrutiva, a menos que também anuncie uma anotação de leitura.

Uma mudança a conhecer se tiver uma configuração antiga: o Codex deixou de suportar approval_policy = "untrusted", e essa definição descontinuada pode impedir o cliente de arrancar. A confiança num projeto define-se agora com o trust_level do projeto.

O ChatGPT na web funciona pelo mesmo princípio. No modo de desenvolvedor, disponível nas contas Pro, Plus, Business, Enterprise e Education, «as ações de escrita exigem confirmação por padrão»; o ChatGPT respeita readOnlyHint e trata qualquer ferramenta sem ela como escrita. Uma escolha pode ser memorizada por ferramenta durante o resto de uma conversa, e não mais do que isso.

O Claude Code e o Claude Desktop: regras escritas pelo nome

O Claude Code não lê anotações para decidir. Usa regras de permissão em três listas — allow, ask e deny — avaliadas numa ordem fixa: deny, depois ask, depois allow. As ferramentas MCP chamam-se mcp__<server>__<tool>, por isso mcp__notes__search permite uma ferramenta, mcp__notes__get_* permite uma família, e mcp__notes ou mcp__notes__* cobre o servidor inteiro. O modo padrão chama-se agora Manual; os modos mais permissivos incluem acceptEdits, auto, em que um classificador revê as ações em vez de si, e bypassPermissions.

Dois pormenores pendem para a segurança. Os servidores do .mcp.json versionado de um projeto precisam da sua aprovação antes sequer de se ligarem. E o autor de um servidor pode marcar uma ferramenta com _meta["anthropic/requiresUserInteraction"], depois do que o Claude Code mostra a confirmação em todas as chamadas — mesmo em acceptEdits, auto e bypassPermissions.

As definições de conectores do Claude Desktop, em Customize → Connectors, agrupam as ferramentas de um servidor em categorias como só de leitura e escrita/eliminação, e cada categoria ou ferramenta individual pode ser definida como Always allow, Needs approval ou Blocked.

Cursor, VS Code, Zed e Devin Desktop: os editores

O Cursor di-lo sem rodeios: «Por padrão, o Cursor pede aprovação antes de usar ferramentas MCP.» O MCP segue os mesmos Run Modes que os comandos de terminal. Em Auto-review, as chamadas em lista de permissões correm de imediato e tudo o resto passa por um modelo classificador; Run Everything executa todas as chamadas de ferramentas sem perguntar. A lista de permissões aceita entradas server:tool com curingas. Uma armadilha: deixar vazia a lista de ferramentas permitidas de um servidor permite todas as ferramentas desse servidor.

O VS Code chama ao seu nível padrão Manual permissions: tudo o que não estiver aprovado automaticamente precisa de confirmação. A caixa de diálogo permite aprovar uma única utilização ou conceder aprovação para a sessão, o espaço de trabalho ou todas as invocações futuras, e podem definir-se aprovações por ferramenta para cada servidor MCP. Allow all elimina por completo as confirmações, e Assisted permissions, em que um modelo avalia cada chamada, está marcado como experimental. Uma exceção merece atenção: os servidores MCP que vêm dentro de um plugin de agente «são considerados implicitamente confiáveis quando instala o plugin» e saltam a confirmação de confiança separada no arranque. Instalar o plugin é a decisão de confiança.

O Zed tem o sistema de regras mais legível. agent.tool_permissions.default é confirm a menos que o altere, com allow e deny como alternativas. As regras nomeiam as ferramentas MCP como mcp:<server>:<tool_name> e podem ser definidas para permitir sempre, confirmar sempre ou negar sempre, com a negação a prevalecer. A própria confirmação oferece «Allow once», «Deny once» e «Always for» a ferramenta; para ferramentas MCP, só existe a opção ao nível da ferramenta.

O Devin Desktop, o antigo Windsurf, mudou de modelo juntamente com o nome. O seu agente, Devin Local, «substitui os níveis de execução automática por um sistema de permissões mais granular» e, por padrão, pergunta antes de chamar qualquer ferramenta MCP. A partir da confirmação pode permitir uma ferramenta ou todas as ferramentas desse servidor, para a sessão ou de forma permanente, e as regras Deny prevalecem sobre tudo. Os administradores Enterprise podem aprovar previamente servidores ou ferramentas específicos para toda a organização.

O que as anotações podem e não podem fazer

A especificação MCP dá aos servidores um vocabulário para descrever as suas ferramentas: readOnlyHint, destructiveHint, idempotentHint, openWorldHint. Também diz aos clientes até que ponto acreditar nelas: os clientes «DEVEM considerar as anotações de ferramentas não confiáveis, a menos que venham de servidores confiáveis». E pede um humano no circuito, com a capacidade de negar qualquer chamada de ferramenta.

Isso põe em perspetiva os dois desenhos acima. Um cliente que decide pelas anotações, como o modo writes do Codex, é prático com um servidor em que confia: configura uma linha, e cada nova ferramenta de escrita que o servidor acrescente passa automaticamente a pedir confirmação. Com um servidor em que não confia, é exatamente tão seguro quanto a honestidade do servidor. Uma ferramenta que altera dados e se declara só de leitura corre sem confirmação.

Um cliente que o obriga a nomear ferramentas, como o Claude Code ou o Zed, falha ao contrário. Não lhe importa o que o servidor afirma, mas uma nova ferramenta de escrita acrescentada numa atualização só fica coberta se a sua regra for suficientemente larga para a apanhar — ou suficientemente estreita para a deixar de fora e voltar a perguntar. As regras por nome são mais seguras quando escritas como «permitir estas leituras», e não «permitir este servidor».

Uma configuração sensata para um servidor que lê e escreve

Seja qual for o cliente, os mesmos quatro hábitos cobrem a maior parte do risco:

1. Permita as leituras pelo nome, não o servidor inteiro. Pesquisar e ler transcrições é o que um assistente faz o dia todo; é aí que uma confirmação custa mais e protege menos.
2. Mantenha a confirmação em tudo o que partilha ou substitui. Publicar para outras pessoas e sobrescrever texto são os dois tipos de alteração que não se desfazem repondo um valor.
3. Confie nas anotações apenas para servidores em que confia. Para um servidor de um registo que nunca usou, nomeie antes as suas ferramentas em regras.
4. Dê a um cliente menos confiável uma instância só de leitura. Se o servidor suportar um modo só de leitura, um cliente pode ficar limitado à leitura enquanto outro mantém o acesso total.

Sinais de alerta: uma entrada na lista de permissões do Cursor para um servidor com a lista de ferramentas vazia, um plugin do VS Code que ninguém da equipa reviu e «Always allow» clicado numa ferramenta cujo nome não leu.

Como fica isto no Speak-Y

O servidor MCP do Speak-Y foi feito para os dois tipos de cliente. As ferramentas de leitura — pesquisar gravações, ler transcrições, resumos e tarefas, listar etiquetas e canais — levam readOnlyHint e leem a biblioteca diretamente da sua máquina. As ferramentas que alteram alguma coisa — etiquetas, títulos, nomes de oradores, nova transcrição, partilha num canal da equipa — são declaradas como alterando dados e passam pela aplicação Speak-Y em execução, onde cada chamada fica registada e onde podem ser desligadas.

Duas delas estão marcadas com destructiveHint de propósito: retranscribe, porque substitui o texto atual de uma gravação, incluindo correções feitas à mão, e share_to_channel, porque os colegas podem ler uma gravação antes de a retirar. No modo writes do Codex essas confirmações surgem sem qualquer configuração; no Claude Code ou no Zed, permita as ferramentas de leitura pelo nome e deixe o resto em ask.

Se preferir que um cliente só possa ler, inicie o servidor com --read-only na configuração desse cliente: as ferramentas que alteram dados nem sequer lhe são publicadas, por isso não há nada para aprovar por engano. A configuração está a um clique em Configurações → Integrações, e o servidor MCP é gratuito em todos os planos, incluindo o Free.

A confirmação de aprovação é apenas um dos controlos que tornam seguro um assistente que escreve. Os outros — que alterações são reversíveis e o que o registo guarda — são tratados em o que torna seguro o acesso de escrita via MCP, e a documentação MCP tem a configuração cliente a cliente.

FAQ

Os clientes MCP perguntam antes de executar uma ferramenta que altera dados?

Todos os clientes principais perguntam por padrão. O Claude Code, o Cursor, o VS Code, o Zed e o Devin Desktop pedem confirmação antes de uma ferramenta MCP ser executada até que a aprove previamente, e o modo de desenvolvedor do ChatGPT exige confirmação para todas as ferramentas que não estejam marcadas como só de leitura. O que difere é com que precisão se pode aprovar previamente depois: por ferramenta, por servidor, por sessão ou para sempre. Verificado em 29 de setembro de 2026.

Que clientes MCP usam a anotação readOnlyHint para decidir quando perguntar?

O Codex e o ChatGPT fazem-no de forma explícita. O modo de aprovação writes do Codex pergunta para ferramentas que não estejam marcadas como só de leitura e pergunta sempre antes de uma ferramenta que se declare destrutiva, e o modo de desenvolvedor do ChatGPT trata qualquer ferramenta sem readOnlyHint como uma ação de escrita. O Claude Code, o Cursor, o VS Code e o Zed não documentam as anotações como critério de aprovação; as regras são escritas por si, pelo nome da ferramenta.

Posso aprovar automaticamente as ferramentas de leitura e continuar a ser consultado antes das escritas?

Sim, em todos os clientes desta comparação, mas o mecanismo difere. No Claude Code, no Zed, no Cursor e no Devin Desktop permitem-se as ferramentas de leitura pelo nome, como mcp__server__search no Claude Code ou mcp:server:search no Zed. No Codex, o modo writes resolve isso numa linha, confiando que o servidor marca honestamente as suas ferramentas de leitura.

Anotações de ferramentas como readOnlyHint são uma garantia de segurança?

Não. A especificação MCP diz que os clientes devem considerar as anotações de ferramentas não confiáveis, a menos que venham de servidores confiáveis. Um servidor que marque uma ferramenta de escrita como só de leitura anula qualquer política do cliente baseada nessa indicação. Trate as anotações como uma conveniência para servidores em que já confia e nomeie explicitamente as ferramentas nas regras para os restantes.

Qual é a forma mais segura de ligar um servidor de notas de reuniões a um assistente de IA?

Aprovar previamente apenas as ferramentas de leitura, manter a confirmação em tudo o que altera dados e dar aos clientes em que confia menos uma instância só de leitura. Com o Speak-Y, iniciar o servidor com --read-only na configuração de um cliente remove por completo desse cliente as ferramentas que alteram dados, enquanto outro cliente mantém o acesso total com as suas próprias confirmações.