Codex Technomanticus

O que é MCP e por que importa

Leitura de 9 min

O que é MCP e por que importa

TL;DR

MCP (Model Context Protocol) é o “USB-C para agents de IA”. Antes dele, cada integração entre LLM e sistema externo (banco de dados, filesystem, Jira, Slack) era reinventar a roda — cada cliente (Claude, Cursor, Copilot) tinha seu próprio formato de plugin. MCP, lançado pela Anthropic em novembro de 2024 e adotado em 2025-2026 por OpenAI, Google, Microsoft, é a padronização dessa conexão. Tecnicamente, MCP é uma camada JSON-RPC 2.0 sobre um transporte (stdio local ou HTTP+SSE remoto) que define três primitivos — Tools, Resources, Prompts — e um handshake de descoberta (list_tools, list_resources, list_prompts) que qualquer client pode chamar sem conhecer o server de antemão. Isso é o que transforma N×M integrações custom em N+M conexões padronizadas: o server é escrito uma vez e funciona em qualquer client compatível. Em 2026, se você está construindo aplicação com agents, MCP é infraestrutura básica, como HTTP — a decisão não é “usar ou não”, é “como estruturar os servers”.

A premissa

Antes do MCP:
  Claude  → custom integration → Postgres
  Cursor  → custom integration → Postgres
  Copilot → custom integration → Postgres
  ... cada cliente reimplementando

Depois do MCP:
  Claude  ──┐
  Cursor  ──┼─→ MCP protocol ─→ Postgres MCP server
  Copilot ──┘
  ... uma vez, qualquer cliente

MCP padroniza:

  1. Como clients e servers se conectam (stdio, HTTP+SSE, WebSocket)
  2. O que servers expõem (tools, resources, prompts)
  3. Como clients descobrem capabilities

Por que isso importa

Sem MCP, era N×M problema:

N clientes × M sistemas = N×M integrações custom

Com MCP:

N clientes × M servers = N + M conexões padronizadas

Linha & cair de N×M para N+M é diferença gigante quando N e M crescem.

Stewardship

Quem mantém MCP

  • Lançado: Anthropic (novembro 2024)
  • Spec aberta: github.com/modelcontextprotocol
  • Adotado por: Anthropic (Claude Desktop, Claude Code), OpenAI (ChatGPT, Codex), Google (Gemini), Microsoft (Copilot Studio), Cursor, Windsurf, Cline, Aider, Zed
  • Governance: especificação aberta com RFC process

Os 3 primitivos

MCP define 3 tipos de coisas que servers podem expor:

PrimitivoO que éExemplo
ToolsFunções executáveis (write)query_database, send_email
ResourcesDados leitáveis (read)Arquivos, schemas, documentos
PromptsTemplates parametrizáveis”Explain this code”, “Summarize doc”

Detalhamento em 02 - Os três primitivos — Tools, Resources, Prompts.

Um MCP server mínimo, primitivo a primitivo

A melhor forma de entender os 3 primitivos é ver o esqueleto de um server real — não um trecho isolado, mas o fluxo completo de conexão até o resultado. Imagine um server MCP para uma base de notas (o “Postgres” do exemplo anterior poderia ser este vault). Em pseudo-código (a forma real usa o SDK oficial em Python ou TypeScript, mas a estrutura é idêntica em ambos):

from mcp.server import Server
 
server = Server("notas-mcp")
 
# 1. TOOL — ação que muda estado ou executa algo
@server.tool()
def buscar_nota(termo: str) -> str:
    """Busca notas do vault que contenham o termo."""
    return grep_vault(termo)
 
# 2. RESOURCE — dado que o client pode ler sem "gastar" uma chamada de LLM
@server.resource("nota://{caminho}")
def ler_nota(caminho: str) -> str:
    """Expõe o conteúdo bruto de uma nota como recurso enderecável."""
    return read_file(caminho)
 
# 3. PROMPT — template parametrizável que o usuário invoca explicitamente
@server.prompt()
def resumir_galho(galho: str) -> str:
    """Gera o prompt pronto para resumir um galho inteiro."""
    return f"Resuma todas as notas em {galho} em um parágrafo cada."

Quando um client (Claude Desktop, por exemplo) se conecta a esse server, o fluxo é sempre o mesmo, independente do que o server faz por dentro:

  1. Handshake — client e server trocam capabilities suportadas (versão do protocolo, quais primitivos o server implementa).
  2. Discovery — client chama list_tools, list_resources, list_prompts. O server responde com o schema de cada primitivo (nome, descrição, parâmetros) — é esse schema que o LLM lê para decidir quando e como chamar cada um.
  3. Invocação — quando o LLM decide usar buscar_nota("MCP"), o client envia tools/call com o nome e os argumentos; o server executa e devolve o resultado como parte do contexto da conversa.

O ponto que costuma escapar: o server nunca sabe que é o Claude do outro lado. Ele só implementa o protocolo. Trocar o client por Cursor ou Copilot não exige nenhuma mudança no código do server acima — é exatamente o “escrito uma vez, plugado em qualquer client” que resolve o problema N×M.

sequenceDiagram
    participant C as Client (Claude/Cursor/Copilot)
    participant S as MCP Server (notas-mcp)

    C->>S: initialize (handshake: versão do protocolo, capabilities)
    S-->>C: capabilities suportadas (tools, resources, prompts)

    C->>S: list_tools()
    S-->>C: [{name: "buscar_nota", schema: {...}}]

    C->>S: list_resources()
    S-->>C: [{uri: "nota://...", schema: {...}}]

    Note over C,S: LLM decide chamar buscar_nota("MCP")

    C->>S: tools/call(buscar_nota, {termo: "MCP"})
    S-->>C: resultado (trechos de notas encontradas)

    Note over C: Resultado entra no contexto do LLM

