MCP explicado pela especificação: o que é realmente um server

Antes do wire, a aritmética. Tem $N$ aplicações de IA e $M$ coisas a que elas deveriam conseguir chegar — um calendário, um gestor de tickets, uma base de dados de armazém, uma ferramenta de design. Sem um contrato partilhado, alguém escreve $N \times M$ integrações, e cada uma delas é um schema mais um endpoint mais uma história de autenticação mais um encargo de manutenção. Com um contrato, o fornecedor da ferramenta escreve um server, o fornecedor da aplicação escreve um cliente, e o total é $N + M$.

Isto não é uma observação nova, e a especificação diz de quem foi a ideia:

MCP takes some inspiration from the Language Server Protocol, which standardizes how to add support for programming languages across a whole ecosystem of development tools. In a similar way, MCP standardizes how to integrate additional context and tools into the ecosystem of AI applications.¹

Leve essa comparação à letra, não como um elogio. Antes desse protocolo, suportar uma linguagem num editor significava um plugin por editor; depois, uma equipa de linguagem enviava um único server e todos os editores o recebiam. A medida de sucesso não era a elegância, era o facto de a contagem de integrações deixar de se multiplicar. O mesmo acontece aqui: o valor está no número de implementações, não no design. Um protocolo falado por dois produtos é um formato de dados com cerimónia extra.

As mensagens MCP são JSON-RPC 2.0. Um pedido é um objeto com jsonrpc, um id, um method e params opcional; uma resposta transporta o mesmo id e ou result ou error; uma notificação é um pedido sem id e não recebe resposta. A especificação acrescenta três restrições por cima: o id tem de ser uma string ou um número e não pode ser null, não pode colidir com outro pedido ainda em curso, e todos os resultados têm de transportar um campo resultType.²

No transporte stdio — o que o comando acima usou — a regra de framing é uma linha por mensagem:

Messages are delimited by newlines, and MUST NOT contain embedded newlines. […] The server MUST NOT write anything to its stdout that is not a valid MCP message.³

Essa última cláusula é a forma mais comum de um server caseiro falhar, e falha em silêncio: um console.log perdido, uma barra de progresso, um aviso de depreciação de uma dependência, e o parser de linhas do cliente encontra algo que não é JSON. A escapatória está na mesma secção — o server pode escrever o que quiser em stderr, e o cliente não deve tratar isso como erro. O server de referência acima imprime Starting default (STDIO) server... em cada arranque, em stderr, e é por isso que o pipe continuou a funcionar.

O outro transporte standard é Streamable HTTP: cada mensagem é um POST para um único endpoint, e a resposta é ou um objeto JSON ou uma stream de Server-Sent Events com o âmbito do pedido — o wire format que o Capítulo 14 analisou à mão. A semântica é idêntica em ambos, porque um transporte é um binding: define framing e entrega, não significado.⁴

O comando acima enviou tools/list e mais nada. Na revisão atual, esse pedido está malformado, e um server conforme tem de o rejeitar.

Desde 2026-07-28, MCP é um protocolo stateless, e a especificação diz isso sem hesitação:

The Model Context Protocol (MCP) is a stateless protocol: all the information needed to process a request is contained in the request itself. A server processes each request independently; no state should be inferred from previous requests, even those on the same connection or stream.²

Por isso, cada pedido transporta a sua própria versão do protocolo e as suas próprias capacidades de cliente, num objeto reservado _meta dentro de params. Dois desses campos são obrigatórios em todos os pedidos; um pedido sem qualquer um deles é malformado e o server tem de responder -32602:²

Escrito por extenso, um tools/list correto é isto — e é a última vez que este capítulo mostra os metadados por inteiro, porque estão em todos os pedidos daqui em diante:

{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{"_meta":{
  "io.modelcontextprotocol/protocolVersion":"2026-07-28",
  "io.modelcontextprotocol/clientCapabilities":{"elicitation":{"form":{}}},
  "io.modelcontextprotocol/clientInfo":{"name":"bare-hands","version":"0.0.1"}}}}

