Model Context Protocol
do primeiro handshake à produção

1.1 O problema M×N

Modelos de linguagem, sozinhos, só fazem uma coisa: transformar texto em texto. Para serem úteis no mundo real, precisam acessar dados (seu banco, seus arquivos, seu CRM) e executar ações (criar um ticket, enviar uma mensagem, rodar uma query). Antes do MCP, cada aplicação de IA implementava suas próprias integrações: o time do produto A escrevia um conector para o GitHub, o time do produto B escrevia outro conector para o mesmo GitHub, com outra interface, outros bugs e outra manutenção.

Com M aplicações de IA e N sistemas externos, o mundo precisava de M×N integrações sob medida. O MCP transforma isso em M+N: cada aplicação implementa o protocolo uma vez (como cliente) e cada sistema externo é exposto uma vez (como servidor). Qualquer cliente conversa com qualquer servidor.

Daí vem a analogia mais citada (inclusive em entrevistas): o MCP é o "USB-C das aplicações de IA". Um padrão único de "porta" que permite plugar qualquer ferramenta em qualquer modelo, sem adaptadores sob medida.

1.2 Linha do tempo (o que você precisa saber de contexto)

1.3 Os três papéis: host, cliente e servidor

Todo o MCP se apoia em três papéis. Memorize-os — a confusão entre "host" e "cliente" é um erro clássico de iniciante:

• Host — a aplicação de IA com a qual o usuário interage: Claude Desktop, Claude Code, uma IDE, seu agente customizado. O host contém o modelo (ou o acesso a ele) e coordena tudo.
• Cliente MCP — o componente dentro do host que mantém uma conexão 1:1 com um servidor. Um host com 5 servidores conectados roda 5 clientes.
• Servidor MCP — o programa que expõe capacidades (ferramentas, dados, prompts) por meio do protocolo. Pode rodar local (um processo na sua máquina) ou remoto (um serviço HTTP).

1.4 As primitivas em 60 segundos

Um servidor pode oferecer três tipos de coisa, e um cliente pode oferecer três de volta. Esta tabela é o mapa mental de toda a apostila:

2.1 Duas camadas: dados e transporte

A especificação separa o MCP em duas camadas independentes — e essa separação é uma decisão de design que você deve saber defender:

• Camada de dados: o que é dito. Mensagens JSON-RPC 2.0, ciclo de vida da conexão, primitivas (tools, resources, prompts...), notificações e utilitários.
• Camada de transporte: como as mensagens viajam. Hoje: stdio (processos locais) e Streamable HTTP (servidores remotos). O capítulo 3 é todo sobre isso.

Consequência prática: o mesmo servidor lógico pode ser servido por stdio em desenvolvimento e por HTTP em produção, sem mudar uma linha das suas tools.

2.2 JSON-RPC 2.0 em 5 minutos

Todo o tráfego MCP são três tipos de mensagem JSON-RPC:

JSON-RPC · request e response de uma chamada de tool→ {"jsonrpc": "2.0", "id": 42,
   "method": "tools/call",
   "params": {"name": "buscar_pedido",
              "arguments": {"pedido_id": "BR-1093"}}}

← {"jsonrpc": "2.0", "id": 42,
   "result": {"content": [{"type": "text",
               "text": "Pedido BR-1093: enviado em 10/07"}],
              "isError": false}}

Detalhe que derruba candidatos: erros têm dois níveis. Erros de protocolo (método inexistente, params inválidos) usam o objeto error do JSON-RPC. Erros de execução da tool (API externa caiu, pedido não existe) voltam como result normal com isError: true — assim o modelo vê o erro e pode reagir (tentar de novo, avisar o usuário). A revisão 2025-11-25 reforçou isso: até erros de validação de argumentos devem voltar como erro de execução, para que o modelo se autocorrija.

2.3 O ciclo de vida da conexão

Toda conexão MCP passa por três fases: inicialização → operação → encerramento. A inicialização é um handshake em que cada lado declara o que sabe fazer (capability negotiation):

