O que é MCP (Model Context Protocol) e como ele conecta IA a ferramentas

Você pede ao assistente de IA do seu editor: “veja quais issues abertas no GitHub falam de login e crie uma branch para a mais antiga”. Há dois anos, isso exigiria copiar e colar a lista de issues no chat. Hoje, o assistente consulta o GitHub sozinho, lê as issues, escolhe uma e roda o comando no seu repositório.

O que mudou no meio do caminho tem nome: MCP, sigla de Model Context Protocol. É um padrão aberto, lançado pela Anthropic em novembro de 2024, que define como um aplicativo de IA conversa com ferramentas e fontes de dados externas. A documentação oficial do MCP usa uma comparação que ajuda: ele é como uma porta USB-C para aplicações de IA. Um conector padrão, muitos dispositivos diferentes.

O problema que o MCP veio resolver

Antes do protocolo, cada integração era feita sob medida. Se você tinha 5 aplicativos de IA e queria conectar cada um a 10 serviços (GitHub, Slack, banco de dados, Google Drive…), precisava, no pior caso, de 50 integrações diferentes, cada uma com seu formato.

Com um padrão comum, a conta vira soma em vez de multiplicação: cada serviço implementa um servidor MCP e cada aplicativo implementa um cliente MCP. Qualquer cliente fala com qualquer servidor. É a mesma lógica que fez a web funcionar com HTTP: o navegador não precisa saber nada específico de cada site.

Em resumo, em três linhas:

• o MCP padroniza a conversa entre IA e ferramentas;
• quem tem dados ou ações expõe um servidor;
• quem usa IA conecta esse servidor ao seu aplicativo e o modelo passa a enxergar as ferramentas.

MCP substitui as APIs ou o function calling?

Não substitui nenhum dos dois, e essa confusão é comum. Uma API (a REST do GitHub, por exemplo) continua existindo: o servidor MCP do GitHub é só uma camada que chama essa API e a descreve de um jeito que o modelo entende. O function calling, recurso em que o modelo devolve “quero chamar a função X com estes argumentos”, também continua: é ele que o host usa por baixo para saber qual ferramenta acionar.

O que o MCP acrescenta é o formato comum de descoberta e chamada. Sem ele, você escreveria a definição das funções dentro do código do seu aplicativo, presa àquele aplicativo. Com ele, quem mantém o serviço escreve o servidor uma vez, e qualquer host compatível passa a usá-lo, sem mudar uma linha.

Pense assim: a API é a tomada na parede, o function calling é a mão que decide ligar o aparelho, e o MCP é o padrão do plugue.

As três peças da arquitetura MCP: host, cliente e servidor

A arquitetura tem nomes que confundem no começo porque “cliente” não é o que você imagina.

Se o host está ligado a três servidores (GitHub, arquivos locais e um banco), ele cria três clientes, um para cada. O modelo de linguagem em si não fala MCP: quem fala é o host, que traduz o que o modelo quer fazer em chamadas ao servidor certo.

O que um servidor MCP oferece ao modelo

Um servidor pode expor três tipos de coisa, que a especificação chama de primitivas:

Tools: ações que o modelo pode executar

Funções com nome, descrição e parâmetros. “criar_issue”, “rodar_consulta_sql”, “enviar_mensagem”. O modelo lê a descrição, decide quando usar e preenche os argumentos. É a parte que transforma um chatbot em agente.

Resources: dados para dar contexto

Conteúdos que o host pode ler e entregar ao modelo: o conteúdo de um arquivo, registros de uma tabela, a resposta de uma API. Não executam nada, só informam.

Prompts: modelos de instrução prontos

Textos reutilizáveis que o servidor sugere, como “revise este pull request seguindo o guia de estilo do time”. Aparecem para o usuário escolher, geralmente como comandos de barra.

O caminho inverso também existe. O servidor pode pedir coisas ao host, como solicitar uma resposta do modelo (sampling) ou pedir uma informação extra ao usuário no meio da tarefa (elicitation).

O passo a passo de uma chamada MCP, do pedido à resposta

Voltando ao exemplo do GitHub, o que acontece por baixo é mais ou menos isto:

1. Conexão: ao abrir, o host inicia cada servidor configurado e os dois lados trocam quais versões e recursos suportam.
2. Descoberta: o cliente pede a lista de ferramentas (método tools/list). O servidor responde com nomes, descrições e o formato dos parâmetros em JSON Schema.
3. Decisão: o host passa essas descrições ao modelo junto com sua mensagem. O modelo decide que precisa da ferramenta list_issues.
4. Execução: o cliente envia tools/call com os argumentos. O servidor consulta a API do GitHub e devolve o resultado.
5. Resposta: o resultado volta ao modelo, que pode chamar outra ferramenta (criar a branch) ou responder a você.

Todas essas mensagens usam JSON-RPC 2.0, um formato simples de requisição e resposta. Uma chamada de ferramenta tem esta cara:

{"jsonrpc": "2.0", "id": 7, "method": "tools/call",
 "params": {"name": "list_issues",
            "arguments": {"repo": "time/app", "state": "open"}}}

A página de arquitetura do protocolo detalha cada método e o ciclo de vida da conexão.

Local ou remoto: os dois jeitos de transportar as mensagens

O protocolo define dois transportes principais. No stdio, o host roda o servidor como um processo na sua própria máquina e conversa pela entrada e saída padrão do terminal. É o caso típico de um servidor que lê seus arquivos locais. No Streamable HTTP, o servidor fica na internet, atende muitos clientes ao mesmo tempo e usa autenticação (normalmente OAuth). É o modelo dos conectores oficiais que empresas como GitHub e Notion oferecem.

Para quem está começando, a diferença prática é esta: servidor local tem acesso ao que sua máquina tem acesso; servidor remoto tem acesso ao que a conta autorizada permite.

Onde o MCP aparece no dia a dia de um dev

• Agentes de código que leem issues, abrem pull requests e consultam a documentação da biblioteca na versão certa.
• Assistentes que consultam o banco de desenvolvimento para responder “quantos pedidos falharam ontem?”.
• Integrações com ferramentas de design, que deixam a IA ler um layout e gerar o componente.
• Servidores internos de empresas, que expõem sistemas legados para a IA sem abrir o banco inteiro.

Escrever um servidor simples é mais fácil do que parece: há SDKs oficiais em Python, TypeScript e outras linguagens, e um servidor com uma ferramenta cabe em poucas dezenas de linhas.

Segurança quando a IA ganha ferramentas

Dar ferramentas a um modelo é dar poder de ação a algo que pode ser enganado. Uma página web ou issue maliciosa pode conter instruções escondidas (prompt injection) que levam o agente a chamar uma ferramenta que você não pediu. O tema é discutido no texto sobre por que ler uma página não autoriza um agente a executar uma tarefa.

Na prática: instale servidores só de fontes confiáveis, dê a cada um o menor acesso possível (token só de leitura quando bastar) e mantenha a confirmação manual para ações que alteram ou apagam algo. O MCP padroniza a conexão; a responsabilidade pelo que fica conectado continua sendo sua.

Para experimentar sem risco, instale um servidor oficial de referência, como o de sistema de arquivos, num host que você já usa e observe as chamadas no MCP Inspector. Outros termos do mundo dos agentes, como LLM e prompt, estão no glossário de programação.