O objeto de capacidades é a negociação. Já não há um passo separado de negociação: o cliente declara o que consegue fazer em cada pedido, o server declara o que consegue fazer no resultado, e nenhum dos lados pode usar uma funcionalidade que o outro não tenha reivindicado. Um server que precise de uma capacidade que o cliente não declarou tem de responder -32021 e nomear a capacidade em falta em data.requiredCapabilities. Um server que não fale a versão pedida tem de responder -32022 e listar as versões que fala.²

Clientes que queiram a resposta logo à partida podem pedi-la: server/discover é um RPC obrigatório que devolve versões suportadas, capacidades, identidade e um bloco opcional de instructions numa só ida e volta.⁵ Chamá-lo é opcional. Implementá-lo não é.

O comando funcionou. Na revisão atual não deveria ter funcionado, e a razão por que funcionou merece uma medição, não um parágrafo, porque é o estado de todo o ecossistema numa linha.

Sonde o server de referência da forma como a especificação manda um cliente moderno sondar:

echo '{"jsonrpc":"2.0","id":1,"method":"server/discover","params":{"_meta":{
  "io.modelcontextprotocol/protocolVersion":"2026-07-28",
  "io.modelcontextprotocol/clientCapabilities":{}}}}' \
  | npx @modelcontextprotocol/server-everything stdio

{"jsonrpc":"2.0","id":1,"error":{"code":-32601,"message":"Method not found"}}

Esse é o terceiro ramo da regra de compatibilidade: um DiscoverResult significa moderno, um erro moderno reconhecido significa moderno-mas-versão-errada, e qualquer outra coisa — incluindo -32601 — significa legacy, recue para o handshake initialize.³ Então faça isso, pedindo a revisão atual:

→ {"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2026-07-28",
   "capabilities":{},"clientInfo":{"name":"bare-hands","version":"0.0.1"}}}

← {"result":{"protocolVersion":"2025-11-25","capabilities":{"tools":{"listChanged":true},
   "prompts":{"listChanged":true},"resources":{"subscribe":true,"listChanged":true},
   "logging":{},"tasks":{…},"completions":{}},"serverInfo":{"name":"mcp-servers/everything",
   "title":"Everything Reference Server","version":"2.0.0"},"instructions":"…"}}

O cliente pediu 2026-07-28 e o server respondeu 2025-11-25. Em 7 de setembro de 2026, o server oficial de referência — pacote npm @modelcontextprotocol/server-everything, versão 2026.8.31, publicado a 31 de agosto de 2026 — não implementa a revisão atual. Nem, nas datas, o SDK TypeScript em que foi construído: a release 1.30.0 saiu a 27 de julho de 2026, na véspera da revisão.

Leia a consequência, não a fofoca. Quase tudo o que está escrito sobre MCP descreve um protocolo com um handshake initialize, uma sessão, um pedido roots/list que o server envia ao cliente, e um transporte HTTP+SSE. Os quatro desapareceram ou estão a desaparecer. Quando ler qualquer coisa sobre MCP, incluindo esta página, a primeira coisa a procurar é um número de revisão.

E a razão por que o primeiro comando funcionou está indicada na especificação como um perigo, não uma funcionalidade:

some legacy servers do not validate that a request arrives after initialize and would process an era-ambiguous method (such as tools/call) under legacy semantics. Probing yields a deterministic failure instead.³

Medido: enviar tools/list a esse server sem handshake nenhum devolve o catálogo completo. Um método que devia ter sido recusado foi servido, que é exatamente por isso que a especificação diz para sondar primeiro com server/discover, mesmo quando só suporta versões modernas.

MCP tem três partes, e a distinção entre as duas primeiras é a que as pessoas tendem a colapsar:

Server. Um processo ou serviço que expõe recursos, ferramentas e prompts. Pode ser local ou remoto, opera de forma independente, e toda a sua função é uma área focada.⁶

Essa regra de "exatamente um server" não é contabilidade. É o que torna implementável o princípio de design abaixo, e esta é a frase a reter da especificação se só reter uma:

Servers should not be able to read the whole conversation, nor "see into" other servers. Servers receive only necessary contextual information. Full conversation history stays with the host. Each server maintains isolation. Cross-server interactions are controlled by the host.⁶

