Conformité MCP 2.0

MCP Fusion cible par défaut la révision du protocole 2026-07-28 et tient un registre écrit des dépréciations, car un protocole qui change sous votre serveur représente un risque opérationnel. Cette page est la carte de conformité : ce qui est implémenté, ce qui a été retiré et ce que le framework refuse de faire.

Contenu structuré

ToolResponse porte le champ structuredContent de MCP 2.0 en plus du contenu textuel. successStructured(data) définit les deux : l’objet lisible par machine et un bloc de texte JSON pour les clients plus anciens. Associez-le à .withOutputSchema(schema) pour publier le contrat de sortie dans la définition de l’outil. Notez que les Presenters produisent la forme textuelle documentée dans Wire format ; structuredContent est le canal analysé parallèle, pas une sortie de Presenter.

Requêtes à allers-retours multiples

Le modèle de requêtes initiées par le serveur de 2025 ne survit pas au serverless. La réponse de 2026 repose sur le retour : un handler indique qu’il a besoin d’une entrée, le client la fournit et réintègre le handler. MCP Fusion l’expose avec requireInput(), readInput(), les descripteurs de champs ask.* et .interactive() sur un outil, le tout documenté dans Streaming and cancellation. Le driver prend en charge les deux époques : sur une connexion de 2026, le framework émet telle quelle la réponse d’entrée requise et le SDK pilote la nouvelle tentative ; sur une connexion persistante de 2025, il satisfait lui-même la requête via le canal actif ; sans canal, l’appel est dégradé en ELICITATION_UNSUPPORTED et la boucle est plafonnée.

Mise en cache des listes (SEP-2549)

Les résultats de listes peuvent contenir des métadonnées de cache pour tout proxy placé devant votre connecteur. Configurez-la une seule fois :

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

Les métadonnées sont placées à la racine du résultat, conformément à la disposition de cette révision, sur tools/list, prompts/list, resources/list et resources/templates/list. Mettre listCacheTtlMs à zéro les supprime sans surcharge. Il s’agit de la mise en cache de la liste au niveau du protocole, et non du signalement d’obsolescence au niveau de l’outil dans State sync.

Scellement de l’état des requêtes (SEP-2322)

Lorsqu’un serveur fait transiter l’état de continuation par un client, cet état ne doit pas pouvoir être falsifié. Fournissez une clé au démarrage :

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

sealRequestState(payload) crée alors un jeton scellé HMAC-SHA256 avec expiration, et le serveur vérifie chaque état scellé entrant avant de réintégrer un handler. Sans clé, le framework revient à une sérialisation JSON simple et le marque comme non fiable dans la documentation : acceptable pour une continuation non sensible, pas pour une identité.

Routage par en-têtes et x-mcp-header

Le transport sans état route les requêtes avec les en-têtes Mcp-Method et Mcp-Name plutôt qu’avec une session, ce qui permet à toute instance derrière un équilibreur round-robin de servir n’importe quel appel. Un paramètre peut aussi être reflété dans un en-tête HTTP : .withHeaderParam('tenant', 'X-Tenant') annote le schéma avec x-mcp-header et le client l’envoie comme Mcp-Param-X-Tenant, afin que l’infrastructure puisse router sans analyser les corps. Les paramètres publiés de cette façon ne doivent pas être des secrets ; le framework lève une erreur pour un nom d’en-tête vide et documente la contrainte de token de la RFC 9110.

Notifications de changement

Quatre événements de liste et de ressource sont câblés : notifications/tools/list_changed (transitions de FSM, handoff, rechargement à chaud), notifications/prompts/list_changed, notifications/resources/updated et notifications/resources/list_changed. Dans MCP 2.0, le flux subscriptions/listen enregistre un filtre et l’accuse réception, afin qu’un client s’abonne une fois et ne reçoive que les classes d’événements demandées.

Le registre des dépréciations

La politique de dépréciation est honnête quant au style : les fonctionnalités sans signification côté serveur sont simplement absentes, celles qui sont déconseillées émettent un avertissement à la validation et celles qui sont retirées disparaissent au lieu d’être dégradées silencieusement. La fenêtre de retrait publiée pour l’ensemble déprécié se termine le 2027-07-28.

Artefacts de découverte

Sur http et stateless, le serveur répond à /.well-known/mcp/server-card.json avec une fiche serveur : URL du schéma, version, version du protocole, informations du serveur, transport (streamable-http avec le point de terminaison /mcp, ou stdio), capacités déclarées et entrées des outils. Elle est compilée une fois au démarrage et servie avec un en-tête de cache public de cinq minutes. Consultez les détails internes dans Introspection.

Codes d’erreur gérés par le SDK

La révision définit des codes au niveau du protocole pour une discordance d’en-tête, l’absence d’une capacité client requise et une version de protocole non prise en charge. Ils sont émis par la couche serveur du SDK v2 sous le framework ; le contrat d’erreur propre au framework est l’enveloppe <tool_error> documentée dans Errors.

Étapes suivantes

• Runtime architecture : les transports en pratique
• Introspection : fiche serveur et manifeste
• Streaming and cancellation : MRTR en détail