Voltar as noticias
Por que eu só construo servidores MCP somente para leitura
MCP ProtocolAltaEN

Por que eu só construo servidores MCP somente para leitura

Dev.to - MCP·9 de abril de 2026

Todo servidor MCP que construo é somente leitura. Listar, pesquisar, obter, ler. Sem criar, atualizar, excluir, ativar, purgar.

Estou executando o Claude Code com --dangerously-skip-permissions em ambientes onde o agente não possui ferramentas MCP com capacidade de escrita e nenhum caminho direto para modificar sistemas de produção. Não tive uma única ação indesejada contra um sistema de produção em meses. Não porque confio que o modelo nunca vai alucinar. Porque as ferramentas às quais ele tem acesso não podem transformar uma ação alucinatória em uma verdadeira escrita de API.

Somente leitura não torna um agente seguro. Remove uma classe inteira de falhas.

O modo de falha não é hipotético

Há um post no r/ClaudeCode onde Claude sugeriu derrubar uma instância de GPU, e então a executou. O usuário nunca confirmou. O modelo disse "destrua o H100 também," tratou sua própria sugestão como confirmação do usuário, e destruiu uma instância em execução com horas de artefatos de construção em cache e núcleos compilados nela.

Claude alucina confirmação do usuário e destrói uma instância de GPU em execução. Fonte: r/ClaudeCode

O modelo mais tarde admitiu: "Eu alucinei que você disse isso. Você nunca disse essas palavras. Eu disse, então executei como se você tivesse concordado."

Se esse agente tivesse ferramentas somente leitura, ele teria lido a lista de instâncias, talvez sugerido derrubar algo, e então... nada. A sugestão morre como texto. Ninguém perde uma máquina.

Como eu realmente uso agentes

Meu fluxo de trabalho com Claude Code é assim: eu peço que ele investigue algo. Ele lê logs, pesquisa código, puxa dados de servidores MCP e volta com uma análise. Se a análise levar a uma ação — criando um ticket no Jira, atualizando uma configuração, implantando uma mudança — Claude a rascunha. Eu reviso o rascunho, então eu faço a ação eu mesmo.

O agente lê e analisa. Eu ajo.

Confio no julgamento do modelo sobre o que escrever em um ticket. O problema é que às vezes ele alucina que eu pedi para ele fazer algo que eu não pedi. Se a ferramenta for somente leitura, o pior que acontece é que ela lê dados que ela já iria ler de qualquer maneira. Se a ferramenta tiver acesso de escrita, o pior que acontece é o post do Reddit acima.

A fadiga de aprovação é o verdadeiro problema

"Mas há um prompt de confirmação antes de ações destrutivas." Claro. Claude Code pergunta antes de executar comandos. O problema é a fadiga de aprovação. Depois de confirmar 50 operações de leitura, você para de ler os prompts. Você clica em sim. E então o 51º é vastai destroy instance 34122719.

A Anthropic escreveu sobre isso em seu post sobre sandboxing. Eles descobriram que prompts constantes de permissão, paradoxalmente, reduzem a segurança porque os usuários param de prestar atenção. A solução deles foi o sandboxing: restringir o que o agente pode acessar para que você não precise perguntar com tanta frequência. Eles reduziram os prompts de permissão em 84% enquanto mantinham a segurança.

Servidores MCP somente leitura seguem a mesma lógica. Se o servidor não pode escrever, você não precisa confirmar gravações. O agente opera livremente dentro do limite de leitura. Sem fadiga, sem confirmação perdida em uma ação destrutiva.

É por isso que eu executo --dangerously-skip-permissions. Parece imprudente até você perceber que todo o conjunto de ferramentas do agente é somente leitura. Não há nada perigoso para pular a permissão.

O que isso não cobre

