MCP: o protocolo que se tornou o USB da inteligência artificial

Antes do USB, cada fabricante tinha seu próprio conector. Impressoras, câmeras, teclados, cada dispositivo exigia um cabo diferente e um driver específico. Funcionava, mas era um pesadelo de compatibilidade.

O mundo das ferramentas de IA vivia o mesmo problema até meados de 2025. Cada assistente (Claude, ChatGPT, Gemini, Copilot) tinha sua própria forma de conectar ferramentas externas. Se você criava um plugin para o Claude, não funcionava no Cursor. Se fazia uma integração com o Copilot, não rodava no Windsurf.

Aí veio o MCP (Model Context Protocol) e mudou tudo.

De 100 mil para 8 milhões de downloads em 5 meses

O MCP foi lançado pela Anthropic como um protocolo aberto para conectar modelos de linguagem a ferramentas externas. A ideia era simples: definir um contrato padrão para que qualquer ferramenta pudesse ser usada por qualquer agente de IA, sem integração customizada.

Em novembro de 2025, tinha 100 mil downloads no npm. Em abril de 2026, ultrapassou 8 milhões. Não porque a Anthropic forçou a adoção, mas porque o problema que ele resolve é real e a solução é elegante.

Hoje, todos os principais agentes de IA suportam MCP: Claude Desktop, Claude Code, Cursor, Windsurf, Cline, OpenCode. O Google adotou para o Gemini. A Microsoft está integrando no Copilot. E o número de servidores MCP disponíveis já passa de 10.000.

Como funciona (em termos técnicos)

O MCP define três primitivas:

Tools (ferramentas)

Funções que o agente pode chamar. Cada tool tem um nome, uma descrição em linguagem natural (que o modelo usa para decidir quando chamar) e um schema JSON dos parâmetros.

{
  "name": "search_code",
  "description": "Search for code patterns across the repository",
  "inputSchema": {
    "type": "object",
    "properties": {
      "query": { "type": "string" },
      "language": { "type": "string" }
    },
    "required": ["query"]
  }
}

O modelo vê essa descrição e decide autonomamente quando chamar a ferramenta, quais parâmetros passar e como interpretar o resultado. Não há hardcoding.

Resources (recursos)

Dados que o agente pode ler. Diferente de tools, resources são passivos — o agente puxa a informação quando precisa. Exemplos: conteúdo de um arquivo, resultado de uma query, estado de um sistema.

Prompts (templates)

Templates pré-definidos que guiam o agente em tarefas específicas. Um servidor MCP pode oferecer um prompt “review-code” que instrui o agente sobre como fazer code review seguindo as convenções do time.

Transporte

O MCP suporta dois modos de transporte:

stdio: o servidor roda como um processo filho do cliente. Comunicação via stdin/stdout. Ideal para ferramentas locais (leitura de arquivos, git, terminal).

HTTP com SSE (Server-Sent Events): o servidor roda remotamente. O cliente faz requests HTTP e recebe eventos via SSE. Ideal para serviços na nuvem.

A escolha do transporte é transparente para o modelo. Ele chama a mesma tool da mesma forma, independente de ela rodar localmente ou em um servidor remoto.

Por que funcionou (quando outros falharam)

Não é a primeira tentativa de padronizar ferramentas para IA. O ChatGPT teve plugins. O LangChain tem tools. O AutoGPT teve integração com APIs. Por que o MCP vingou?

1. Simplicidade radical

O spec inteiro cabe em poucas páginas. Um servidor MCP básico pode ser implementado em 50 linhas de código. Isso baixou a barreira de entrada drasticamente. Qualquer desenvolvedor consegue criar um servidor MCP em uma tarde.

2. Protocolo, não plataforma

O MCP não exige que você use um framework específico, uma linguagem específica ou um serviço específico. É um protocolo — um contrato de comunicação. Você implementa do seu jeito.

3. O efeito rede

Quanto mais ferramentas suportam MCP, mais agentes adotam. Quanto mais agentes adotam, mais ferramentas suportam. Esse loop virtuoso acelerou a adoção após a massa crítica inicial.

4. O timing certo

O MCP chegou no momento exato em que agentes de IA estavam evoluindo de “chatbots” para “agentes com ferramentas”. A demanda por um protocolo padrão era real e urgente.

O ecossistema que emergiu

O MCP criou um ecossistema que não existia antes. Alguns exemplos:

Ferramentas de código: GitNexus (grafos de conhecimento), Serena (análise semântica), Context7 (documentação de bibliotecas). Cada uma resolve uma dimensão do problema de entender código, e todas funcionam com qualquer agente MCP.

