O que é MCP? O padrão que liga a IA às suas ferramentas

Toda onda de integração começa com o mesmo problema: N sistemas de um lado, M sistemas do outro, e N × M integrações sob medida para escrever. Aconteceu com bancos de dados, com meios de pagamento, com mensageria. Chegou a vez da IA.

Se você tem 4 aplicativos de IA e quer que cada um leia o seu CRM, o seu ERP, o seu Drive e o seu banco, alguém precisa escrever 16 conectores — e mantê-los quando qualquer uma das 8 pontas mudar. Essa conta é o que o MCP existe para não deixar acontecer.

A tese em uma frase: o MCP transforma N × M integrações em N + M. Cada aplicativo de IA implementa o protocolo uma vez, cada sistema expõe um servidor uma vez, e os dois se encontram sem que ninguém escreva código sob medida para aquele par.

O que é MCP, sem analogia

O Model Context Protocol é uma especificação aberta que padroniza três coisas entre um aplicativo de IA e um sistema externo:

• Descoberta — como o sistema anuncia o que ele sabe fazer
• Invocação — como o modelo pede a execução de uma dessas coisas
• Retorno — como o resultado volta em formato que o modelo consegue usar

O vocabulário tem três papéis, e vale fixar porque toda a documentação usa:

O ponto que costuma passar batido: o servidor MCP é quem executa. Com as credenciais dele, na sua infraestrutura ou na de quem você contratou.

O modelo não ganha acesso ao seu banco. Ele ganha o direito de pedir que uma consulta já definida seja executada. Essa distinção separa uma integração aceitável de uma péssima ideia.

O problema real que ele resolve

Antes de MCP, conectar IA a sistema corporativo tinha três saídas, todas ruins:

• Integração sob medida — funciona e custa caro. Morre no primeiro reprojeto de qualquer das pontas.
• Colar dado no chat — o famoso copiar e colar do relatório. Funciona, não escala e é exatamente como dado sensível vaza.
• Plugin proprietário — resolve dentro de um fornecedor e te amarra a ele.

O MCP não é mais poderoso que uma integração sob medida. É mais barato de manter, e é aí que está o ganho: a mesma implementação serve para o próximo modelo, o próximo aplicativo e a próxima versão.

Dezembro de 2025: por que a doação à Linux Foundation importa

Aqui está o fato que muda a análise, e que quase nenhum conteúdo em português menciona: em dezembro de 2025, a Anthropic doou o MCP à Agentic AI Foundation, sob a Linux Foundation.

Um protocolo controlado por um fornecedor é uma aposta no fornecedor. Um protocolo sob fundação neutra é infraestrutura. A diferença é a mesma que separa "formato do fabricante" de "padrão da indústria" — e ela decide se vale construir em cima.

Esse arco é conhecido de quem acompanha telecom, e este blog já contou a versão anterior dele: as APIs antifraude das operadoras seguiram exatamente o mesmo caminho via projeto CAMARA, também sob a Linux Foundation, como está em o que é Open Gateway. Especificação primeiro, adoção cruzada depois, governança neutra por último. Quando a terceira etapa acontece, o padrão parou de ser negociável.

Os números do ecossistema (e por que eles divergem)

Vale citar com cuidado, porque cada fonte conta uma coisa diferente:

A divergência entre 9,6 mil e 19,8 mil não é erro: são recortes diferentes (registro oficial, índice de terceiro, busca por tópico no GitHub). O que os quatro números concordam é na ordem de magnitude — dezenas de milhares em pouco mais de um ano, o que coloca o MCP entre os padrões abertos de adoção mais rápida que já apareceram.

Todos esses números têm prazo de validade curto. A data ao lado importa tanto quanto o valor — se você está lendo isto muito depois de julho de 2026, reconfira no registro oficial antes de citar.

MCP não é API, não é RAG, não é plugin

Confusão comum, e que atrapalha decisão de arquitetura:

• Não é substituto de API. Na maioria dos casos o servidor MCP fica na frente da sua API, traduzindo-a para um formato que o modelo entende. Se você quer entender o conceito de API por baixo, o blog tem uma lista de APIs públicas com exemplos concretos.
• Não é RAG. RAG busca trechos de texto num acervo por similaridade para o modelo ler. MCP executa uma ação num sistema e devolve o resultado. Um responde "o que os nossos documentos dizem sobre X"; o outro responde "quantos pedidos estão atrasados agora".
• Não é plugin. Plugin é implementação de um fornecedor específico. MCP é especificação que qualquer um implementa.

Escolher entre esses caminhos é decisão de arquitetura com consequência de custo, e merece texto próprio — é o assunto do post sobre como conectar a IA aos dados da empresa.

O que muda para uma PME

Sendo honesto: hoje, quase nada — e é bom saber disso antes de investir.

MCP é infraestrutura. Ele passa a importar quando você quer que a IA responda a partir dos seus dados em vez da memória dela. Três situações em que isso deixa de ser teoria:

• Você já cola relatório no chat toda semana. Isso é um servidor MCP querendo existir — e enquanto não existe, é dado saindo da empresa por copiar e colar.
• Você usa uma ferramenta que já oferece servidor MCP (repositório de código, gestor de tarefas, CRM). Aí o custo de ligar é baixo e o ganho é imediato.
• Você está avaliando agentes de IA. Aí MCP não é opcional: é como o agente ganha mão para agir. O conceito de agente está em o que são agentes de IA — MCP é o encanamento por baixo dele, não uma alternativa a ele.

E se nenhuma das três se aplica, a resposta correta é esperar. Padrão aberto tem a vantagem de continuar existindo quando você precisar.

O risco que vem junto

Dar ao modelo o direito de executar ações reais em sistemas reais cria superfície de ataque nova. E ela é diferente das que a área de segurança já conhece.

Dois pontos, em resumo, porque cada um merece tratamento próprio:

• Prompt injection com ferramenta na mão. Suponha que um conteúdo lido pelo modelo contenha instrução maliciosa. Se o modelo tem uma ferramenta que escreve ou apaga, a instrução vira ação. O caso extremo já está documentado em ataques agênticos, incluindo abuso de ferramenta com escalada de privilégio.
• Servidor de terceiro é dependência. Instalar um servidor MCP de origem desconhecida é o mesmo tipo de decisão que instalar uma biblioteca de origem desconhecida — e o blog tem o enquadramento certo para isso em cadeia de suprimentos de software.

A regra prática é conservadora e funciona: permissão mínima, origem conhecida, e registro de tudo que foi executado. Servidor que só precisa ler não deve receber credencial que escreve.

O ponto que fica

O MCP resolveu bem o problema que se propôs a resolver: integração deixou de ser N × M. E, como toda boa solução de integração, criou um problema novo no lugar.

Agora existe uma porta padronizada para dentro dos seus sistemas. A decisão de quem passa por ela é sua.

Padrão aberto com governança neutra e dezenas de milhares de implementações é, na prática, uma escolha já feita pela indústria. Vale aprender agora, mesmo que só para saber quando dizer não.