Conformidade com MCP 2.0

O MCP Fusion usa a revisão de protocolo 2026-07-28 como padrão e mantém um registro escrito de descontinuações, porque um protocolo que muda sob o seu servidor é um risco operacional. Esta página é o mapa de conformidade: o que está implementado, o que foi removido e o que o framework se recusa a fazer.

Conteúdo estruturado

ToolResponse carrega o campo structuredContent do MCP 2.0 junto com o conteúdo de texto. successStructured(data) define ambos: o objeto legível por máquina e um bloco de texto JSON para clientes mais antigos. Combine-o com .withOutputSchema(schema) para publicar o contrato de saída na definição da ferramenta. Observe que os Presenters produzem o formato de texto documentado em Wire format; structuredContent é o canal analisado em paralelo, não uma saída de Presenter.

Requisições com múltiplas idas e voltas

O modelo de requisições iniciadas pelo servidor de 2025 não funciona em serverless. A resposta de 2026 é baseada em retorno: um handler retorna que precisa de entrada, o cliente a fornece e entra novamente. O MCP Fusion expõe isso como requireInput(), readInput(), os descritores de campos ask.* e .interactive() em uma ferramenta, todos documentados em Streaming and cancellation. O driver oferece suporte às duas eras: em uma conexão de 2026, o framework emite a resposta de entrada necessária sem alterações e o SDK conduz a nova tentativa; em uma conexão persistente de 2025, ele atende à requisição pelo canal ativo; sem canal, a chamada é degradada para ELICITATION_UNSUPPORTED, e o loop tem um limite.

Cache de listas (SEP-2549)

Os resultados de listas podem carregar metadados de cache para qualquer proxy diante do seu conector. Configure uma vez:

attachToServer(server, {
  listCacheTtlMs: 300_000,   // default: 5 minutes
  listCacheScope: 'private', // or 'public' for shared data
});

Os metadados são colocados na raiz do resultado, conforme o layout desta revisão, em tools/list, prompts/list, resources/list e resources/templates/list. Definir listCacheTtlMs como zero os remove sem custo adicional. Este é o cache no nível do protocolo da lista; não é a sinalização de obsolescência no nível da ferramenta de State sync.

Selagem do estado de requisições (SEP-2322)

Quando um servidor faz uma ida e volta do estado de continuação por meio de um cliente, esse estado não pode ser falsificado. Forneça uma chave na inicialização:

startServer(registry, {
  transport: 'http',
  requestStateKey: process.env.REQUEST_STATE_KEY,  // 32 bytes or more
});

sealRequestState(payload) então cria um token selado HMAC-SHA256 com expiração, e o servidor verifica cada estado selado recebido antes de entrar novamente em um handler. Sem uma chave, o framework recorre à serialização JSON simples e o marca como não confiável na documentação: seguro para uma continuação não sensível, não para identidade.

Roteamento por cabeçalho e x-mcp-header

O transporte sem estado roteia requisições pelos cabeçalhos Mcp-Method e Mcp-Name em vez de uma sessão, o que permite que qualquer instância atrás de um balanceador round-robin atenda qualquer chamada. Um parâmetro também pode ser espelhado em um cabeçalho HTTP: .withHeaderParam('tenant', 'X-Tenant') anota o esquema com x-mcp-header e o cliente o envia como Mcp-Param-X-Tenant, para que a infraestrutura possa rotear sem analisar corpos. Parâmetros publicados dessa forma não podem ser segredos; o framework lança um erro para um nome de cabeçalho vazio e documenta a restrição de token da RFC 9110.

Notificações de mudança

Quatro eventos de lista e recurso estão conectados: notifications/tools/list_changed (transições de FSM, handoff, recarga a quente), notifications/prompts/list_changed, notifications/resources/updated e notifications/resources/list_changed. No MCP 2.0, o stream subscriptions/listen registra um filtro e o confirma, para que um cliente se inscreva uma vez e receba somente as classes de eventos solicitadas.

O registro de descontinuações

A política de descontinuação é honesta quanto ao estilo: recursos sem significado no servidor simplesmente não existem, recursos desencorajados geram avisos na validação e recursos removidos desaparecem em vez de serem degradados silenciosamente. A janela de remoção publicada para o conjunto descontinuado termina em 2027-07-28.

Artefatos de descoberta

Em http e stateless, o servidor responde em /.well-known/mcp/server-card.json com um cartão do servidor: URL do esquema, versão, versão do protocolo, informações do servidor, transporte (streamable-http com endpoint /mcp, ou stdio), capacidades declaradas e as entradas das ferramentas. Ele é compilado uma vez na inicialização e servido com um cabeçalho de cache público de cinco minutos. Leia os detalhes internos em Introspection.

Códigos de erro tratados pelo SDK

A revisão define códigos no nível do protocolo para incompatibilidade de cabeçalho, ausência de uma capacidade obrigatória do cliente e versão de protocolo não suportada. Eles são emitidos pela camada de servidor do SDK v2 abaixo do framework; o contrato de erro próprio do framework é o envelope <tool_error> documentado em Errors.

Próximos passos

• Runtime architecture: os transportes na prática
• Introspection: cartão e manifesto do servidor
• Streaming and cancellation: MRTR em detalhes