Servidores MCP somente leitura são uma fronteira, não um modelo de segurança completo para agentes. Se você também der acesso bash ao agente, CLIs de nuvem, kubectl, ou credenciais de produção através de outros canais, esse design não vai te salvar. Claude Code com --dangerously-skip-permissions ainda pode executar comandos shell, editar arquivos e interagir com o que quer que esteja acessível a partir do host. A própria documentação da Anthropic recomenda usar ambientes isolados ao executar em modo de bypass, e sua abordagem de sandboxing combina isolamento de sistema de arquivos, restrições de rede e controles de permissão — não apenas restrições a nível de ferramenta.

Este artigo é sobre a fronteira MCP especificamente. Para mim, essa fronteira importa porque meus agentes se comunicam com sistemas externos quase exclusivamente através do MCP. Mas é uma camada, não todo o stack.

Além do IDE

Há outra razão pela qual me importo com servidores MCP somente leitura: eles são portáteis. Meu fluxo de trabalho é Claude Code hoje, mas os mesmos servidores funcionam em qualquer sistema de agente que fale MCP.

Em um sistema de agente sem cabeça — um onde não há humano no loop e nenhuma shell bash — a fronteira MCP não é apenas uma camada. É a única interface que o agente tem com sistemas externos. Se cada servidor MCP que ele pode alcançar for somente leitura, o agente literalmente não pode modificar o estado de produção. Sem necessidade de sandboxing, sem prompts de permissão, sem fadiga de aprovação. As próprias ferramentas são a proteção.

Isso importa se você estiver construindo sistemas de agentes para outros usuários. Dar a todos os usuários acesso somente leitura à configuração do seu CDN, logs de construção ou registros DNS geralmente é aceitável. Dar a todos os usuários acesso de escrita é uma conversa completamente diferente. Servidores MCP somente leitura permitem que você exponha dados a agentes em escala sem se preocupar com o que acontece quando um deles alucina uma ação.

Para que servidores somente leitura são bons

Eu executo servidores MCP para gerenciamento de CDN, CI/CD, agregação de logs, DNS e gerenciamento de incidentes. Todos somente leitura. As perguntas que faço são: "Qual é a configuração atual do CDN para checkout?" "Qual build falhou na noite passada?" "Compare as regras de cache entre produção e staging." "Rascunhe um ticket no Jira para a mudança de DNS que discutimos."

Claude produz o texto do rascunho. Eu copio para o Jira ou GitHub eu mesmo. Nada neste fluxo de trabalho precisa que o agente escreva no sistema de destino.

O argumento das credenciais

Conseguir uma credencial de API somente leitura aprovada é uma conversa. "Preciso de acesso somente leitura à API de configuração do CDN para um assistente de IA que ajuda engenheiros a investigar problemas." A maioria das equipes diz sim.

Conseguir uma credencial de escrita é diferente. "Preciso que um agente de IA possa modificar configurações do CDN." Isso é uma reunião, uma revisão de segurança, uma discussão sobre procedimentos de rollback, e provavelmente um "não" ou um "vamos revisar no Q3."

Credenciais somente leitura têm um raio de explosão menor e um processo de aprovação mais simples. Elas também cobrem todos os casos de uso que eu realmente tenho.

O que isso significa para servidores MCP

Todo servidor MCP que publico segue isso: somente leitura por design. As melhores práticas de segurança do MCP descrevem a minimização de escopo como um princípio central. Comece com os privilégios mínimos, eleve apenas quando necessário. Meus servidores não elevam.

Se alguém abrir uma issue no GitHub pedindo ferramentas de escrita, a resposta é: "Este servidor é intencionalmente somente leitura. Faça um fork se precisar de operações de escrita." Isso não é preguiça. É uma decisão de design sobre o que eu quero que um agente de IA possa fazer quando ele alucina uma ação às 3 da manhã.

Estou planejando uma série de produ

Contexto Triplo Up

A implementação de servidores MCP somente para leitura pode ajudar empresas brasileiras a evitar erros dispendiosos causados por ações não intencionais de agentes de IA. Essa abordagem reduz a necessidade de confirmações constantes e melhora a segurança operacional. Além disso, facilita a aprovação de credenciais de acesso, tornando a integração de IA mais eficiente.

Noticias relacionadas

Gostou do conteudo?

Receba toda semana as principais novidades sobre WebMCP.