handshake · o que cada lado declara→ // cliente
{"method": "initialize", "params": {
  "protocolVersion": "2025-11-25",
  "capabilities": {"sampling": {}, "elicitation": {}, "roots": {"listChanged": true}},
  "clientInfo": {"name": "meu-agente", "version": "1.0.0"}}}

← // servidor
{"result": {
  "protocolVersion": "2025-11-25",
  "capabilities": {"tools": {"listChanged": true},
                   "resources": {"subscribe": true}},
  "serverInfo": {"name": "pedidos-mcp", "version": "2.3.1"}}}

Regras de ouro da negociação: (1) nenhum lado pode usar uma capacidade que o outro não declarou; (2) a versão do protocolo é negociada — se o servidor não suporta a versão pedida, responde com a mais nova que suporta e o cliente decide se continua; (3) só depois do notifications/initialized começa a operação normal.

2.4 Tools por dentro

Tools são funções descritas por JSON Schema. O modelo lê nome, descrição e schema — e é só isso que ele vê. Por consequência, a qualidade da descrição é a qualidade da sua tool:

resposta de tools/list · a "vitrine" que o modelo enxerga{"tools": [{
  "name": "buscar_pedido",
  "title": "Buscar pedido",
  "description": "Retorna status, itens e rastreio de um pedido pelo ID (formato BR-XXXX). Use quando o usuário perguntar sobre um pedido específico.",
  "inputSchema": {
    "type": "object",
    "properties": {"pedido_id": {"type": "string", "pattern": "^BR-\\d{4}$"}},
    "required": ["pedido_id"]},
  "annotations": {"readOnlyHint": true, "openWorldHint": false}}]}

• Annotations (readOnlyHint, destructiveHint, idempotentHint...) são dicas para a interface do host — por exemplo, pedir confirmação extra antes de tools destrutivas. São não confiáveis por definição: o host não deve tomar decisões de segurança baseado nelas.
• Desde a revisão 2025-06-18, tools podem declarar outputSchema e devolver structuredContent — JSON validável em vez de só texto. Essencial quando outro software (não só o modelo) consome o resultado.
• O resultado pode conter texto, imagens, áudio e resource links (referências a resources do servidor).

2.5 Resources e prompts por dentro

