Em algumas empresas que estão usando o Model Context Protocol (MCP), observei alguns aspectos que merecem mais atenção e que vou compartilhar aqui.

De maneira geral, quase toda a discussão com elas está concentrada na facilidade de integrar sistemas e disponibilizar ferramentas para os LLMs. Pouco se fala sobre segurança, desempenho, governança e arquitetura operacional.

O MCP representa um avanço importante na padronização da comunicação entre aplicações baseadas em LLMs e ferramentas externas. Assim como protocolos como HTTP padronizaram o acesso a recursos na Web, o MCP busca padronizar como modelos descobrem e utilizam ferramentas, APIs, bancos de dados e outros serviços. Isso reduz significativamente a complexidade das integrações. Mas também amplia o conjunto de capacidades que passam a estar acessíveis aos agentes.

É importante deixar claro que o MCP é apenas um protocolo de comunicação. Os riscos não decorrem do protocolo em si, mas das arquiteturas construídas sobre ele.

Em arquiteturas agentic, por exemplo, o modelo pode decidir quais ferramentas utilizar, em que sequência executá-las, quais parâmetros enviar e como combinar os resultados obtidos. O LLM deixa de apenas gerar texto e passa a participar da orquestração de processos corporativos.

Cada ferramenta adicionada a um servidor MCP representa uma nova capacidade operacional. Consultar um ERP, atualizar um CRM, acessar documentos internos ou iniciar uma operação financeira deixam de ser apenas funcionalidades disponíveis para usuários e passam a integrar o conjunto de ações que podem ser utilizadas pelos agentes.

O primeiro risco que frequentemente encontro envolve identidade e autorização. Quando a identidade do usuário não é propagada ao longo da cadeia de execução, o servidor MCP pode utilizar credenciais próprias para acessar sistemas corporativos. Se essas credenciais possuírem privilégios superiores aos do usuário que iniciou a solicitação, surge um problema clássico de segurança conhecido como Confused Deputy: a arquitetura passa a executar operações que aquele usuário jamais poderia realizar diretamente. O princípio do least privilege continua sendo fundamental. Sempre que possível, a identidade, os papéis e as permissões do usuário devem ser preservados durante toda a execução.

Outro aspecto importante é o Indirect Prompt Injection. Esse risco já aparece na documentação de diversos fornecedores e não se limita a convencer o modelo a gerar uma resposta inadequada. Um documento, e-mail ou página web aparentemente legítimos podem conter instruções capazes de influenciar o planejamento do agente durante o uso das ferramentas. O problema deixa de ser apenas uma resposta incorreta e passa a envolver seleção inadequada de ferramentas, execução de operações desnecessárias ou envio de parâmetros incorretos. Quanto maior a autonomia do agente, maior tende a ser o impacto potencial.

Também observei excesso de contexto sendo compartilhado entre ferramentas. Documentos completos, históricos integrais de conversas e dados pessoais eram enviados quando apenas alguns campos seriam suficientes. Além dos riscos relacionados à privacidade e à LGPD, isso aumenta consumo de tokens, latência e custos. O princípio da minimização de dados continua tão importante em arquiteturas de IA quanto em aplicações tradicionais.

Outro ponto pouco discutido é a chamada capability explosion. À medida que mais ferramentas são disponibilizadas ao agente, cresce o espaço de decisão sobre qual utilizar. Isso pode aumentar a complexidade do planejamento, elevar custos, ampliar a latência e aumentar a probabilidade de escolhas inadequadas.

Também chama atenção o comportamento em cascata das chamadas. Um único prompt pode levar um agente a consultar um servidor MCP, que aciona diversas APIs, bancos de dados e outros serviços internos. Para o usuário parece apenas uma resposta um pouco mais lenta. Nos bastidores, dezenas de operações podem ter sido executadas. Cada nova dependência aumenta a latência, amplia a probabilidade de falhas e torna muito mais difícil identificar a origem de um incidente.

Por isso, observabilidade precisa ir muito além de registrar prompts e respostas. É importante registrar quais ferramentas foram utilizadas, por que foram escolhidas, quais parâmetros receberam, quanto tempo consumiram, quais modelos participaram da execução, qual foi o consumo de tokens, quais permissões estavam associadas ao usuário e correlacionar toda a sequência de chamadas por meio de trace IDs. Sem esse nível de rastreabilidade, auditorias e investigações tornam-se extremamente complexas.

Também chamou atenção a dificuldade para controlar custos. Pequenas mudanças no contexto, na estratégia de planejamento do agente ou na quantidade de ferramentas disponíveis podem alterar completamente a carga computacional. Retries automáticos, chamadas paralelas e cadeias longas de execução tornam o custo muito menos previsível do que em arquiteturas tradicionais. Limites de execução, cache, monitoramento e políticas de uso passam a ser essenciais.

Outro risco pouco discutido é a manipulação das respostas das ferramentas, frequentemente chamada de Tool Poisoning. Normalmente o agente assume que as informações retornadas são confiáveis. Mas um servidor MCP comprometido, uma API vulnerável ou um serviço que retorne dados manipulados podem influenciar decisões posteriores. A saída das ferramentas também deve ser tratada como entrada não confiável.

Vale atenção ainda para arquiteturas multiagentes. Um agente pode acionar outro, que consulta novas ferramentas, que por sua vez iniciam novas execuções. Sem limites de profundidade, mecanismos de contenção e controle de loops, esse comportamento pode provocar explosão de custos, aumento expressivo da latência e ciclos difíceis de interromper.

Outro aspecto frequentemente negligenciado é a idempotência, um princípio fundamental em sistemas distribuídos. Em termos simples, uma operação idempotente pode ser executada mais de uma vez sem produzir efeitos duplicados. Imagine que um agente solicite uma transferência bancária. A operação é concluída, mas ocorre um timeout antes da resposta retornar. Sem saber se a transferência foi realizada, o agente pode tentar novamente. Se não existir um mecanismo de idempotência, o pagamento poderá ser efetuado duas vezes. O mesmo risco existe para criação de pedidos, aprovações, atualizações cadastrais ou qualquer outra operação com efeitos permanentes. Quanto maior a autonomia concedida aos agentes, mais importante se torna garantir que uma nova tentativa não gere uma segunda execução da mesma ação.

No fim, estamos conectando modelos probabilísticos a sistemas determinísticos. Um ERP, um sistema financeiro ou um banco de dados esperam comandos precisos e previsíveis. Um LLM produz a sequência de tokens estatisticamente mais provável dado o contexto disponível. Enquanto o erro de um chatbot normalmente termina em uma resposta incorreta, o erro de uma arquitetura baseada em MCP pode resultar em alterações operacionais reais.

Por isso, minha impressão é que muitas organizações ainda enxergam o MCP apenas como um padrão de integração. Na prática, ele está se tornando uma camada de orquestração entre modelos e sistemas corporativos. E toda camada de orquestração precisa nascer com autenticação, autorização, observabilidade, auditoria, isolamento, limitação de privilégios, mecanismos de contenção de falhas e governança.

A facilidade para conectar ferramentas é justamente o que torna o MCP tão poderoso. E também o que torna sua adoção muito mais complexa do que parece à primeira vista.