Isto vira do avesso o modelo mental com que a maioria das pessoas chega. Um server de meteorologia que liga ao seu assistente não vê o que perguntou. Vê um tools/call com os argumentos que o modelo escolheu, e nada mais — nem os turnos anteriores, nem o seu system prompt, nem os resultados que o server de calendário devolveu há um momento. Se dois servers precisarem de cooperar, o host transporta um valor de um para o outro, deliberadamente, porque o modelo o pediu. É por isso que o isolamento é a propriedade de segurança em que o Capítulo 30 assenta: um server comprometido tem um raio de explosão pequeno e definido, e aumentá-lo exige a cooperação do host.

O primeiro comando pediu ferramentas a esse server e recebeu treze. Faça-lhe as outras duas perguntas e ele também responde: resources/list devolve sete, prompts/list devolve quatro. Nenhum apareceu, porque nada perguntou. O que nos traz à espinha pedagógica de MCP, presente na especificação como uma tabela que quase ninguém cita:

Não são "três formas de expor uma capacidade". São três respostas a quem decide que isto acontece. O modelo decide chamar uma ferramenta. A aplicação decide anexar um recurso. A pessoa decide executar um prompt. Se errar isto, a funcionalidade continua a funcionar, mas funciona no momento errado e pela razão errada.

A forma mais clara de o sentir é um calendário. Aqui está um server que expõe o mesmo calendário três vezes, uma como cada primitivo, em cem linhas de Node puro sem dependências:

const TOOL = {
  name: "create_event",
  description: "Create a calendar event. Writes to the calendar.",
  inputSchema: {
    type: "object",
    properties: {
      title:    { type: "string", description: "Event title." },
      startsAt: { type: "string", format: "date-time", description: "Start, ISO 8601 UTC." },
    },
    required: ["title"],
  },
};

switch (method) {
  case "resources/read":                                          
    return ok(id, { contents: [{ uri: "calendar://week",
      mimeType: "application/json", text: JSON.stringify(EVENTS) }],
      ttlMs: 60000, cacheScope: "private" });

  case "prompts/get":                                             
    return ok(id, { description: PROMPT.description, messages: [{ role: "user",
      content: { type: "text", text: `Read calendar://week and draft a plan. ` +
        `Focus: ${params.arguments?.focus ?? "balance"}.` } }] });

  case "tools/list":                                              
    return ok(id, { tools: [TOOL], ttlMs: 300000, cacheScope: "public" });
}

Execute-o e pergunte-lhe das três formas. Output real, uma mensagem por linha no wire, embrulhado aqui para a página, com o _meta do pedido e o bloco de identidade do server omitidos:

→ resources/read  {"uri":"calendar://week"}
← {"resultType":"complete","contents":[{"uri":"calendar://week",
   "mimeType":"application/json","text":"[{\"id\":\"e1\",\"title\":\"Standup\",
   \"startsAt\":\"2026-09-07T09:00:00Z\"},{\"id\":\"e2\",\"title\":\"Design review\",
   \"startsAt\":\"2026-09-09T15:00:00Z\"}]"}],"ttlMs":60000,"cacheScope":"private"}

→ prompts/get    {"name":"prepare_week","arguments":{"focus":"deep work"}}
← {"resultType":"complete","description":"Read the week and draft a plan.",
   "messages":[{"role":"user","content":{"type":"text",
   "text":"Read calendar://week and draft a plan. Focus: deep work."}}]}

→ tools/call     {"name":"create_event","arguments":{"title":"Dentist",
                  "startsAt":"2026-09-10T08:30:00Z"}}
← {"resultType":"complete","content":[{"type":"text",
   "text":"Created e3: Dentist at 2026-09-10T08:30:00Z"}],
   "structuredContent":{"id":"e3","title":"Dentist","startsAt":"2026-09-10T08:30:00Z"},
   "isError":false}

Três métodos, três formas, um calendário. Agora o ponto:

Quase toda a gente transforma estas três coisas em ferramentas. O resultado é um catálogo onde uma leitura que a aplicação devia ter anexado silenciosamente compete pela attention do modelo com uma escrita que precisa de aprovação, e onde a única coisa para a qual uma pessoa queria um botão fica enterrada num schema. Não custa nada acertar, e decide-se antes de escrever uma linha.

A ferramenta de calendário tem um argumento obrigatório, title, e um opcional, startsAt. Peça-lhe para criar um evento sem data, e algo interessante volta:

→ tools/call {"name":"create_event","arguments":{"title":"Dentist"}}

← {"resultType":"input_required",
   "inputRequests":{"when":{"method":"elicitation/create","params":{"mode":"form",
     "message":"When should \"Dentist\" start?",
     "requestedSchema":{"type":"object",
       "properties":{"startsAt":{"type":"string","format":"date-time"}},
       "required":["startsAt"]}}}},
   "requestState":"eyJ0aXRsZSI6IkRlbnRpc3QifQ=="}

O server não enviou um pedido. Respondeu ao que lhe foi dado, com resultType: "input_required" e uma descrição do que ainda precisa. O cliente recolhe a resposta da pessoa e depois reenvia a chamada original — com um novo id, transportando inputResponses e ecoando de volta o requestState opaco:

→ tools/call {"name":"create_event","arguments":{"title":"Dentist"},
   "inputResponses":{"when":{"action":"accept",
     "content":{"startsAt":"2026-09-10T08:30:00Z"}}},
   "requestState":"eyJ0aXRsZSI6IkRlbnRpc3QifQ=="}

← {"resultType":"complete","content":[{"type":"text",
   "text":"Created e3: Dentist at 2026-09-10T08:30:00Z"}],"isError":false}

Isto é Multi Round-Trip Requests, introduzido na revisão atual, e substituiu o desenho antigo em que servers enviavam pedidos JSON-RPC de volta para clientes. A especificação de transporte diz agora a regra de forma direta: "servers do not initiate JSON-RPC requests and clients do not send JSON-RPC responses".⁴ Há uma direção de iniciativa, e pertence ao host.

Duas funcionalidades do lado do cliente assentam nesse mecanismo, e uma delas tem um nome que o vai fazer tropeçar.

Elicitation é o server pedir algo à pessoa: um formulário com um JSON Schema deliberadamente restrito — objetos planos, propriedades primitivas, sem aninhamento — para que qualquer cliente o possa renderizar sem motor de layout. Traz uma regra rígida: servers não podem usar o modo formulário para pedir "passwords, API keys, access tokens, or payment credentials", e têm de usar o modo URL para isso, que envia o utilizador para uma página que o cliente nunca lê.⁷

Sampling é o server pedir uma geração ao modelo do host, para que um server possa ser inteligente sem guardar uma API key. E aqui fica o aviso de vocabulário, porque esta palavra já significa outra coisa neste curso: isto não é o sampling do Capítulo 17. Nada aqui tem a ver com temperatura, top-p ou a forma de uma distribuição de probabilidade. É uma chamada de modelo aninhada a viajar para trás através de um protocolo.

Há uma segunda razão para não recorrer a isto: nesta revisão, sampling está deprecated, juntamente com roots e logging, ao abrigo de SEP-2577, com uma migração sugerida sem rodeios — "integrate directly with LLM provider APIs instead of Sampling".⁸ A ideia não falhou tecnicamente; falhou em justificar a sua área de superfície, e um protocolo que consegue remover coisas é mais saudável do que um que não consegue.

A statelessness parece um detalhe de wire format até a testar. Pegue na troca de três mensagens acima e execute cada mensagem num processo separado — um node calendar.mjs fresco, sem memória partilhada, sem nada transportado:

process A   tools/call (no date)   → resultType: input_required
                                     requestState: eyJ0aXRsZSI6IkRlbnRpc3QifQ==
process B   tools/call (with the answer, same requestState)
                                   → resultType: complete
                                     "Created e3: Dentist at 2026-09-10T08:30:00Z"
process C   resources/read calendar://week
                                   → events: 2  (Standup, Design review)

O processo B, que nunca viu a pergunta, completou uma chamada multi-round-trip que o processo A começou. Esse é o objetivo de requestState: a continuação viaja na mensagem, por isso nada depende de o processo ser o mesmo.

O processo C é a falha. O evento foi criado e não está lá — porque o server de brinquedo mantém EVENTS num array ao nível do módulo, e um array ao nível do módulo é estado de ligação. A nota da especificação nomeia o erro com precisão:

an open connection, such as a STDIO process, is not a conversation or session: clients may interleave unrelated requests on the same transport, and a server must not treat connection or process identity as a proxy for conversation or session continuity.²

A correção prescrita não é uma sessão. É um handle explícito: uma ferramenta de criação devolve um identificador opaco, e todas as chamadas posteriores o recebem como argumento normal. O protocolo não tem conceito dele — "from the wire's perspective a handle is an ordinary string in a tool result and an ordinary argument to subsequent tool calls".⁹ Isto põe o modelo encarregado de o transportar, e põe o server encarregado de validar que este chamador está autorizado a usá-lo em cada chamada, porque um handle é um nome, não uma permissão.

Cada ferramenta que um server expõe é um schema que entra no seu prompt em todos os pedidos, e o Capítulo 24 mediu o que isso faz a uma context window. MCP acrescenta uma segunda rubrica fácil de ignorar, por isso vale a pena contar ambas no server de referência acima.

13 tool definitions (name + description + inputSchema):  1,307 tokens
  cheapest tool, get-tiny-image                              52
  costliest tool, gzip-file-as-resource                     235
server `instructions`, returned by discovery:               312 tokens
                                                          ------
one server, connected, before it is used:                 1,619 tokens

Duas observações. A primeira é aritmética: ligue cinco servers deste tamanho e cerca de oito mil tokens da sua context window ficam ocupados em todos os turnos, para sempre, quer o modelo use algum deles quer não — que é o mecanismo por trás da redução de 150.000 para 2.000 citada no Capítulo 24, e a razão por que existe descoberta de ferramentas just-in-time.

A segunda é uma nota de segurança disfarçada de contabilidade. instructions é texto em linguagem natural, escrito pelo autor do server, que entra no prompt do host, e as descrições de ferramentas ao lado são iguais. A especificação diz o que fazer quanto a isso nos seus próprios princípios de segurança: anotações e descrições de ferramentas "should be considered untrusted, unless obtained from a trusted server", e hosts "must obtain explicit user consent before invoking any tool".¹ Ligar um server MCP não é adicionar uma dependência. É conceder a um estranho 1.619 tokens do seu system prompt e o direito a ser chamado. O Capítulo 30 mostra o que acontece quando esse estranho é hostil.

Tudo nesta secção é verdadeiro para a revisão do protocolo 2026-07-28, a atual, lida em 7 de setembro de 2026. As revisões são datadas YYYY-MM-DD e a data é a última vez que foi feita uma alteração retroincompatível.¹⁰ O documento normativo é um ficheiro TypeScript, schema/2026-07-28/schema.ts; o JSON Schema ao lado é gerado a partir dele, e é por isso que a especificação é lida aqui em TypeScript e ensinar MCP a partir de outra coisa é ensinar uma tradução.

A alteração de governação por baixo dessa tabela é mais importante do que qualquer linha isolada. Esta revisão adotou uma política de ciclo de vida de funcionalidades e depreciação: as funcionalidades são Active, Deprecated ou Removed, uma funcionalidade deprecated documenta o seu caminho de migração e permanece na especificação durante pelo menos doze meses antes de se tornar elegível para remoção, e há um registo que lista tudo o que está atualmente no estado Deprecated.⁸ Antes dessa política, "deprecated" num protocolo de IA significava o que dissesse o último blog post. Agora significa uma data.

Este é o vocabulário de todo o bloco num só lugar.

Dois desses merecem uma frase cada, porque é aí que a confusão realmente vive.

