O que é o Model Context Protocol?

O Model Context Protocol (MCP) é um protocolo aberto que padroniza como uma aplicação de IA descobre e usa ferramentas e dados que estão fora dela. Você escreve um servidor MCP uma vez e qualquer cliente compatível passa a consumi-lo, sem conector sob medida. É a resposta ao problema N×M: N aplicações vezes M sistemas dá N×M integrações para manter.

A Anthropic publicou o MCP em 25 de novembro de 2024 e o doou à Agentic AI Foundation, um fundo dirigido da Linux Foundation, em 9 de dezembro de 2025. Em 30 de julho de 2026, data em que este artigo foi verificado, a revisão vigente da spec é a 2026-07-28, publicada dois dias antes¹. Ela reescreveu o núcleo do protocolo, e boa parte do que está escrito por aí sobre MCP descreve a revisão anterior.

Dois fatos estruturais antes de qualquer detalhe. A arquitetura tem três papéis: host, cliente e servidor. E o servidor expõe exatamente três tipos de coisa, tools, resources e prompts, cada um controlado por um ator diferente.

O que atravessa o fio

MCP é JSON-RPC 2.0 sobre um transporte. Quando o modelo decide usar uma ferramenta, o cliente monta uma requisição tools/call com o nome da tool e os argumentos, envia para o servidor e recebe de volta um resultado que entra no contexto da próxima chamada ao modelo.

Essa frase esconde três coisas que costumam confundir.

O modelo não executa nada. Ele devolve o pedido; o cliente decide se envia; o servidor executa. São três processos, e é essa separação que dá onde encaixar permissão, validação de argumento e confirmação humana.

Cada cliente fala com exatamente um servidor. Um host com quatro servidores conectados tem quatro clientes, isolados entre si. Um servidor não vê o que outro recebeu, e nenhum deles vê a conversa inteira — quem faz a agregação é o host.

Servidor não quer dizer serviço remoto. A maior parte dos servidores que você vai instalar em 2026 sobe como subprocesso na sua máquina e conversa por stdin e stdout.

As três primitivas e quem controla cada uma

A parte mais subestimada do desenho do MCP é que as primitivas não são só três formatos de dado. Cada uma tem um dono diferente¹.

Primitiva	Quem dispara	Exemplo
Tools	o modelo	criar_issue, rodar_query
Resources	a aplicação	conteúdo de arquivo, histórico do git
Prompts	o usuário	comando de barra, item de menu

Tools são o que quase todo mundo usa, e é onde mora o risco: é a única primitiva que o modelo aciona sozinho. Resources são dados que o cliente anexa ao contexto por decisão da aplicação, sem o modelo pedir. Prompts são modelos de instrução que o usuário escolhe de propósito.

Se você está avaliando um servidor de terceiro, a pergunta útil não é quantas tools ele tem. É quais delas escrevem em algum lugar.

Os dois transportes, e o que aconteceu com o SSE

A revisão 2026-07-28 define dois transportes padrão¹:

stdio. O cliente sobe o servidor como subprocesso e troca JSON-RPC delimitado por linha pelas streams padrão. É o que roda quando você adiciona um servidor ao arquivo de configuração do seu editor.

Streamable HTTP. Cada mensagem é um POST para um endpoint único. A resposta volta como um objeto JSON ou como um stream SSE ligado àquela requisição específica.

Aqui está o ponto em que mais se erra ao escrever sobre MCP. “SSE” foi o nome de um transporte antigo, de dois endpoints, introduzido na revisão 2024-11-05. Esse transporte está depreciado desde 2025-03-26 e, em 2026-07-28, foi reclassificado como Deprecated no registro formal de features, com remoção possível três meses depois de a política correspondente virar Final¹. O que não morreu foi o SSE em si: o Streamable HTTP continua usando SSE para o stream de resposta. Dizer “o MCP abandonou o SSE” está errado; dizer “o transporte HTTP+SSE de dois endpoints está de saída” está certo.

A mesma revisão removeu a retomada de stream, ou seja, o cabeçalho Last-Event-ID e os IDs de evento SSE. Se a conexão cai no meio de uma chamada, a requisição se perde e o cliente precisa reemitir com um ID novo.

O problema que ele resolve

