O que é MCP (Model Context Protocol)? Guia completo

MCP (Model Context Protocol) é um protocolo aberto, criado pela Anthropic e lançado em código aberto em 25 de novembro de 2024, que padroniza como uma aplicação de IA — um chatbot, um assistente dentro de um IDE, um agente autônomo — se conecta a fontes de dados e ferramentas externas. Em vez de cada assistente precisar de uma integração feita sob medida para cada banco de dados, API ou sistema interno, o MCP define uma interface comum: qualquer aplicação que fala MCP consegue usar qualquer servidor MCP, sem escrever código de integração específico para aquele par.

Por que o MCP existe

Antes do MCP, conectar um modelo de linguagem a uma fonte de dados exigia uma integração própria para cada combinação de assistente e sistema: um conector para o Slack dentro do produto A, outro conector para o mesmo Slack dentro do produto B, e assim por diante. O problema cresce como M×N — M assistentes vezes N sistemas. O MCP substitui essa combinatória por M+N: quem mantém um sistema escreve um único servidor MCP, e quem constrói um assistente escreve um único cliente MCP. A partir daí, qualquer par funciona sem código adicional.

Arquitetura: host, cliente e servidor

A especificação do MCP descreve uma arquitetura de três papéis, e um host pode manter vários clientes ao mesmo tempo, um para cada servidor conectado:

• Host — a aplicação que a pessoa usa diretamente: o Claude Desktop, um IDE como o Cursor, um agente próprio. É o host que decide, dentro das permissões concedidas pelo usuário, quando acionar um servidor.
• Cliente — vive dentro do host e mantém uma conexão individual e isolada com um servidor MCP específico. Cada servidor conectado tem seu próprio cliente, sem compartilhar estado com os demais.
• Servidor — expõe capacidades (dados, ferramentas, templates de prompt) através do protocolo, sem precisar saber qual host ou qual modelo está do outro lado da conexão.

Os três primitivos: tools, resources e prompts

Um servidor MCP anuncia suas capacidades usando três tipos de primitivo, e cada um serve a um propósito diferente:

• Tools (ferramentas) — funções que o modelo pode chamar para executar uma ação: consultar uma API, rodar uma query, escrever um arquivo. O modelo decide quando chamar, dentro do que o host autorizar.
• Resources (recursos) — dados somente leitura que o servidor expõe para dar contexto, como o conteúdo de um arquivo ou o resultado de uma consulta. Ao contrário de uma tool, não executam uma ação.
• Prompts (prompts) — templates de instrução prontos e parametrizáveis que o servidor oferece para tarefas recorrentes. Diferente das tools, costumam ser acionados explicitamente pelo usuário ou pelo host, não pelo modelo sozinho.

Como as mensagens trafegam: JSON-RPC e transportes

Toda comunicação MCP usa o formato JSON-RPC 2.0. A especificação mantém oficialmente dois transportes: stdio, em que o servidor roda como um subprocesso local e troca mensagens pela entrada e saída padrão — sem overhead de rede, ideal para uso local —, e Streamable HTTP, usado para servidores remotos, que envia mensagens por POST/GET e pode transmitir respostas em tempo real via Server-Sent Events. O Streamable HTTP substituiu o transporte HTTP+SSE mais antigo na revisão de 26 de março de 2025.

Um servidor MCP mínimo em Python

O SDK oficial em Python (pacote mcp, com o helper FastMCP) transforma uma função comum em uma tool MCP com um decorador. Os type hints e o docstring viram automaticamente o schema que o servidor anuncia:

from mcp.server.fastmcp import FastMCP

mcp = FastMCP(name="Calculadora")

@mcp.tool()
def somar(a: int, b: int) -> int:
    """Soma dois números inteiros."""
    return a + b

if __name__ == "__main__":
    mcp.run()

Ao rodar esse arquivo, qualquer host MCP que se conecte a ele descobre a tool somar, seu schema de entrada e sua descrição — sem que ninguém do lado do host precise conhecer Python ou ter acesso ao código-fonte.

MCP não é mais só da Anthropic: a Agentic AI Foundation

Em dezembro de 2025 a Anthropic doou o MCP para a Agentic AI Foundation (AAIF), um fundo dirigido sob a Linux Foundation cofundado com OpenAI e Block, com apoio declarado de Google, Microsoft, AWS, Cloudflare e Bloomberg — a mesma estrutura de governança neutra que hoje sustenta projetos como Kubernetes, PyTorch e Node.js. Segundo o anúncio da doação, em pouco mais de um ano o protocolo já somava mais de 97 milhões de downloads mensais dos SDKs e cerca de 10 mil servidores ativos, com suporte nativo em produtos como ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot e Visual Studio Code. Isso muda o cálculo de risco de quem avalia adotar o protocolo: o MCP deixou de depender de uma decisão unilateral de uma única empresa.

MCP vs function calling: qual a diferença

Function calling é um recurso do próprio modelo: você descreve uma função no seu código e a API do LLM decide quando pedir para chamá-la, mas quem executa e mantém essa função continua sendo o seu processo. O MCP resolve um problema anterior a esse: como descobrir, sem código novo, quais funções (tools), dados (resources) e templates (prompts) um sistema externo oferece. Na prática, a maioria dos hosts MCP usa o function calling do modelo por baixo dos panos — o cliente MCP traduz as tools descobertas em definições de função que o modelo já sabe chamar.

Riscos de segurança: o outro lado da flexibilidade

Um servidor MCP pode executar ações reais e dar ao modelo acesso a dados internos, o que torna cada servidor conectado uma superfície de ataque em potencial. Os riscos mais discutidos incluem tool poisoning (uma tool com nome inofensivo, mas com instruções escondidas na descrição que o modelo segue como se fizessem parte do prompt do sistema), o problema do confused deputy (o servidor age com as permissões do host, além do que o usuário pretendia) e a injeção indireta de prompt por meio do conteúdo de um resource. O tema se conecta diretamente ao que já detalhamos em [Prompt Injection: o que é e como se proteger](/artigo/prompt-injection-o-que-e-como-funciona-como-proteger).

Onde o MCP falha e quando não vale a pena

• Para uma integração única, estável e que não muda, escrever a chamada direta à API costuma ser mais simples do que manter um servidor MCP.
• Servidores com tools demais sobrecarregam a janela de contexto do modelo com descrições — veja como isso afeta custo e desempenho em [Tokens e janela de contexto em LLMs](/artigo/tokens-janela-de-contexto-llm).
• Não existe isolamento automático de permissões entre as tools de um mesmo servidor: se o host confia no servidor, confia em tudo o que ele expõe.
• O ecossistema ainda é jovem: nem toda ferramenta corporativa tem um servidor MCP maduro, e boa parte da integração no dia a dia ainda é feita por scripts ad-hoc.

MCP no Bytezine: onde você já viu isso

Se você acompanha o Bytezine, já esbarrou no MCP mais de uma vez sem que o protocolo em si fosse explicado: é a peça que sustenta como [agentes de IA](/artigo/o-que-e-um-agente-de-ia-guia-completo) descobrem e usam ferramentas, é a base da integração descrita em [Como empresas estão usando agentes Claude para automatizar processos](/artigo/claude-agentes-automacao-empresas), e é o protocolo por trás da política que o GitHub criou em [GitHub cria allowlist de servidores MCP para o Copilot](/artigo/github-allowlist-mcp-copilot). Entender o MCP em si fecha essa lacuna.