Diagrama de arquitetura MCP: hosts, clientes, servidores e transportes

Seu agente de código lê o repositório, verifica o build e abre issues no seu rastreador. Um diagrama típico dessa configuração mostra uma única caixa com o rótulo «MCP» entre o modelo e as ferramentas. Então um revisor de segurança pergunta qual processo pode ler seu diretório pessoal, qual token chega ao rastreador e quem aprovou a chamada que criou uma issue. A caixa não tem resposta.

O Model Context Protocol (MCP) tem uma arquitetura precisa, e sua revisão 2026-07-28 mudou parte dela. Este artigo cobre participantes, camadas do protocolo, transportes, recursos, uma chamada de ferramenta, autorização remota e limites de confiança, com um diagrama que você pode copiar.

Hosts, clientes e servidores

Antes do MCP, cada aplicativo de IA precisava de um adaptador próprio para cada ferramenta: cinco aplicativos e vinte ferramentas significavam até 100 integrações. Com o MCP, 25 implementações (um cliente por aplicativo, um servidor por ferramenta) cobrem todas as combinações.

Um host cria um cliente por servidor, e cada cliente fala com exatamente um servidor. O modelo nunca chama um servidor por conta própria: ele pede uma chamada de ferramenta, e o host decide se a executa e qual cliente a envia. Os servidores permanecem isolados: não devem ver a conversa inteira nem uns aos outros.

Duas camadas e o que a 2026-07-28 mudou

A camada de dados é JSON-RPC 2.0: requisições (com um id que nunca é nulo), resultados, erros e notificações de mão única. A camada de transporte move essas mensagens e cuida de enquadramento, cancelamento e autorização.

A especificação 2026-07-28, lançada em 28 de julho de 2026, tornou o MCP sem estado. As revisões anteriores abriam cada conexão com um handshake initialize que fixava a versão e as capacidades, e os servidores HTTP podiam fixar uma sessão com Mcp-Session-Id. Agora cada requisição carrega sua versão de protocolo e as capacidades do cliente em _meta, então ela pode cair em qualquer instância do servidor atrás de um balanceador de carga round-robin simples.

Servidores criados com SDKs antigos ainda esperam o handshake, então clientes das duas eras sondam primeiro e recorrem a initialize. Um cliente que fala apenas 2026-07-28 não consegue usar um servidor somente legado. O changelog lista cada mudança incompatível.

Transportes: stdio e Streamable HTTP

O Streamable HTTP substituiu o transporte HTTP+SSE (um stream GET mais um endpoint POST separado) na 2025-03-26; o HTTP+SSE agora está formalmente obsoleto. Gateways podem rotear e limitar taxa por Mcp-Method e Mcp-Name sem analisar os corpos, e os servidores rejeitam requisições cujos cabeçalhos divergem do corpo. Servidores HTTP devem validar o cabeçalho Origin contra DNS rebinding, e os locais devem se vincular a 127.0.0.1.

Recursos do servidor e do cliente

O modo de formulário da elicitation nunca deve pedir senhas, chaves de API ou tokens; o modo URL envia o usuário a uma página fora do cliente. Sampling, roots e o log do servidor foram descontinuados na 2026-07-28 e só podem ser removidos a partir da primeira revisão lançada em ou depois de 28 de julho de 2027.

Uma chamada de ferramenta, passo a passo

O modelo abre uma issue por meio de um servidor remoto:

1. Opcionalmente, o cliente chama server/discover para obter versões e capacidades.
2. O cliente chama tools/list. O host une as listas de todos os servidores, prefixa os nomes que colidem e as entrega ao modelo.
3. O modelo pede create_issue. O host mostra a chamada, e o usuário a aprova.
4. O cliente envia tools/call, mostrado abaixo.
5. Se o servidor precisa de uma confirmação, ele retorna input_required com uma solicitação de elicitation. O cliente pergunta ao usuário e tenta de novo com a resposta e o requestState opaco do servidor.
6. O resultado chega como complete. Uma falha da ferramenta define isError: true, para que o modelo possa se corrigir.
7. Em um stream subscriptions/listen, notifications/tools/list_changed diz ao cliente para listar as ferramentas de novo.

POST /mcp HTTP/1.1
Host: mcp.tracker.example
Authorization: Bearer eyJhbGciOi...
Content-Type: application/json
Accept: application/json, text/event-stream
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: create_issue

{"jsonrpc": "2.0", "id": 7, "method": "tools/call",
 "params": {"name": "create_issue",
  "arguments": {"title": "Login fails on Safari"},
  "_meta": {"io.modelcontextprotocol/protocolVersion": "2026-07-28",
   "io.modelcontextprotocol/clientInfo": {"name": "my-ide", "version": "1.4.0"},
   "io.modelcontextprotocol/clientCapabilities": {"elicitation": {}}}}}

{"jsonrpc": "2.0", "id": 7, "result": {"resultType": "complete",
 "content": [{"type": "text", "text": "Created issue #482"}], "isError": false}}

Servidores remotos e autorização

Um servidor MCP remoto é um servidor de recursos OAuth; seus tokens vêm de um servidor de autorização operado pelo mesmo fornecedor ou por um provedor de identidade separado. Em uma primeira conexão:

1. O cliente chama sem token e recebe 401, normalmente com um cabeçalho WWW-Authenticate apontando para os metadados do recurso protegido do servidor (RFC 9728).
2. Esse documento, ou /.well-known/oauth-protected-resource como alternativa, nomeia o servidor de autorização, cujos metadados o cliente lê; ele para se o PKCE não for anunciado.
3. O cliente usa um ID de cliente pré-registrado, um Client ID Metadata Document (uma URL HTTPS como ID de cliente) ou o registro dinâmico de clientes, que a 2026-07-28 descontinua.
4. O cliente executa o fluxo de código de autorização com PKCE (S256) e um parâmetro resource que nomeia o servidor MCP (RFC 8707). O usuário faz login e dá consentimento no navegador, e o cliente verifica o iss da resposta (RFC 9207).
5. Toda requisição carrega Authorization: Bearer. Um 403 com insufficient_scope dispara a autorização escalonada (step-up).