Resources são dados identificados por URI (file:///..., postgres://..., esquemas customizados). O cliente pode listá-los (resources/list), lê-los (resources/read) e, se o servidor declarar suporte, assinar mudanças (resources/subscribe → o servidor emite notifications/resources/updated). Também existem resource templates — URIs parametrizadas como pedidos://{cliente_id}/historico que descrevem famílias inteiras de dados.

Prompts são templates de mensagens com argumentos, pensados para o usuário invocar explicitamente (a origem dos comandos de barra em várias interfaces). prompts/get devolve mensagens prontas para entrar na conversa.

2.6 Notificações e dinamismo

MCP é um protocolo vivo: servidores podem mudar durante a sessão. Se declarou listChanged, o servidor pode emitir notifications/tools/list_changed e o cliente refaz o tools/list. Isso habilita padrões avançados como tools que aparecem após login ou de acordo com o plano do usuário.

3.1 stdio: o transporte local

No transporte stdio, o cliente lança o servidor como subprocesso e conversa com ele por stdin/stdout: uma mensagem JSON-RPC por linha. É o transporte padrão de servidores locais (acesso a arquivos, git, ferramentas da máquina).

• Vantagens: latência mínima, zero rede, herda as permissões do usuário, simples de depurar.
• Regra crítica: o servidor jamais pode escrever logs no stdout — qualquer print() perdido corrompe o protocolo. Logs vão para stderr ou arquivo. Esse é provavelmente o bug nº 1 de iniciantes em MCP.
• Limite: um processo por cliente; não serve para expor um serviço a muitos usuários.

3.2 Streamable HTTP: o transporte remoto

Introduzido na revisão 2025-03-26, o Streamable HTTP usa um único endpoint (por convenção /mcp) que aceita POST com mensagens JSON-RPC. A resposta pode ser:

• um JSON simples (Content-Type: application/json) para operações rápidas; ou
• um stream SSE (text/event-stream) quando o servidor precisa mandar múltiplas mensagens — progresso, logs, requests de sampling — antes da resposta final.

O servidor também pode aceitar GET no mesmo endpoint para abrir um canal SSE de notificações espontâneas. Sessões são identificadas pelo header Mcp-Session-Id, e clientes devem enviar o header MCP-Protocol-Version nas chamadas subsequentes.

na prática · uma chamada por HTTPPOST /mcp HTTP/1.1
Host: mcp.minhaempresa.com
Authorization: Bearer eyJhbGciOi...
Mcp-Session-Id: 3fa85f64-5717
MCP-Protocol-Version: 2025-11-25
Content-Type: application/json
Accept: application/json, text/event-stream

{"jsonrpc":"2.0","id":7,"method":"tools/call", ...}

3.3 O legado HTTP+SSE (e por que você ainda vai encontrá-lo)

A primeira versão do protocolo (2024-11-05) usava dois endpoints: um SSE permanente (/sse) para servidor→cliente e um POST para cliente→servidor. Esse desenho complicava load balancing, retomada de conexão e infraestrutura serverless — por isso foi substituído pelo Streamable HTTP. Muitos servidores antigos e tutoriais de 2024/2025 ainda usam o modelo antigo; saber identificar e migrar é trabalho real de manutenção que empresas estão pagando para fazer. Formalmente, o HTTP+SSE entrou em estado Deprecated na revisão 2026-07-28, sob a nova política de ciclo de vida do protocolo: toda funcionalidade agora passa por Active → Deprecated → Removed, com no mínimo 12 meses entre depreciação e a remoção mais próxima possível (exceção apenas para emergências de segurança, com piso de 90 dias).

3.4 Como decidir

4.1 Escolhendo o SDK

Existem SDKs oficiais para Python, TypeScript, Java, Kotlin, C#, Go, Ruby, Rust, Swift e PHP. Para o mercado, domine Python (dados, automação, IA) e TypeScript (produtos web, ecossistema npm) — a maioria absoluta das vagas cita um dos dois.

instalação# Python (SDK oficial, servidor de alto nível FastMCP incluído)
uv add "mcp[cli]"        # ou: pip install "mcp[cli]"

# TypeScript
npm install @modelcontextprotocol/sdk zod

4.2 Servidor completo em Python

O exemplo abaixo expõe as três primitivas — uma tool, um resource e um prompt — para um domínio realista (suporte a pedidos):

pedidos_server.pyfrom mcp.server.fastmcp import FastMCP

mcp = FastMCP("pedidos")

# --- TOOL: o modelo decide chamar -------------------------------
@mcp.tool()
def buscar_pedido(pedido_id: str) -> dict:
    """Retorna status, itens e rastreio de um pedido (formato BR-XXXX).
    Use quando o usuário perguntar sobre um pedido específico."""
    pedido = db.get(pedido_id)          # sua lógica real aqui
    if pedido is None:
        raise ValueError(f"Pedido {pedido_id} não encontrado")
    return pedido                        # vira structuredContent

# --- RESOURCE: contexto controlado pela aplicação ---------------
@mcp.resource("pedidos://{cliente_id}/historico")
def historico(cliente_id: str) -> str:
    """Histórico de pedidos de um cliente, em texto."""
    return db.historico_txt(cliente_id)

# --- PROMPT: template invocado pelo usuário ---------------------
@mcp.prompt()
def responder_reclamacao(pedido_id: str) -> str:
    return (f"Analise o pedido {pedido_id}, identifique o problema "
            "e redija uma resposta empática com próximos passos.")

if __name__ == "__main__":
    mcp.run()   # transporte stdio por padrão

Repare no que o framework faz por você: gera o inputSchema a partir dos type hints, usa a docstring como descrição, converte exceções em resultados com isError e serializa o retorno. Seu trabalho intelectual está nos nomes, tipos e descrições.

4.3 O mesmo servidor em TypeScript

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

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

server.registerTool("buscar_pedido", {
  title: "Buscar pedido",
  description: "Retorna status, itens e rastreio de um pedido (BR-XXXX).",
  inputSchema: { pedido_id: z.string().regex(/^BR-\d{4}$/) }
}, async ({ pedido_id }) => {
  const pedido = await db.get(pedido_id);
  if (!pedido) return { content: [{ type: "text",
      text: `Pedido ${pedido_id} não encontrado` }], isError: true };
  return { content: [{ type: "text", text: JSON.stringify(pedido) }] };
});

await server.connect(new StdioServerTransport());

4.4 Conectando ao Claude Desktop e ao Claude Code

Servidores stdio são declarados na configuração do host, que os lança como subprocesso:

claude_desktop_config.json{
  "mcpServers": {
    "pedidos": {
      "command": "uv",
      "args": ["run", "--with", "mcp", "python", "/caminho/pedidos_server.py"],
      "env": { "DB_URL": "postgres://..." }
    }
  }
}

Claude Code · CLI# local (stdio)
claude mcp add pedidos -- uv run python /caminho/pedidos_server.py

# remoto (Streamable HTTP)
claude mcp add --transport http pedidos https://mcp.minhaempresa.com/mcp

4.5 Depurando com o MCP Inspector

O Inspector é a ferramenta oficial de teste: uma interface web que se conecta ao seu servidor, mostra o handshake, lista primitivas e permite chamar tools manualmente com argumentos arbitrários — sem precisar de um modelo no meio.

terminalnpx @modelcontextprotocol/inspector uv run python pedidos_server.py

Fluxo de trabalho profissional: Inspector primeiro (o contrato está certo?), host depois (o modelo entende e escolhe bem as tools?). Metade dos "bugs de MCP" são, na verdade, descrições ruins que confundem o modelo — e isso você só enxerga testando com o host real.

5.1 O ecossistema de hosts

Você raramente precisará construir um host do zero: Claude Desktop e Claude.ai (conectores), Claude Code, VS Code/Copilot, Cursor, Windsurf, JetBrains, agentes via API (Claude, OpenAI e outros aceitam servidores MCP diretamente) e dezenas de frameworks de agentes falam MCP. A habilidade de mercado aqui é saber configurar, restringir e auditar servidores nesses hosts — especialmente em ambiente corporativo (quem pode instalar o quê, com quais credenciais, com que escopo).

5.2 Escrevendo um cliente do zero

Escrever um cliente mínimo é o melhor exercício para fixar o protocolo — e é a base de qualquer agente customizado:

cliente mínimo em Pythonimport asyncio
from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client

async def main():
    params = StdioServerParameters(
        command="uv", args=["run", "python", "pedidos_server.py"])
    async with stdio_client(params) as (read, write):
        async with ClientSession(read, write) as session:
            await session.initialize()            # handshake do cap. 2
            tools = await session.list_tools()
            r = await session.call_tool("buscar_pedido",
                                        {"pedido_id": "BR-1093"})
            print(r.content)

asyncio.run(main())

5.3 O loop agêntico: MCP + LLM

Um agente é um loop: o modelo recebe as tools (vindas do tools/list de todos os servidores conectados), decide chamar, o cliente executa via tools/call, devolve o resultado ao modelo, e repete até a resposta final. Este é o coração de qualquer produto agêntico:

esqueleto do loop (Claude API + MCP)tools_mcp = await session.list_tools()          # 1. descoberta
schema = [converter(t) for t in tools_mcp.tools] # 2. formato da API do modelo

while True:
    resp = client.messages.create(model="claude-sonnet-4-6",
        max_tokens=2048, tools=schema, messages=msgs)
    if resp.stop_reason != "tool_use": break    # 5. resposta final
    msgs.append({"role": "assistant", "content": resp.content})
    results = []
    for b in resp.content:
        if b.type == "tool_use":                # 3. modelo decidiu
            out = await session.call_tool(b.name, b.input)  # 4. MCP executa
            results.append({"type": "tool_result",
                "tool_use_id": b.id, "content": out.content[0].text})
    msgs.append({"role": "user", "content": results})

Além disso, a API da Anthropic aceita o parâmetro mcp_servers apontando para servidores remotos — o próprio backend faz a ponte, e seu código não precisa nem do loop de conversão. Conheça as duas formas: o loop manual (controle total, qualquer provedor) e o conector gerenciado (menos código).

5.4 Orquestrando múltiplos servidores

Problemas reais de quem conecta 5+ servidores num agente — e que separam pleno de sênior:

• Colisão de nomes: dois servidores com tool search. Solução: prefixar por servidor (github__search).
• Inflação de contexto: 80 tools no prompt degradam a escolha do modelo e custam tokens. Soluções: filtrar tools por tarefa, carregar sob demanda (descoberta dinâmica), agrupar servidores por "modo" do agente.
• Resultados gigantes: paginação e sumarização antes de devolver ao modelo.
• Confiabilidade: timeout por tool, limite de iterações do loop, orçamento de custo por execução, trilha de auditoria de cada chamada.

6.1 Sampling: o servidor usa o LLM do host

Com sampling (sampling/createMessage), um servidor pede que o cliente rode uma geração no modelo do host. O servidor ganha inteligência sem ter chave de API própria, sem escolher modelo e sem pagar a conta — e o usuário mantém controle (o host pode exigir aprovação e revisar o prompt).

servidor pedindo uma geração ao host@mcp.tool()
async def triagem_reclamacao(texto: str, ctx: Context) -> str:
    """Classifica a reclamação e sugere prioridade."""
    r = await ctx.session.create_message(          # sampling!
        messages=[{"role": "user", "content":
            {"type": "text", "text": f"Classifique em baixa/média/alta e justifique: {texto}"}}],
        max_tokens=200)
    return r.content.text

Casos de uso legítimos: sumarizar dados grandes antes de devolver à conversa, extrair campos de texto livre, decidir ramificações dentro de uma tool. Cuidados: latência (é um round-trip até o modelo), aprovação humana no host, e nunca depender de um modelo específico — você não escolhe qual roda, apenas envia preferências (modelPreferences com hints e prioridades de custo/velocidade/inteligência).

Desde a revisão 2025-11-25, o sampling aceita os parâmetros tools e toolChoice: o servidor pode rodar um loop agêntico próprio usando o modelo (e as chaves) do host — o modelo pede tool uses, o servidor executa e devolve os resultados na mensagem seguinte. Isso abre a porta para servidores que são, eles mesmos, mini-agentes. Nota de futuro: no release candidate 2026-07-28 o sampling clássico (iniciado pelo servidor) entra em deprecated, substituído pelo padrão MRTR descrito na seção 6.6 — mas segue válido e suportado por pelo menos 12 meses.

6.2 Elicitation: o servidor pergunta ao usuário

Introduzida na revisão 2025-06-18, a elicitation (elicitation/create) permite ao servidor pedir dados estruturados ao usuário no meio de uma operação — com um JSON Schema simples (campos planos) que o host transforma em formulário. O usuário pode aceitar, recusar ou cancelar, e a spec proíbe usar elicitation para pedir segredos (senhas, tokens): credenciais pertencem ao fluxo de autenticação, não a formulários.

A revisão 2025-11-25 resolveu exatamente essa lacuna com o modo URL (mode: "url"): em vez de um formulário, o servidor envia uma URL e o usuário completa o fluxo sensível no navegador — OAuth com terceiros, cadastro de API key, pagamento. O cliente nunca vê as credenciais; o servidor recebe os tokens diretamente. Regras de segurança do host: exibir a URL completa antes do consentimento, nunca pré-buscar a página, abrir só no navegador do sistema (nunca em webview embutida) e destacar o domínio contra spoofing. É o mecanismo padrão para servidores que precisam de autorização junto a outros serviços em nome do usuário — sem token passthrough.

confirmação estruturada antes de agirresult = await ctx.elicit(
    message="Confirme o reembolso do pedido BR-1093",
    schema={"type": "object", "properties": {
        "valor": {"type": "number", "maximum": 500},
        "motivo": {"type": "string", "enum": ["defeito", "atraso", "outro"]}},
        "required": ["valor", "motivo"]})
if result.action != "accept": return "Reembolso cancelado pelo usuário."

6.3 Roots: delimitando o território

Roots são URIs (tipicamente file://) que o cliente informa ao servidor como fronteiras de operação — "trabalhe dentro destas pastas". São orientação, não sandbox: a aplicação host ainda precisa impor os limites de verdade (permissões do SO, validação de caminhos). Servidores bem-comportados consultam os roots (roots/list) e reagem à notificação de mudança. (No RC 2026-07-28, roots — assim como sampling e logging clássicos — entra em deprecated, com a janela mínima de 12 meses; hosts tendem a mover essa função para configuração da aplicação.)

6.4 Utilitários que separam protótipo de produto

6.5 Padrões de projeto avançados

• Servidor adaptativo: tools mudam conforme estado (pós-login, plano do usuário, fase do fluxo) usando listChanged. Reduz drasticamente o contexto do modelo.
• Workflow como tool: em vez de expor 12 tools cruas da sua API, exponha 3 tools de intenção ("preparar_relatorio_mensal") que orquestram várias chamadas internamente. Menos passos de modelo = mais confiabilidade e menos custo.
• Resource + tool em par: resource para o dado bruto (contexto), tool para a ação sobre ele — deixando claro ao host o que é leitura e o que é efeito colateral.
• Composição/proxy: um servidor MCP que é, ele próprio, cliente de outros servidores — agregando, filtrando e aplicando políticas (um "gateway MCP"). É o padrão por trás de plataformas corporativas de conectores.

6.6 O que a revisão 2026-07-28 muda neste capítulo

A maior revisão do protocolo desde o lançamento (final prevista para 28/07/2026) reorganiza justamente as interações avançadas deste capítulo. Três peças para acompanhar:

• MRTR — Multi Round-Trip Requests: num protocolo stateless, o servidor não pode mais "ligar de volta" para o cliente a qualquer momento. Quando precisa de algo no meio de uma chamada (uma pergunta ao usuário, uma geração do modelo), ele responde com um InputRequiredResult contendo os pedidos (inputRequests) e um estado opaco (requestState); o cliente coleta as respostas e reemite a chamada original com elas. Além disso, pedidos iniciados pelo servidor só podem ocorrer enquanto ele processa uma requisição do cliente — o usuário nunca é interrompido "do nada", e toda elicitation rastreia de volta a algo que ele (ou seu agente) iniciou.
• Framework de extensões: extensões ganham processo formal — identificadas por IDs em reverse-DNS, negociadas num mapa extensions das capacidades, versionadas de forma independente da spec. Novas capacidades nascem como extensão e só migram para o núcleo (se um dia migrarem) depois de amadurecer.
• Duas extensões oficiais de estreia: MCP Apps — servidores entregam interfaces HTML interativas que o host renderiza em iframe sandboxed; os templates de UI são declarados antecipadamente (o host pode pré-buscar, cachear e revisar), e toda ação da UI volta pelo mesmo JSON-RPC, passando pelo mesmo caminho de auditoria e consentimento de uma tool. E Tasks — o experimento de 2025-11-25 foi redesenhado como extensão para o modelo stateless: o servidor decide responder um tools/call com um identificador de task, e o cliente dirige o ciclo com tasks/get, tasks/update e tasks/cancel (o tasks/list foi removido por não ter escopo seguro sem sessões). Quem implementou as Tasks experimentais precisará migrar.

7.1 Autorização OAuth 2.1 em servidores remotos

Servidores Streamable HTTP autenticam com OAuth 2.1. Desde a revisão 2025-06-18, o servidor MCP é formalmente um resource server — ele valida tokens, mas quem os emite é um authorization server (o seu IdP: Auth0, Keycloak, Okta, etc.). Peças do quebra-cabeça:

• Descoberta: o servidor publica /.well-known/oauth-protected-resource apontando para o authorization server; o cliente descobre tudo sozinho e inicia o fluxo.
• PKCE obrigatório e registro de cliente sem cadastro manual. O mecanismo original era o Dynamic Client Registration (DCR), que obrigava cada authorization server a manter um banco de clientes; desde a revisão 2025-11-25, o mecanismo recomendado é o CIMD (Client ID Metadata Documents): o próprio client ID é uma URL HTTPS onde o cliente publica seus metadados (nome, redirect URIs, chaves), que o servidor busca e cacheia durante a autorização — sem pré-cadastro em milhares de servidores.
• Descoberta e consentimento modernos: suporte a OpenID Connect Discovery 1.0 além do Protected Resource Metadata, e consentimento incremental de escopos via WWW-Authenticate — o servidor pede permissões adicionais só quando a operação exige, em vez de tudo no primeiro login (privilégio mínimo na prática).
• Resource Indicators (RFC 8707): o token é emitido para aquele servidor específico (claim de audiência). Impede que um token roubado de um servidor seja aceito em outro.
• Proibição de token passthrough: o servidor nunca repassa ao upstream o token que recebeu do cliente, nem aceita tokens emitidos para outra audiência. Se precisa falar com uma API externa, troca por credencial própria (ex.: token exchange).

fluxo resumido1. Cliente → POST /mcp            → 401 + WWW-Authenticate (onde me autentico?)
2. Cliente → /.well-known/...     → descobre o authorization server
3. Cliente → fluxo OAuth (PKCE)   → usuário consente no navegador
4. Cliente → POST /mcp + Bearer   → servidor valida (assinatura, audiência, escopo)
5. Servidor executa a tool COM AS PERMISSÕES DAQUELE usuário

O item 5 é a alma do enterprise: identidade propagada. A tool buscar_pedido deve enxergar apenas os pedidos que aquele usuário pode ver. Autorização por usuário, não por servidor.

Duas novidades de 2025/2026 completam o quadro corporativo. A extensão Enterprise-Managed Authorization ficou estável em 2026: a organização gerencia centralmente a autorização dos servidores MCP e o usuário final acessa todos os conectores aprovados com um único login (SSO de verdade para agentes). E o release candidate 2026-07-28 endurece o alinhamento com OAuth/OIDC como são usados na prática — por exemplo, clientes agora devem validar o parâmetro iss nas respostas de autorização (RFC 9207), fechando ataques de mix-up entre authorization servers.

7.2 O mapa de ameaças

7.3 Deploy e operação

• Empacotamento: servidores stdio distribuídos via uvx/npx ou binário; servidores HTTP em containers. Streamable HTTP foi desenhado para funcionar até em serverless (respostas JSON simples quando não há streaming).
• Estado e escala: na spec estável corrente (2025-11-25), sessões via Mcp-Session-Id exigem afinidade de sessão ou armazenamento compartilhado (ex.: Redis) atrás do load balancer — ou modo stateless quando o servidor dispensa sessão. Com a revisão 2026-07-28, a sessão de protocolo desaparece e um round-robin comum basta; ao projetar hoje, minimize a dependência de sessão para que a migração seja trivial.
• Observabilidade: logue cada tools/call com usuário, argumentos (com redação de dados sensíveis), duração, resultado/erro; exporte métricas (latência por tool, taxa de isError, tokens consumidos por resultados). Tracing distribuído (OpenTelemetry) ligando conversa → chamada → sistemas downstream é o padrão que empresas maduras pedem.
• Testes: unitários da lógica; contrato via Inspector/cliente de teste; e evals com modelo real — um conjunto de tarefas em linguagem natural que devem resultar nas chamadas corretas. Tool design se testa com evals, não só com asserts.
• Versionamento: a spec versiona por data e o servidor versiona seu pacote (semver). Mudar schema de tool é breaking change para o modelo também — descreva mudanças e mantenha compatibilidade quando puder.

7.4 Distribuição: o MCP Registry

O Registry oficial (registry.modelcontextprotocol.io) é um catálogo aberto com API padronizada: servidores publicam metadados (nome com namespace, pacotes, transporte) e clientes/marketplaces consomem o índice — inclusive sub-registries corporativos com curadoria interna (só servidores aprovados pelo time de segurança). Publicar seu servidor no registry, com metadados corretos, é o "último quilômetro" da distribuição — e mais um item verificável de portfólio. Para dimensionar o ecossistema em 2026: registries independentes indexam dezenas de milhares de servidores e os SDKs oficiais somam algo na casa de dezenas de milhões de downloads mensais; no roadmap, os MCP Server Cards propõem metadados em URLs .well-known para que navegadores, crawlers e registries descubram capacidades de um servidor sem precisar conectar.

8.1 Onde o MCP aparece nas vagas

Você raramente verá o cargo "Engenheiro de MCP". O protocolo aparece como requisito ou diferencial dentro destes perfis:

Termos para configurar nos alertas de vaga: MCP, Model Context Protocol, tool use, function calling, AI agents, agentic, conectores/integrações de IA, LLM integrations.

8.2 Como colocar no currículo e no LinkedIn

• Fraco: "Conhecimento em MCP." Forte: "Projetei e operei servidor MCP (Streamable HTTP + OAuth 2.1) expondo o ERP a 300 usuários via Claude; 14 tools de intenção, p95 de 800 ms, zero incidentes de segurança em 6 meses."
• Use os verbos do domínio: projetei tools, negociei capacidades, implementei elicitation, publiquei no MCP Registry, escrevi threat model. Recrutadores técnicos filtram por vocabulário.
• Cada projeto de portfólio (caps. 4, 5 e 7) vira: repositório com README forte + post curto explicando decisões + demo em vídeo de 60s. Três projetos assim contam uma progressão: local → agente → produção segura.
• Mostre que acompanha o padrão: desde a doação à Agentic AI Foundation, o MCP evolui por SEPs e Working Groups públicos. Citar uma SEP relevante para a vaga (ex.: a de extensões ou a de Tasks) ou ter comentado uma discussão no repositório da spec é um sinal raro e forte de senioridade.

8.3 Banco de perguntas de entrevista

Conceituais — responda em 2–3 frases cada, em voz alta, cronometrado:

1. O que o MCP resolve que function calling puro não resolve? (padronização entre hosts: a tool escrita uma vez serve a qualquer cliente; ciclo de vida, descoberta, resources/prompts e capacidades bidirecionais que function calling não define)
2. Host × cliente × servidor — quem é quem?
3. Tool × resource × prompt e o modelo de controle (modelo × aplicação × usuário).
4. stdio × Streamable HTTP: quando cada um, e o que aconteceu com o HTTP+SSE original?
5. Erro de protocolo × erro de execução (isError): por que a distinção existe?
6. O que é sampling e por que um servidor o usaria em vez de ter chave de API própria?
7. Por que token passthrough é proibido? O que é audiência de token?
8. Descreva prompt injection indireto com um exemplo envolvendo uma tool de leitura de e-mail.
9. O que muda com o núcleo stateless da revisão 2026-07-28, e por que isso importa para quem opera atrás de load balancer? (fim do initialize e da sessão de protocolo → round-robin simples, sem sticky sessions; interações servidor→cliente viram MRTR)
10. Quando usar Tasks em vez de uma chamada síncrona com notificações de progresso? (quando a operação pode exceder o tempo de vida razoável da requisição/conexão: o cliente recebe um identificador e consulta depois)
11. DCR × CIMD: qual problema o CIMD resolve no registro de clientes OAuth?
12. O que é o modo URL de elicitation e que problema de credenciais ele elimina?

De design — pratique desenhando de verdade:

1. Desenhe o servidor MCP do nosso SaaS de gestão de projetos. Quais tools, quais resources, o que exige elicitation?
2. Nosso agente ficou lento com 70 tools de 9 servidores. Plano de ataque?
3. Como você levaria um servidor stdio interno para 5 mil usuários com SSO corporativo?

De código (teste técnico típico): implementar um servidor com 2–3 tools sobre uma API fake, com validação, erros bem reportados e um teste; ou depurar um servidor com bugs plantados (print no stdout, schema errado, descrição enganosa).

8.4 Plano de estudo de 6 semanas

Fontes primárias para continuar

• modelcontextprotocol.io — especificação corrente, tutoriais e SDKs (leia a spec da versão que você usa; ela é curta).
• github.com/modelcontextprotocol — SDKs, Inspector, servidores de referência e o registry.
• Documentação de MCP dos hosts que você usa (Claude Docs para Claude Desktop/Code e API).
• Changelogs entre revisões da spec — ler o diff entre versões é o jeito mais rápido de se manter atualizado (e rende boas respostas em entrevista).