A aritmética da figura é o argumento inteiro, e vale desconfiar dela um pouco. O protocolo não faz a integração desaparecer: alguém ainda escreve o código que chama a sua API, trata erro dela e decide o que expor. O que muda é que esse código passa a existir uma vez por sistema em vez de uma vez por par.

O ganho aparece a partir do segundo consumidor. Se você tem um agente e uma API, MCP acrescenta um processo, um transporte e um formato de mensagem sem nada em troca. Se você tem três aplicações que precisam do mesmo banco, ele se paga na primeira.

Quem já fala MCP

A pergunta que decide adoção não é técnica. É se existe algo do outro lado.

Em dezembro de 2025, quando o protocolo foi doado à Agentic AI Foundation, os mantenedores relataram 97 milhões de downloads mensais dos SDKs e cerca de 10 mil servidores ativos, com suporte de primeira classe em ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot e Visual Studio Code². A fundação nasceu com Anthropic, OpenAI e Block, e os mantenedores do MCP mantiveram autonomia sobre a direção técnica do projeto.

Esse é o argumento mais forte a favor do MCP e o mais frágil de citar. O número muda todo mês, e “quantos servidores existem” mede bem menos do que parece, pelo motivo que a seção de limites detalha. O que importa aqui é a forma do dado, não a magnitude: o protocolo deixou de pertencer a um fornecedor só, e é isso que torna razoável escrever um servidor em vez de um conector.

MCP não substitui function calling

Essa confusão custa tempo em reunião, e a resposta é curta: são camadas diferentes.

Function calling é o mecanismo dentro da chamada de API do modelo. Você declara ferramentas no corpo da requisição, o modelo devolve uma intenção de uso, seu código executa. Isso é entre você e o provedor do modelo.

MCP é o mecanismo de como a sua aplicação descobre quais ferramentas existem e conversa com quem as executa. As tools que o servidor MCP anuncia viram declarações de function calling na chamada ao modelo. A comparação detalhada está em MCP ou function calling, mas a regra prática cabe em uma linha: MCP resolve distribuição, function calling resolve invocação.

O que mudou em 28 de julho de 2026

A revisão 2026-07-28 é a maior mudança desde o lançamento, e ela invalida boa parte dos tutoriais existentes¹. As alterações que mais afetam quem já tem código rodando:

1. O protocolo virou stateless. O handshake de initialize e notifications/initialized deixou de existir. Cada requisição carrega a própria versão de protocolo e as capacidades do cliente em _meta.
2. Sessões de transporte saíram. O cabeçalho Mcp-Session-Id foi removido do Streamable HTTP. Servidor que precisa de estado entre chamadas agora emite um handle explícito e o recebe como argumento comum de tool.
3. server/discover entrou. É uma RPC obrigatória que devolve versões suportadas, capacidades e identidade do servidor em uma requisição.
4. Sampling, roots e logging foram depreciados. Continuam funcionando, mas o registro de features marca a remoção mais cedo possível para a primeira revisão publicada em 28 de julho de 2027 ou depois.
5. Tasks virou extensão oficial, fora do núcleo, junto com um framework de extensões e a política formal de depreciação, com janela mínima de doze meses.