O servidor aceita apenas tokens emitidos para ele e nunca os repassa: chamadas a uma API upstream usam um token separado. O diagrama do fluxo OAuth 2.0 explica o PKCE, e a especificação de autorização tem todas as regras, baseadas no rascunho do OAuth 2.1.

Onde ficam os limites de confiança

O transporte stdio não é um sandbox: o guia de segurança de servidores locais do MCP diz que um servidor stdio roda com os privilégios do cliente, e que o isolamento fica por conta do host e de quem opera a máquina. Um handle de estado emitido por um servidor sem estado também não é uma credencial; vincule-o ao usuário autenticado. O diagrama de fluxo de dados para modelagem de ameaças mostra como percorrer esses limites com STRIDE.

O diagrama de arquitetura MCP

Como ler:

• A moldura verde é um domínio de confiança: o host, seus três clientes e os dois servidores stdio rodam como o usuário do SO do desenvolvedor.
• Um cliente por servidor. Os clientes 1 e 2 usam stdin e stdout; o cliente 3 usa Streamable HTTP.
• As arestas cinzas a partir do modelo são chamadas de ferramenta que o host roteia; os servidores nunca alcançam o modelo diretamente.
• O azul cruza a rede com um bearer token. O violeta tracejado é o fluxo OAuth, que só roda quando o cliente não tem um token válido.
• O verde-azulado é o servidor remoto chamando sua API com o próprio token: sem repasse.
• O bloco Markdown resume a revisão 2026-07-28.

Como desenhar diagramas de arquitetura MCP com clareza

• Um cliente por servidor. Uma única caixa «MCP» esconde o que cada servidor pode ver.
• Rotule as arestas com o transporte e a carga útil: stdin e stdout, um POST com bearer token, um fluxo OAuth, nomes de ferramentas de exemplo.
• Desenhe os limites de confiança como molduras: a máquina, o host, cada fornecedor. Marque os servidores em sandbox.
• Dê ao servidor de autorização e às APIs upstream nós próprios, para que as fontes dos tokens e a regra de não repasse fiquem visíveis.
• Informe a revisão do protocolo. Um diagrama da 2026-07-28 não tem handshake nem IDs de sessão.
• Deixe de fora os detalhes internos dos SDKs, as listas completas de ferramentas e a infraestrutura do provedor do modelo.

O diagrama de arquitetura de agentes de IA cobre o loop do agente em torno dessas chamadas.

Monte no Archboard

1. Entre com Google ou GitHub e crie um diagrama.
2. Adicione uma Moldura do pacote Básico para a máquina do desenvolvedor e, dentro dela, um Limite do contêiner do pacote C4 Model para o host.
3. No limite, adicione um Modelo do pacote ML e três nós Componente do pacote C4 Model para os clientes, com a tecnologia stdio, stdio e Streamable HTTP.
4. Adicione dois nós Contêiner do pacote C4 Model para os servidores locais, conectados com arestas «stdin / stdout», e uma Pessoa do mesmo pacote conectada ao modelo.
5. Fora da moldura, adicione um Limite do sistema do pacote C4 Model contendo um Contêiner para o servidor remoto, um Sistema externo para a API dele e um Provedor de identidade do pacote Segurança, e então desenhe as arestas do bearer token, do OAuth tracejado e de «own token».
6. Adicione um bloco Markdown do pacote Básico com os fatos do protocolo, e notas de Texto do Básico para os limites.

Nenhuma ferramenta gratuita lê arquivos de configuração de clientes MCP, então desenhe os servidores você mesmo ou cole um fluxograma Mermaid, como o da especificação MCP, na ferramenta de Mermaid para diagrama editável.

No momento da escrita (novembro de 2026), o próprio Archboard é um servidor MCP remoto em https://getarchboard.app/mcp: Streamable HTTP, OAuth 2.1 a partir do seu próprio servidor de autorização com PKCE (S256) e essa URL como indicador de recurso, e registro de cliente por Client ID Metadata Document ou registro dinâmico de clientes. A documentação do servidor MCP lista as ferramentas, e a página de agentes de IA mostra como conectar seu app.

O exemplo usa 14 nós de diagrama e fica dentro do plano Free.

Perguntas frequentes

Qual é a diferença entre host, cliente e servidor MCP? O host é o aplicativo de IA, como uma IDE. Ele cria um cliente por servidor, e cada cliente mantém uma conexão dedicada com um servidor, que expõe ferramentas, recursos e prompts.

O MCP agora é sem estado? Sim, desde a revisão 2026-07-28: sem handshake initialize, sem ID de sessão, e cada requisição carrega sua própria versão e capacidades. Servidores em revisões mais antigas ainda usam o handshake.

Quais transportes o MCP suporta? Dois padrão: stdio para servidores locais e Streamable HTTP para servidores remotos. O HTTP+SSE está obsoleto, e transportes personalizados devem manter o formato de mensagem JSON-RPC.

Servidores MCP locais precisam de OAuth? Não. A especificação diz que servidores stdio devem obter as credenciais do ambiente. Dê a cada um um token de escopo restrito e isole servidores de terceiros em um sandbox.

O que é token passthrough no MCP? Um servidor MCP que aceita um token que não foi emitido para ele, ou que repassa o token do cliente a outra API. A especificação proíbe isso; chamadas upstream precisam do token próprio do servidor.

Comece grátis — um assento, sem cartão de crédito.