MCP é a sigla de Model Context Protocol, um padrão aberto criado pela Anthropic no fim de 2024 para que modelos de linguagem conversem com ferramentas e fontes de dados externas por uma interface única. Em menos de dois anos ele deixou de ser proposta de um fornecedor e virou a camada que praticamente todo ecossistema de agentes assume como dada.
Vale entender por quê, porque o motivo não é técnico no sentido estrito. O MCP não trouxe capacidade nova: tudo que ele faz já era possível escrevendo integração à mão. O que ele trouxe foi a eliminação de um trabalho que não gerava valor para ninguém e que toda empresa estava refazendo sozinha.
O problema que ele resolve
Antes do MCP, ligar um modelo aos sistemas da empresa era um problema de multiplicação. Cada modelo tinha o seu formato de declarar ferramenta, cada sistema tinha a sua API, e a ponte entre os dois era código específico para aquele par. Com quatro modelos e dez sistemas, você não escrevia quatorze integrações. Escrevia quarenta, e mantinha as quarenta.
O custo real disso não aparecia no primeiro projeto. Aparecia no segundo, quando o time descobria que a integração com o ERP feita para o assistente de compras não servia para o agente de finanças, porque tinha sido escrita colada no formato de um modelo específico. E aparecia de novo na primeira troca de provedor, quando a decisão de mudar de modelo passava por reescrever a camada de ferramentas inteira.
O MCP transforma essa multiplicação em soma. O sistema expõe as suas capacidades uma vez, num servidor MCP. Qualquer modelo que fale o protocolo consome. Quatro modelos e dez sistemas voltam a ser quatorze peças, e cada uma delas tem um dono claro.
Como funciona, na prática
A arquitetura tem duas pontas. O servidor MCP fica do lado do sistema e publica o que aquele sistema sabe fazer. O cliente MCP fica do lado da aplicação de IA e consome. A conversa entre os dois é JSON-RPC, por entrada e saída padrão quando o servidor roda na mesma máquina, ou por HTTP quando ele é remoto.
O que um servidor publica cabe em três primitivas, e a diferença entre elas importa mais do que parece:
- Tools são ações. Consultar um pedido, abrir um chamado, lançar uma nota. É o modelo pedindo que algo aconteça, e é aqui que mora o risco: tool escreve.
- Resources são dados de leitura. Um documento, uma linha de tabela, o resultado de uma consulta. Servem para dar contexto sem dar poder.
- Prompts são modelos de instrução que o servidor oferece pronto, para que quem integra não precise adivinhar a melhor forma de pedir aquilo.
A separação entre tool e resource é a decisão de design mais subestimada do protocolo. Ela é o que permite dar ao agente acesso amplo de leitura e acesso estreito de escrita, que é exatamente o desenho que passa numa revisão de segurança. Servidor que expõe tudo como tool joga essa vantagem fora.
Por que pegou, quando tantos padrões não pegam
Padrão de integração é uma categoria cheia de tentativas abandonadas. O MCP acertou três coisas que as anteriores erraram.
- Escopo pequeno. Ele resolve transporte e descoberta de capacidade, e para. Não tenta definir como o agente pensa, nem como o modelo é servido, nem como o dado é armazenado. Padrão que tenta padronizar tudo não é adotado por ninguém.
- Custo de adoção quase zero para quem publica. Envelopar uma API que já existe num servidor MCP é trabalho de dias, não de trimestre. Quem tem a API pronta não precisa mudar nada dela.
- Neutralidade real. Nasceu num fornecedor, mas sem amarra a ele. Um servidor MCP escrito para um modelo funciona com os outros, e é por isso que os concorrentes da Anthropic o adotaram em vez de propor o seu.
O que o MCP não resolve, e ninguém avisa
Aqui está a parte que separa demonstração de operação. O MCP padroniza a conversa entre modelo e sistema. Ele não padroniza quem pode falar, o que essa pessoa pode pedir, nem o que fica registrado depois. Essas três lacunas são intencionais, e são exatamente o que uma área de segurança pergunta na primeira reunião.
Identidade
O protocolo não carrega o usuário final. Do ponto de vista do sistema, quem chamou foi o servidor MCP, com a credencial dele. Se o agente atende a diretoria e o estagiário pela mesma conexão, o ERP vê a mesma identidade nos dois casos. Propagar quem de fato pediu é responsabilidade da camada que você constrói por cima.
Autorização
Não existe no protocolo o conceito de permissão por ação. Se a tool de emitir nota fiscal está publicada, ela está disponível. A régua de quem pode acionar o quê, e sob qual limite de valor, vive fora do MCP. Sem essa régua, a única proteção efetiva é não publicar a tool, o que reduz o agente a consulta.
Auditoria
O protocolo não obriga registro de nada. Se ninguém montar a trilha, a resposta para "por que o agente cancelou esse pedido em agosto" é uma reconstrução por aproximação. Para setor regulado, isso não é detalhe operacional: é o que decide se o projeto entra em produção.
A leitura útil é essa: o MCP resolveu o encanamento, e resolveu bem. O que ele deixou em aberto (identidade, autorização, auditoria e controle de custo) é justamente o que separa um agente que impressiona numa demonstração de um agente que a auditoria interna aprova.
Como decidir onde usar
MCP não é resposta para toda integração. Ele rende quando há incerteza sobre qual capacidade vai ser usada, e pesa quando não há.
| Situação | MCP compensa? |
|---|---|
| Vários agentes vão consumir o mesmo sistema | Sim. É o caso canônico: publica uma vez, consome em todos. |
| Você quer trocar de modelo sem reescrever ferramenta | Sim. É o principal ganho de médio prazo. |
| Um agente, uma chamada fixa, um sistema | Não. Chamada direta é mais simples de operar e de depurar. |
| Fluxo determinístico, sem decisão do modelo | Não. Se não há escolha a fazer, não precisa de protocolo de descoberta. |
| O sistema é legado e não tem API | Depende. O MCP não cria a API que falta, só padroniza o acesso a ela. |
Três erros que aparecem sempre
- Publicar toda a API como tool. Servidor com sessenta tools não deixa o agente mais capaz, deixa mais errático: o modelo passa a escolher errado com mais frequência. Publique o que o agente precisa fazer, não o que o sistema sabe fazer.
- Tratar tool e resource como sinônimos. Marcar leitura como tool tira de você a única fronteira barata entre ler e escrever, e é a primeira coisa que uma revisão de segurança vai pedir de volta.
- Deixar credencial no servidor sem escopo. O servidor MCP acaba com um token amplo porque foi assim que ficou pronto mais rápido. Esse token vira o teto real de permissão do agente, e ninguém revisa depois.
Onde isso encosta na Runflow
A plataforma da Runflow fala MCP e traz mais de 150 conectores prontos para ERPs, CRMs, APIs e canais, além das ferramentas internas que o seu time escreve no SDK TypeScript. O MCP entra ali como uma das formas de conectar, e não como a arquitetura inteira.
As três lacunas descritas acima são cobertas pela camada que fica em volta: controle de acesso e aprovação humana antes de o agente agir onde o risco exige, sanitização de dados sensíveis antes de a informação chegar ao modelo, e trilha auditável de cada execução, decisão e chamada de ferramenta. É essa camada que faz a diferença entre um protocolo bem implementado e um agente que a sua área de risco assina embaixo.
Perguntas frequentes
O que é MCP (Model Context Protocol)?
MCP é um padrão aberto criado pela Anthropic no fim de 2024 que define como modelos de linguagem se conectam a ferramentas e fontes de dados externas. Ele usa JSON-RPC entre um servidor, que fica do lado do sistema e publica capacidades, e um cliente, que fica do lado da aplicação de IA. As capacidades são publicadas em três primitivas: tools (ações), resources (dados de leitura) e prompts (modelos de instrução).
Por que o MCP virou padrão para agentes de IA?
Porque transforma um problema de multiplicação em soma. Sem ele, ligar quatro modelos a dez sistemas exige manter quarenta integrações específicas. Com ele, cada sistema publica as suas capacidades uma vez e qualquer modelo compatível consome, o que são quatorze peças. Ele também tem escopo pequeno, custo de adoção baixo para quem já tem API e neutralidade entre fornecedores de modelo.
O MCP resolve segurança e governança de agentes de IA?
Não. O MCP padroniza a comunicação entre modelo e sistema, mas não trata identidade do usuário final, autorização por ação nem registro de auditoria. Do ponto de vista do sistema integrado, quem chamou foi o servidor MCP com a credencial dele, não a pessoa que pediu. Essas três camadas precisam ser construídas por cima do protocolo, e são elas que decidem se o agente entra em produção em setor regulado.
Qual a diferença entre tools e resources no MCP?
Tools são ações que alteram estado, como abrir um chamado ou lançar uma nota. Resources são dados apenas de leitura, como um documento ou o resultado de uma consulta. A separação permite dar ao agente acesso amplo de leitura e acesso estreito de escrita, que é o desenho que passa numa revisão de segurança. Publicar leitura como tool elimina essa fronteira.
Quando não vale a pena usar MCP?
Quando existe um único agente fazendo uma chamada fixa a um único sistema, ou quando o fluxo é determinístico e não há decisão do modelo sobre qual capacidade acionar. Nesses casos a chamada direta é mais simples de operar e de depurar. O MCP também não cria a API que um sistema legado não tem: ele padroniza o acesso a uma API existente.