Le Validateur d'Agent Card vérifie le JSON collé, les fichiers de Agent Card téléversés, et les URL publiques d'agents par rapport aux exigences de découverte A2A v1.0.
Collez JSON, une URL d'agent public ou faites glisser un fichier JSON dans l'éditeur.
Couverture du Validateur d'Agent Card
Le Validateur d'Agent Card est conçu pour les développeurs publiant des agents A2A, les équipes de plateforme internes révisant les métadonnées d'agents, et les opérateurs de marketplace vérifiant si une Agent Card soumise contient suffisamment d'informations pour un appel fiable.
Collez un document JSON local pendant le développement, téléversez une Agent Card depuis votre dépôt, ou utilisez la validation d'URL en direct contre un domaine déployé pour vérifier les chemins de découverte publics.
Vérifie les champs requis par rapport à la spécification v1.0 : name, description, version, supportedInterfaces avec protocolBinding et protocolVersion par interface, capabilities, modes de contenu, et au moins un skill avec les tags requis.
Détecte les structures antérieures à v1.0 — url de premier niveau, preferredTransport, protocolVersion, provider.name, stateTransitionHistory — et vous indique exactement où chaque champ a été déplacé dans v1.0.
Vérifie que securitySchemes et les exigences de sécurité sont déclarés pour les endpoints non publics, signale les URL non-HTTPS, et recherche des valeurs ressemblant à des clés API, des JWT, ou des tokens bearer intégrés.
Récupère /.well-known/agent-card.json et l'ancien /.well-known/agent.json depuis un domaine en direct et confirme que les deux renvoient du JSON d'Agent Card analysable.
Où s'intègre la validation
Une Agent Card qui a passé la révision le mois dernier peut encore casser la découverte aujourd'hui — un endpoint change, un skill évolue, un redéploiement supprime la route well-known. Les équipes de plateforme et les relecteurs de marketplace traitent la validation comme une porte répétable, pas une vérification unique.
La protection CI la plus simple n'a besoin que de curl : confirmez que le chemin well-known répond avec du JSON analysable avant que le trafic ne bascule vers un nouveau déploiement.
# deploy pipeline: fail if the published card breaks
curl -fsS https://your-domain/.well-known/agent-card.json \
| python3 -c '
import json, sys
card = json.load(sys.stdin)
assert card.get("name"), "name is required"
assert card.get("supportedInterfaces"), "supportedInterfaces missing"
assert card.get("skills"), "skills missing"
print("agent card OK:", card["name"])'Guide de correction
Utilisez le rapport du Validateur d'Agent Card pour traiter d'abord les champs requis, puis améliorez les détails de découverte, de confiance, et de migration.
Remplacez les URL d'endpoint d'espace réservé par l'URL du service A2A HTTPS déployé.
Déplacez le url et preferredTransport de premier niveau dans un tableau supportedInterfaces ordonné — la première entrée est l'interface préférée.
Ajoutez le champ version de premier niveau requis décrivant l'agent lui-même, et ajoutez des tags à chaque skill.
Renommez provider.name en provider.organization et développez les descriptions courtes pour que les clients sachent quand invoquer l'agent.
Déclarez des métadonnées de sécurité chaque fois que l'endpoint de l'agent n'est pas entièrement public — et n'intégrez jamais l'identifiant lui-même.
Publiez le même Agent Card valide sur /.well-known/agent-card.json (et sur le chemin agent.json hérité tant que les clients vérifient encore les deux).
FAQ
Réglez bien l'essentiel avant que votre agent n'atteigne un client A2A.
Comparer des exemples validesLes vérifications suivent la structure Agent Card A2A v1.0 — supportedInterfaces, versions de protocole par interface, tags de skill requis, provider.organization. Les Agent Cards antérieures à v1.0 ne sont pas rejetées d'emblée : les champs hérités apparaissent comme des avertissements avec le remplacement exact de v1.0.
La spécification v1.0 enregistre /.well-known/agent-card.json, mais les implémentations A2A antérieures utilisaient /.well-known/agent.json. Vérifier les deux permet de détecter les lacunes de découverte avant que les clients n'échouent.
Les avertissements ne bloquent pas comme des erreurs JSON, mais ils indiquent généralement des métadonnées qui rendent l'agent plus facile à découvrir, à faire confiance, et à appeler — ou des champs antérieurs à v1.0 que les clients plus récents cesseront de lire.
Trois moments : pendant l'édition d'une Agent Card en développement, comme porte CI avant le déploiement, et après la publication — collez l'URL du service en direct pour confirmer ce que les clients reçoivent réellement des deux chemins de découverte.
Prêt à valider
Collez du JSON, déposez un fichier de Agent Card, ou vérifiez une URL publique depuis l'espace de travail unifié du validateur.