MCP face a A2A não é uma rivalidade, e ambas as especificações o dizem. A documentação A2A traça a linha pelo que está do outro lado: MCP "defines how an AI agent interacts with and utilizes individual tools and resources, such as a database or an API", em que uma ferramenta executa "specific, often stateless, functions"; A2A aborda agents, "more autonomous systems" que "reason, plan, use multiple tools, maintain state over longer interactions, and engage in complex, often multi-turn dialogues". O seu próprio resumo é a frase a reter: "A2A is about agents partnering on tasks, while MCP is more about agents using capabilities."¹¹ Os dois encaixam — uma aplicação usa A2A para chegar a outros agents, e cada agent usa MCP para chegar às suas próprias ferramentas. O Capítulo 25 traçou essa linha dentro de um processo, entre pedir a um sub-agent e passar-lhe a conversa; A2A traça-a entre organizações.

MCP face a ACP é uma comparação com uma premissa caduca, que é exatamente por isso que vale a pena responder. O Agent Communication Protocol era uma norma aberta separada para mensagens agent-to-agent. A sua própria documentação agora abre com o aviso: "ACP is now part of A2A under the Linux Foundation!"¹² A resposta honesta a "MCP ou ACP?" em setembro de 2026 é que a pergunta tem uma opção a menos do que as páginas que ranqueiam para ela sugerem.

E a comparação que as pessoas mais pedem, mcp vs api, tem a resposta menos interessante: MCP é uma API. O que acrescenta não é poder, são convenções — um conjunto fixo de nomes de métodos, uma chamada de descoberta, uma hierarquia de controlo sobre os primitivos, e um modelo de isolamento. Abdica da liberdade de desenhar a sua própria interface e recebe todos os hosts que falam o protocolo, que é a troca que todos os protocolos sempre ofereceram.

Agora consegue ler a especificação sem tradutor, distinguir um recurso de uma ferramenta e de um prompt por quem manda nele, escrever um pedido à mão quando uma biblioteca de cliente lhe está a mentir, e datar qualquer artigo sobre MCP que leia pelas funcionalidades deprecated que ainda ensina como atuais.

O que ainda não fez foi enviar um para produção. O Capítulo 27 escreve o mesmo server duas vezes — TypeScript e Python, lado a lado, porque MCP é o único território genuinamente bilingue deste curso e os números dizem-no nos dois sentidos. Cobre corretamente os dois transportes vivos, o inspector, packaging, e a metade do protocolo que este capítulo deixou deliberadamente de lado: autorização. Porque no momento em que o seu server é remoto em vez de um subprocesso no seu próprio portátil, o cliente de um estranho apresentará um token, e a regra da especificação sobre o que pode fazer com ele é invulgarmente rigorosa.

O que levanta a pergunta a que o próximo capítulo tem de responder, e não é uma pergunta amigável: se um token chega ao seu server e foi emitido para a audience de outra pessoa, o que o impede exatamente de o encaminhar?

Todas as citações, nomes de métodos, códigos de erro e regras deste capítulo foram lidos na especificação do Model Context Protocol, revisão 2026-07-28, em 7 de setembro de 2026. Todos os traces foram produzidos localmente em Node 22: o server de calendário de brinquedo tem 101 linhas sem dependências, e o server de referência é o pacote npm publicado com o nome abaixo. Nenhuma API paga foi chamada para escrever este capítulo — nada aqui precisa de um modelo, o que é em si o ponto.

As medições: @modelcontextprotocol/server-everything@2026.8.31, publicado a 31 de agosto de 2026, construído sobre @modelcontextprotocol/sdk@1.30.0, publicado a 27 de julho de 2026 — um dia antes da revisão que este capítulo descreve. Responde a server/discover com -32601, negoceia 2025-11-25 quando lhe pedem 2026-07-28, e serve tools/list sem handshake nenhum. O seu catálogo tem 13 ferramentas em 7.663 bytes; as contagens de tokens são o200k_base via tiktoken, sobre o name, description e inputSchema de cada definição, que é o que um provider renderiza no seu prompt e não o que pesa o frame JSON-RPC.

Anthropic, Code execution with MCP: building more efficient agents, 4 de novembro de 2025, é a fonte do valor de 150.000 para 2.000, citado e usado no Capítulo 24 e apenas referenciado aqui.