O efeito prático em agosto de 2026 é um descompasso. Os quatro SDKs de primeira linha (TypeScript, Python, Go e C#) saíram atualizados junto com a spec, e o de Rust está em beta. Mas os servidores instalados na sua máquina e os hosts que você usa ainda falam 2025-11-25 ou algo mais antigo, e vão continuar falando por um bom tempo.

Onde o MCP falha

Quatro limites concretos, todos com evidência.

O catálogo é inflado. Um levantamento de 2025 rastreou seis mercados de servidores MCP durante 14 dias, coletou 17.630 entradas e concluiu que 8.401 correspondiam a projetos válidos — 8.060 servidores e 341 clientes. Mais da metade do que estava listado era placeholder, protótipo abandonado ou duplicata³. Contagem de servidor em marketplace não é medida de maturidade do ecossistema.

A descrição da tool é entrada não confiável. O texto que descreve uma ferramenta entra no contexto do modelo e influencia o que ele decide fazer. Um estudo de 2025 analisou 67.057 servidores em seis registros públicos e encontrou condições generalizadas para sequestro de servidor e manipulação de invocação; a ferramenta de análise dos autores apontou 833 servidores vulneráveis e 18 com descrições suspeitas⁴. Um trabalho anterior já havia mapeado o ciclo de vida de um servidor MCP em quatro fases e catalogado 16 cenários de ameaça correspondentes⁵.

A aprovação humana quase nunca existe. Um estudo de 2026 analisou 1.723 aplicações que consomem servidores MCP, mineradas do GitHub. 90,8% registram log e 77,2% oferecem controle para ligar e desligar servidores, mas só 37,2% colocam uma aprovação bloqueante antes de executar uma tool⁶. Na maioria dos casos, o modelo aciona qualquer ferramenta habilitada sem passar por ninguém.

A spec se mexe rápido. Cinco revisões em vinte meses, e a última removeu o handshake que todo tutorial ensina. Se você depende de MCP em produção, isso é uma linha de manutenção recorrente, não um custo único de integração.

O registro oficial de servidores, em registry.modelcontextprotocol.io, seguia em preview em 30 de julho de 2026, com aviso explícito de que pode haver quebra de compatibilidade e reset de dados antes da disponibilidade geral.

Quanto custa

O custo direto do MCP é contexto. Cada tool que um servidor anuncia vira uma declaração no prompt: nome, descrição e JSON Schema dos argumentos. Pela ordem de grandeza, uma tool modesta ocupa algo entre 100 e 400 tokens, e essa conta se repete em toda chamada ao modelo, não uma vez por sessão.

Três servidores com dez tools cada colocam algo na casa de 3.000 a 12.000 tokens de prefixo antes de o usuário digitar qualquer coisa. Isso é ordem de grandeza, não medição: conte os seus com o endpoint de contagem de tokens do provedor antes de decidir qualquer coisa.

A consequência é que “conectar todos os servidores disponíveis” é uma decisão cara e silenciosa. Ela também degrada a escolha do modelo, que passa a selecionar entre dezenas de ferramentas parecidas.

Por onde começar

1. Use um servidor pronto antes de escrever qualquer coisa. Conecte um servidor de sistema de arquivos ou de banco ao editor que você já usa e observe as chamadas. Meia hora aqui vale mais que qualquer explicação, e a lista de servidores MCP essenciais é um bom ponto de partida.
2. Leia as tools do servidor antes de habilitá-lo. Descrição e schema são o que entra no seu contexto e influencia o modelo. Trate como código de terceiro com permissão de execução, porque é isso que é.
3. Comece por stdio. Servidor local, sem autenticação, sem rede. Autenticação e Streamable HTTP são o problema seguinte, não o primeiro.
4. Fixe a versão de protocolo que você suporta. Com a 2026-07-28 recém publicada e a maior parte do ecossistema em 2025-11-25, escrever código que assume uma revisão sem checar é a fonte de bug mais provável dos próximos meses.
5. Habilite poucas tools. Comece com as de leitura. Acrescente as de escrita uma a uma, e só depois de existir uma aprovação bloqueante no caminho.

O passo 5 é o que separa uma demonstração de um sistema, e é o que os dados mostram que quase ninguém faz.

Footnotes

1. A revisão 2026-07-28 da especificação é a fonte para as primitivas, os dois transportes, o estado de depreciação do HTTP+SSE e as mudanças de protocolo stateless descritas aqui. Verificada em 30 de julho de 2026. ↩ ↩² ↩³ ↩⁴ ↩⁵

2. O anúncio da doação, de 9 de dezembro de 2025, é a origem dos números de downloads mensais de SDK e de servidores ativos citados aqui, e da lista de hosts com suporte de primeira classe. ↩

3. Guo et al. (2025) rastrearam seis mercados por 14 dias, coletaram 17.630 entradas e validaram 8.401 projetos, dos quais 8.060 servidores e 341 clientes. ↩

4. Li et al. (2025) analisaram 67.057 servidores em seis registros públicos e identificaram 833 servidores com vulnerabilidade explorável e 18 com descrição de tool enganosa. ↩

5. Hou et al. (2025) decompuseram o ciclo de vida de um servidor MCP em quatro fases e 16 atividades, e derivaram uma taxonomia com 16 cenários de ameaça por tipo de atacante. ↩

6. Majeed et al. (2026) mineraram 1.723 aplicações consumidoras de MCP no GitHub: 85,2% configuram servidores por arquivo, 81,1% usam um SDK oficial e 37,2% exigem aprovação bloqueante antes de executar uma tool. ↩