Memória e contexto: MCP Context Hub (memória persistente + otimização de contexto). Resolve o problema de agentes esquecendo tudo entre sessões.

Integração com serviços: servidores MCP para GitHub, Jira, Slack, bancos de dados, APIs REST. O agente pode consultar um ticket no Jira, criar um branch, escrever código, abrir um PR e postar no Slack, tudo sem sair da conversa.

Automação de infraestrutura: servidores MCP para Docker, Kubernetes, AWS. O agente pode consultar logs, escalar serviços e investigar incidentes.

O que antes exigia integração customizada para cada combinação de agente + ferramenta agora funciona plug-and-play. Crie um servidor MCP e ele funciona em todos os agentes.

Implicações para arquitetura de software

O MCP está mudando a forma como pensamos ferramentas de desenvolvimento. Antes, cada ferramenta era um aplicativo isolado com sua própria interface. Agora, ferramentas estão se tornando serviços sem interface que expõem capacidades via MCP.

Isso tem duas consequências importantes:

1. A interface é o agente

Se sua ferramenta funciona via MCP, a “interface” é o agente de IA. O usuário não precisa aprender um UI novo. Ele simplesmente descreve o que quer em linguagem natural e o agente chama a ferramenta certa.

2. Composição livre

Ferramentas MCP são composíveis. O agente pode combinar GitNexus (entender a estrutura do código) + Context Hub (buscar decisões arquiteturais) + GitHub MCP (abrir um PR) em uma única tarefa. Essa composição acontece dinamicamente, sem integração pré-configurada.

Isso lembra a filosofia Unix: cada ferramenta faz uma coisa bem e se comunica via um protocolo padrão (pipes no Unix, MCP na era da IA).

Como criar um servidor MCP

O SDK oficial suporta TypeScript e Python. Aqui está um servidor mínimo em TypeScript:

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({ name: "my-tool", version: "1.0.0" });

server.tool(
  "greet",
  "Greet someone by name",
  { name: z.string() },
  async ({ name }) => ({
    content: [{ type: "text", text: `Hello, ${name}!` }]
  })
);

const transport = new StdioServerTransport();
await server.connect(transport);

Isso é tudo. Esse servidor pode ser usado por Claude Code, Cursor, Windsurf ou qualquer outro cliente MCP. A barreira de entrada é intencionalmente baixa.

Detalhes técnicos do protocolo

Para quem quer entender o MCP em profundidade, vale olhar para os detalhes de implementação que fazem o protocolo funcionar na prática.

Ciclo de vida de uma conexão

Quando um cliente MCP (como o Claude Code) se conecta a um servidor, o fluxo segue etapas bem definidas:

Inicialização: o cliente envia uma mensagem initialize com suas capacidades (quais versões do protocolo suporta, quais features implementa)
Negociação: o servidor responde com suas próprias capacidades e a lista de tools, resources e prompts disponíveis
Execução: o cliente pode chamar tools, ler resources e usar prompts conforme necessário
Encerramento: qualquer lado pode encerrar a conexão de forma limpa

Cada mensagem segue o formato JSON-RPC 2.0. Isso significa que o MCP herda um formato maduro e bem testado, com suporte nativo a requests, responses e notificações. Não reinventou a roda.

Schema de validação

Cada tool define seu input schema usando JSON Schema. Isso permite que o cliente valide os parâmetros antes de enviar, e que o modelo entenda exatamente o que cada parâmetro espera. Na prática, schemas bem escritos reduzem drasticamente erros de chamada.

Um exemplo mais completo de tool com validação:

server.tool(
  "search_issues",
  "Search GitHub issues by query and filters",
  {
    query: z.string().describe("Search query text"),
    state: z.enum(["open", "closed", "all"]).default("open"),
    labels: z.array(z.string()).optional().describe("Filter by labels"),
    limit: z.number().min(1).max(100).default(20)
  },
  async ({ query, state, labels, limit }) => {
    const results = await github.searchIssues({ query, state, labels, limit });
    return {
      content: [{
        type: "text",
        text: JSON.stringify(results, null, 2)
      }]
    };
  }
);

O .describe() em cada campo é crucial. É o que o modelo lê para entender o propósito de cada parâmetro. Descrições vagas geram chamadas erradas. Descrições precisas geram chamadas corretas.

Gestão de erros

O MCP define códigos de erro padronizados que permitem ao cliente reagir de forma inteligente. Se uma tool retorna ToolNotFound, o agente sabe que precisa usar outra abordagem. Se retorna RateLimited, sabe que deve esperar. Isso é diferente de simplesmente receber um erro genérico e tentar interpretar a mensagem.

