Se você acompanha qualquer conteúdo sobre agentes de IA em 2026, esbarrou na sigla MCP. Aparece em toda ferramenta séria — Claude, Cursor, Windsurf, praticamente todo harness relevante fala em "suporte a MCP" como recurso central. Vale entender o que é, porque a explicação de verdade é mais simples do que o jargão sugere.
O problema que existia antes
Um agente de IA só é útil de verdade quando consegue agir fora da conversa: ler um arquivo, consultar um banco de dados, mandar uma mensagem, buscar na web. [Como já explicamos no post sobre agent harness](/lab/o-que-e-agent-harness), essa camada de ferramentas é parte do harness, não do modelo.
O problema é que, sem um padrão comum, cada integração era um projeto próprio. Conectar um agente ao Google Drive exigia um código. Conectar ao Slack, outro código diferente, com outra forma de autenticação, outro formato de resposta. Cada empresa de ferramenta e cada desenvolvedor de agente reinventava a roda para cada combinação. Isso não escala: com N ferramentas e M agentes diferentes, você teria potencialmente N vezes M integrações distintas para manter.
O que o MCP resolve
MCP significa Model Context Protocol, um protocolo aberto lançado pela Anthropic no fim de 2024 e adotado desde então por praticamente todo o mercado de ferramentas de IA.
A ideia central é separar dois papéis:
* Servidor MCP: um serviço que expõe um conjunto de ferramentas de forma padronizada — "aqui estão as ações que você pode pedir para o Google Drive", por exemplo, com descrição de cada uma e o formato de entrada esperado.
* Cliente MCP: o agente (ou o harness que o hospeda) que se conecta a um ou mais servidores e usa as ferramentas disponíveis.
Com esse padrão, quem constrói uma integração com o Google Drive faz isso uma vez, como servidor MCP. Qualquer agente compatível com o protocolo consegue usar essa integração sem código adicional. A conta que antes era N vezes M vira N mais M: cada ferramenta se integra uma vez ao protocolo, cada agente se integra uma vez ao protocolo, e a combinação entre os dois acontece de graça.
É o mesmo princípio por trás de USB ou HTTP: um padrão comum que qualquer fabricante ou desenvolvedor pode implementar de um lado ou do outro, sem coordenar diretamente com todo mundo do lado oposto.
Como isso aparece na prática
Quando você conecta o Claude ao Google Drive, ao Gmail ou a um servidor de terceiro — como fizemos com o ClickUp em automações anteriores — o que está acontecendo por trás é exatamente isso: o Claude atua como cliente MCP, conversando com um servidor MCP que expõe as ações daquele sistema.
Do lado do modelo, o processo dentro de uma conversa segue um padrão fixo:
* O agente recebe a lista de ferramentas disponíveis, com nome e descrição de cada uma.
* Decide, com base no pedido do usuário, se alguma ferramenta é necessária.
* Chama a ferramenta certa com os parâmetros certos.
* Recebe o resultado e decide o próximo passo — responder, chamar outra ferramenta, ou pedir mais informação.
A qualidade dessa descrição de ferramenta é o que determina se o agente escolhe certo. Servidor MCP mal documentado gera agente que escolhe a ferramenta errada com a mesma frequência que um funcionário mal treinado pega o processo errado.
Por que virou padrão da indústria, não só da Anthropic
O detalhe relevante é que o MCP não ficou restrito ao ecossistema Claude. Por ser um protocolo aberto, outras empresas de IA e ferramentas de desenvolvimento passaram a suportá-lo — o mesmo padrão de convergência que discutimos no post sobre harness: quando várias equipes concorrentes adotam a mesma solução de forma independente, geralmente é porque a solução resolve um problema real, não porque alguém impôs.
Isso tem uma consequência prática para quem avalia ferramenta: suporte a MCP deixou de ser diferencial e virou expectativa mínima. Se uma ferramenta de agente não suporta o protocolo, ela te prende a um conjunto fechado de integrações — e cada nova conexão que você precisar vai exigir código sob medida, o problema que o protocolo existe para eliminar.
O que MCP não resolve
Vale a clareza sobre os limites, porque o termo às vezes é usado como se resolvesse tudo:
* MCP não decide o que o agente pode ou não fazer. A camada de permissão — o que roda sozinho, o que exige confirmação — é parte separada do harness, não do protocolo.
* MCP não garante que o agente escolha a ferramenta certa. Isso depende do modelo e da qualidade da descrição de cada ferramenta.
* MCP não substitui gerência de contexto. Se um servidor retorna muito dado, alguém ainda precisa decidir o que descartar.
MCP resolve exatamente um problema: como conectar ferramentas a agentes sem reinventar a integração toda vez. É a peça de conectividade, não o sistema inteiro.
Fechando
Se você está avaliando um projeto de IA para sua empresa e alguém menciona "integração via MCP", isso significa que a conexão com seus sistemas usa um padrão aberto e reutilizável — em vez de um código de integração fechado que só aquele fornecedor sabe manter. É um sinal de arquitetura saudável, mas é só uma das peças do harness. As outras — permissão, contexto, verificação — continuam exigindo decisão própria, e é aí que a maioria dos projetos ainda erra.