MCP 2025-06-18 traz elicitation e saída estruturada para servidores em produção

A especificação oficial do Model Context Protocol↳MCP7 conteúdosArquitetura de Sistemas Cognitivos: Integração de RAG, MCP e LLMs no Ecossistema .NETDev (Back & Front) · abr 2026MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025Agentes de IA com LLMs de Código Aberto: Integração Prática com o Model Context Protocol (MCP)AI · ago 2025Ver tudo em AI → ganhou uma revisão em 18 de junho de 2025, substituindo a versão anterior, de 26 de março daquele ano. O changelog publicado em modelcontextprotocol.io lista mudanças que não são cosméticas: elas afetam como servidor e cliente conversam, como ferramentas devolvem dados e como a autenticação é negociada. Mais de um ano depois, vale olhar com calma o que isso significa para quem já tem um servidor MCP rodando em produção, porque parte dessas mudanças é retrocompatível e parte não é.

O que a revisão de 2025-06-18 mudou na especificação

A fonte organiza as mudanças em duas categorias: as grandes e as de schema. Entre as grandes estão a remoção do suporte a batching de JSON-RPC (PR #416), a adição de saída estruturada em ferramentas (PR #371), a classificação de servidores MCP como OAuth Resource Servers com metadata de descoberta (PR #338), a exigência de Resource Indicators conforme a RFC 8707 nos clientes (PR #734), o suporte a elicitation (PR #382) e a resource links em resultados de tool call (PR #603).

Duas mudanças menores têm peso prático alto. A negociação de versão de protocolo passou a exigir o header MCP-Protocol-Version em toda requisição HTTP subsequente (PR #548), e um SHOULD da operação de lifecycle virou MUST. Nas mudanças de schema, chama atenção o campo _meta adicionado a mais tipos de interface (PR #710) e o novo campo title, que separa nome de exibição do identificador programático (PR #663).

Elicitation: o servidor pode parar o fluxo e pedir mais informação

Antes da revisão, um servidor MCP só tinha os dados que o cliente mandava na chamada da ferramenta. Com elicitation, o servidor pode interromper a execução e pedir ao cliente que colete mais informação do usuário, no meio da interação, antes de continuar. Isso resolve um problema comum em agentes: ferramentas que precisam de confirmação ou de um dado que não estava no prompt original.

O fluxo segue o padrão de requisição já usado em outras partes do protocolo. O servidor manda uma mensagem elicitation/create descrevendo o que precisa, com um schema JSON do formato esperado:

{
 "method": "elicitation/create",
 "params": {
 "message": "Preciso confirmar o diretório de destino antes de continuar",
 "requestedSchema": {
 "type": "object",
 "properties": {
 "directory": { "type": "string" }
 },
 "required": ["directory"]
 }
 }
}

O cliente decide como apresentar isso ao usuário (um formulário, uma pergunta de chat, o que fizer sentido na interface) e responde com uma ação: aceitar e devolver os dados, recusar ou cancelar. Para quem constrói agentes que hoje fazem suposições arriscadas sobre caminho de arquivo, credencial ou escopo de operação, elicitation tira esse chute da equação.

Saída estruturada: tools deixam de devolver só texto solto

Até a versão 2025-03-26, uma ferramenta MCP devolvia resultado como blocos de content genéricos, geralmente texto, e o cliente tinha que parsear essa string para extrair dado estruturado. A PR #371 permite que a definição da ferramenta declare um outputSchema, no mesmo espírito do inputSchema que já existia, e que o resultado traga um campo structuredContent validado contra esse schema.

// Antes: o cliente precisa parsear texto livre
return {
 content: [{ type: "text", text: JSON.stringify(weather) }]
};

// Depois: outputSchema declarado e structuredContent tipado
server.registerTool("get_weather", {
 description: "Retorna a previsão do tempo",
 inputSchema: { city: z.string() },
 outputSchema: {
 temperature: z.number(),
 condition: z.string(),
 },
}, async ({ city }) => {
 const weather = await fetchWeather(city);
 return {
 content: [{ type: "text", text: `Tempo em ${city}: ${weather.condition}` }],
 structuredContent: weather,
 };
});

Na prática, isso elimina uma classe inteira de bug silencioso: parser de texto que quebra quando o modelo formata a resposta de um jeito ligeiramente diferente. Com outputSchema declarado, o cliente valida o retorno contra um contrato, não contra heurística de regex.

Resource links: o resultado vira referência, não corpo inteiro

A PR #603 permite que o resultado de uma tool call inclua links para recursos em vez de embutir o conteúdo inteiro inline. Uma ferramenta que gera um relatório grande, por exemplo, pode devolver uma referência de URI para esse recurso ao invés de colar o arquivo inteiro no resultado. Isso evita estourar o contexto do modelo com payload que ele nem precisa ler por completo, e deixa a decisão de buscar o conteúdo completo para quando for realmente necessário.

O que quebra: batching fora, header obrigatório, autenticação mais rígida

Nem toda mudança da revisão é aditiva. Três pontos exigem trabalho de quem já tem servidor ou cliente MCP em produção, porque não são apenas novos recursos opcionais.

A mudança de autenticação não é só burocracia de schema: ela existe para impedir que um servidor malicioso obtenha um token de acesso emitido para outro recurso. Quem não implementar Resource Indicators no cliente fica exposto justamente ao problema que a mudança tenta fechar.

O roteiro para validar um servidor contra a 2025-06-18

Para quem quer checar se um servidor MCP existente está alinhado com a revisão, o caminho lógico passa por alguns pontos de verificação, na ordem em que normalmente aparecem problemas:

1. Conferir a versão do SDK usado (TypeScript↳TypeScript23 conteúdosTypeScript: ReadonlyArrayDev (Back & Front) · jun 2019Onde usar ANY no TypeScriptDev (Back & Front) · out 2025Tudo sobre o Node rodar TypeScript nativamente!Dev (Back & Front) · jul 2025Ver tudo em Dev (Back & Front) →, Python ou outro) e confirmar que ela já suporta a revisão 2025-06-18, não só a 2025-03-26.
2. Testar a negociação de versão de protocolo via header MCP-Protocol-Version em uma chamada HTTP e verificar se o servidor responde corretamente quando o header falta.
3. Procurar no código do servidor qualquer lugar que ainda monte requisições JSON-RPC em lote; isso precisa virar chamadas individuais.
4. Revisar as definições de tool: quais já têm outputSchema e quais ainda devolvem só texto livre que o cliente tem que parsear.
5. Se o servidor expõe autenticação OAuth, checar se ele publica a metadata de recurso protegido e se o cliente envia Resource Indicators.

Esse roteiro não substitui rodar a suíte de testes de conformidade do protocolo, mas cobre os pontos onde a revisão de 2025-06-18 historicamente quebra integrações que foram escritas contra a 2025-03-26.

Quando não compensa migrar ainda

Elicitation e saída estruturada resolvem problemas reais, mas trazem custo de engenharia que nem toda ferramenta justifica. Um servidor MCP simples, que expõe uma única função determinística sem necessidade de confirmação do usuário, não ganha muito ao implementar o fluxo de elicitation: é complexidade extra sem benefício visível. Da mesma forma, declarar outputSchema só compensa quando o cliente realmente consome o campo structuredContent; se o ecossistema em volta ainda só lê texto, o schema fica decorativo.

O ponto mais sensível continua sendo o ecossistema de clientes. A especificação permite negociação de versão, então servidor e cliente podem, em teoria, conviver em revisões diferentes. Na prática, quem depende de integrações de terceiros ainda presas à 2025-03-26 vai sentir a remoção do batching e a exigência de header antes de conseguir aproveitar elicitation ou saída estruturada.

Fonte: Especificação oficial do Model Context Protocol — Changelog da versão 2025-06-18