Sujet : protocols
-
Protocoles agent-à-agent en esquisse : cartes d'agent A2A, tâches et la place du MCP
Ce que le protocole A2A (version 1.0.0, Linux Foundation) normalise entre agents indépendants : une Agent Card publiée sur /.well-known/agent-card.json, avec les capacités, les compétences, le point de terminaison et les schémas de sécurité ; des tâches dont le cycle de vie passe par submitted, working, input-required, auth-required, completed, failed, canceled et rejected ; des messages et des artefacts composés de parts ; des liaisons JSON-RPC, gRPC et REST ; et le propre compte rendu de la spécification sur la façon dont elle complète le MCP.
-
MCP Roots, Sampling et Logging : migrations après leur dépréciation dans 2026-07-28
Roots, Sampling et Logging au niveau du protocole sont dépréciés, mais restent présents. Les remplacements documentés nécessitent des décisions distinctes sur les permissions du système de fichiers, l'accès aux modèles et l'observabilité en exploitation.
-
Faire respecter les limites de dépenses des agents avec x402, AP2 et le passage en caisse délégué
Proposition de procédure opérationnelle reliant plafonds par transaction, budgets cumulés, restrictions de destinataires, approbations et reçus aux fonctions des protocoles. L’application des règles et la comptabilisation restent à la charge des composants de paiement de confiance.
-
MCP 2026-07-28 : le cœur sans état et ses limites de compatibilité
La révision de juillet supprime la négociation d’initialisation et les sessions de transport, ajoute des métadonnées propres à chaque requête et des interactions à plusieurs allers-retours, et formalise les extensions et la dépréciation. Les serveurs doivent implémenter la découverte, mais les clients sont libres de l’appeler ou non.
-
Intégration marchande avec ACP : sessions de passage en caisse, jetons délégués et relances sûres
La version datée du 2026-04-17 d’ACP sépare l’état du passage en caisse chez le marchand des justificatifs de paiement délégués. Les marchands doivent disposer de points de terminaison de session versionnés, de gestionnaires de paiement compatibles, d’une finalisation idempotente et de mises à jour de commande authentifiées.
-
Mandats AP2 v0.2 : intention de l’utilisateur, achats autonomes et gouvernance FIDO
AP2 v0.2 utilise des mandats Checkout et Payment ouverts ou fermés pour transmettre une autorisation vérifiable. Son modèle actuel diffère de l’ancienne terminologie Intent/Cart, et l’annonce de la contribution à FIDO ne doit pas être prise pour une norme définitive.
-
Autorisation MCP 2026-07-28 : vérification de l'émetteur et évolution de l'enregistrement des clients
Cette révision renforce la validation de l'émetteur des réponses d'autorisation, lie les identifiants d'enregistrement stockés à leur émetteur et déprécie Dynamic Client Registration. Les Client ID Metadata Documents étaient déjà recommandés dans la révision précédente.
-
MCP 2026-07-28 derrière des répartiteurs de charge HTTP : routage et portée sûre du cache
Les en-têtes de requête permettent le routage sans analyser le JSON, tandis que les indications de cache MCP régissent les résultats admissibles. La validation des en-têtes, l'isolation des contextes d'autorisation et un cache compatible MCP restent nécessaires ; une mise en cache générique des réponses POST ne les remplace pas.
-
Mettre en œuvre les échanges HTTP x402 v2 : en-têtes, facilitateurs et règlement
Présentation de la mise en œuvre de x402 v2 : les trois en-têtes HTTP, les responsabilités du client et du serveur de ressources, et la distinction entre vérification de l’autorisation de paiement et règlement.
-
Migrer un serveur MCP HTTP vers 2026-07-28 tout en prenant en charge les anciens clients
Une migration par étapes sépare l'initialisation des anciens clients des requêtes autonomes, met en œuvre les nouveaux formats de réponse et d'interaction, puis teste les deux modes via la passerelle HTTP réelle.
Lisible par machine : JSON