Quando MCP brilha

✅ Compartilhar integração entre múltiplos clients “Quero que Claude E Cursor acessem nosso DB interno”

✅ Distribuir capability entre projetos “Vou expor nossa API interna como MCP server, qualquer dev usa em qualquer ferramenta”

✅ Aproveitar ecossistema “Awesome MCP Servers tem 500+ integrações já feitas — quero plugar Stripe, Linear, GitHub direto”

Quando MCP NÃO é a resposta

❌ App single-user com tools internas — implementação direta com SDK pode ser mais simples ❌ Latência crítica <50ms — overhead do protocol ❌ Tools triviais (calculator, regex) — não vale o setup

O modelo mental

MCP é HTTP, não framework:

  • HTTP padroniza request/response, headers, cookies
  • MCP padroniza tool calls, resource fetching, prompt templates

Você não “usa HTTP” como decisão — você usa porque é o padrão. Mesmo com MCP em 2026.

Diferença para function calling normal

Function callingMCP
Definido ondeNo código do clientNo server (descoberto pelo client)
ReutilizaçãoPor clientCross-client
DiscoveryManualAutomático (list_tools)
LifecycleApp-boundServer-independent
AuthCustomPadronizado

Function calling resolve o problema “modelo chama função no meu código”. MCP resolve “qualquer modelo chama função em qualquer servidor padrão”.

O que diferencia um senior em MCP

Tip

  1. Sabe quando NÃO usar MCP — single-user app com tools custom não precisa
  2. Distingue tools de resources de prompts — usa cada um corretamente
  3. Implementa MCP servers que parecem APIs — descrições claras, schemas precisos
  4. Pratica least privilege — server só expõe o que é necessário
  5. Conhece o stdio vs HTTP+SSE trade-off — local vs remoto
  6. Trata segurança seriamente — MCP é vetor de prompt injection
  7. Versiona MCP servers — semver, breaking changes documentados
  8. Sabe debugar com MCP Inspector
  9. Aproveita Awesome MCP Servers — não reinventa o que existe
  10. Não confunde MCP com plugin proprietary — é spec aberta

Armadilhas comuns

Usar MCP onde function calling basta

MCP faz sentido quando há reutilização entre clients ou servidores compartilhados. Para uma app single-user com tools internas — um chatbot interno com 5 funções fixas — o overhead de setup (servidor separado, configuração no client, JSON-RPC) não traz retorno. A pergunta certa é: “mais de um client vai consumir isso?” Se não, implemente direto com o SDK.

Confundir "MCP" com "plugin proprietary"

MCP é especificação aberta (RFC process em github.com/modelcontextprotocol). Um server MCP escrito hoje funciona com Claude, OpenAI Codex, Cursor e qualquer client que implemente o protocolo. O risco de adotar MCP como “plugin da Anthropic” e depois descobrir que é padrão aberto é inversamente proporcional ao risco de tratar standard aberto como solução vendor-lock. Quem já viveu a era pré-REST de APIs proprietárias vai reconhecer o padrão.

Ignorar a hierarquia de primitivos desde o início

Muitos times adotam MCP implementando “tudo como tool”. Mas Tools, Resources e Prompts têm semânticas distintas com implicações de performance e design. Tratar dados read-only como tool faz o LLM gastar tool-call budget em operações que o client poderia carregar proativamente. Definir a hierarquia certo desde o início evita refatoração dolorosa quando o servidor já tem usuários.

Como explicar em inglês

MCP — Model Context Protocol — is a standardized, open protocol that defines how AI clients (like Claude, Cursor, or Copilot) connect to external capability servers. Before MCP, every integration between an LLM and an external system (databases, APIs, filesystems) required a custom implementation for each client-server pair. MCP reduces this from an N×M problem to N+M by defining a common wire format (JSON-RPC 2.0), a capability model (Tools, Resources, Prompts), and a discovery mechanism (list_tools, list_resources, list_prompts).

The analogy that holds up well is USB-C: before a universal connector, you needed a different cable for every device-peripheral pair. MCP plays the same role in the AI ecosystem — write a server once, plug it into any compliant client. In 2026, with support from Anthropic, OpenAI, Google, and Microsoft, MCP has achieved the critical mass that makes it a genuine infrastructure standard rather than an experiment.

In a technical interview, you might say:

“MCP gives us N+M instead of N×M integrations. A Postgres MCP server written once works in Claude, Cursor, and any future client without modification. It does this by standardizing three things: the transport layer (JSON-RPC over stdio or HTTP+SSE), the capability model (Tools execute, Resources expose data, Prompts templatize workflows), and the discovery protocol (list_tools on connect). In 2026, if you’re building agents for a team, MCP is as foundational as HTTP — you don’t decide whether to use it, you decide how to structure your servers.”

PTEN
Protocolo de contexto de modeloModel Context Protocol
Servidor MCPMCP server
Cliente MCPMCP client
Chamada de funçãoFunction calling
Descoberta de capabilitiesCapability discovery
PrimitivosPrimitives
TransporteTransport
Integração customizadaCustom integration
Adoção inter-vendorCross-vendor adoption
Especificação abertaOpen specification

O que vem a seguir

Entender o que MCP é — e por que importa — é o passo zero. O passo seguinte é saber o que um servidor MCP pode efetivamente expor: quais são os “blocos de construção” que o protocolo oferece para modelar qualquer capability. Sem essa distinção, você vai implementar tudo como tool e perder os benefícios de performance e composição que Resources e Prompts oferecem.

A próxima nota mapeia os três primitivos e deixa claro quando usar cada um, com anti-patterns do mundo real que mostram o custo de escolher errado desde o início.

Veja também

Referências

Visão de gráfico

Backlinks