Casos de uso reais que impressionam

Além dos exemplos óbvios (GitHub, Jira, Slack), alguns casos de uso de MCP são particularmente interessantes por mostrarem o potencial do protocolo.

Investigação de incidentes

Imagine um agente que, ao receber um alerta de produção, automaticamente: consulta logs via MCP (servidor Datadog ou CloudWatch), verifica o estado dos pods via MCP (servidor Kubernetes), analisa commits recentes via MCP (servidor GitHub), e correlaciona tudo para sugerir a causa raiz. Cada uma dessas fontes de dados é um servidor MCP independente, mas o agente as combina em uma investigação coerente.

Isso já existe em produção. Times de SRE estão usando essa abordagem para reduzir o tempo de diagnóstico de incidentes de horas para minutos.

Onboarding automatizado

Um novo desenvolvedor entra no time e precisa entender o projeto. Em vez de ler documentação desatualizada, ele conversa com um agente que tem acesso via MCP ao grafo de código (GitNexus), às decisões arquiteturais (Context Hub), à documentação de dependências (Context7) e ao histórico de PRs (GitHub). O agente responde perguntas como “por que usamos filas em vez de chamadas síncronas neste fluxo?” com contexto real, não respostas genéricas.

Pipeline de CI/CD inteligente

Servidores MCP integrados ao pipeline de CI/CD permitem que agentes analisem falhas de build com contexto completo. O agente vê o log de erro, consulta o código que mudou, verifica se o teste que falhou cobre a mudança feita, e sugere (ou aplica) a correção. Em pipelines com muitos testes flaky, isso economiza horas de investigação manual por semana.

MCP vs. alternativas: uma comparação honesta

O MCP não é a única forma de conectar ferramentas a agentes de IA. Vale comparar com as alternativas para entender onde cada abordagem se encaixa.

MCP vs. Function Calling nativo

Modelos como GPT-4 e Claude já suportam function calling nativo. Você define funções no prompt e o modelo as chama. A diferença é que function calling é específico por modelo. Se você define funções para a API da OpenAI, precisa adaptar para a API da Anthropic. O MCP é agnóstico: defina uma vez, funcione em qualquer agente.

Além disso, function calling exige que as definições de função estejam no prompt, consumindo tokens. Com MCP, as definições ficam no servidor e o cliente as descobre dinamicamente.

MCP vs. LangChain Tools

LangChain popularizou o conceito de “tools” para agentes. Mas tools do LangChain são código Python que roda dentro do processo do agente. Isso limita a linguagem, cria dependências e dificulta a reutilização entre projetos.

O MCP separa o servidor (que pode ser em qualquer linguagem) do cliente (o agente). Essa separação é fundamental para um ecossistema aberto. Um servidor MCP em Rust pode ser usado por um agente em Python sem nenhuma adaptação.

MCP vs. OpenAPI/REST direto

Agentes podem chamar APIs REST diretamente. O problema é que APIs REST são projetadas para humanos ou aplicações, não para modelos de linguagem. Um endpoint REST retorna dados brutos que o modelo precisa interpretar. Uma tool MCP retorna dados com descrições semânticas que guiam o modelo.

Além disso, APIs REST não têm o conceito de “descoberta”. O agente precisa saber de antemão quais endpoints existem. Com MCP, o servidor anuncia suas capacidades e o agente descobre dinamicamente o que está disponível.

O que vem a seguir

O MCP ainda está evoluindo. Algumas áreas em desenvolvimento:

Autenticação padronizada: hoje cada servidor implementa auth do seu jeito. Um spec de autenticação padrão está em discussão ativa, com propostas baseadas em OAuth 2.0 e tokens de curta duração.
Streaming de resultados: para ferramentas que retornam dados grandes (logs, resultados de busca), streaming progressivo é essencial. O draft atual propõe streaming via chunks incrementais.
Descoberta de servidores: um registry centralizado onde agentes podem descobrir servidores MCP relevantes automaticamente, similar ao npm para pacotes.
Composição de servidores: a capacidade de um servidor MCP chamar outro servidor MCP, criando cadeias de ferramentas compostas.

Mas o núcleo do protocolo já está estável e adotado. As empresas que estão construindo ferramentas de IA sem suporte a MCP estão, na prática, construindo para um ecossistema isolado. Assim como construir um periférico sem USB em 2010.

O MCP não é a única coisa que importa no ecossistema de IA. Mas é a cola que conecta tudo. E isso é suficiente para mudar o jogo.

Links: