Der Agent Card Validator prüft eingefügtes JSON, hochgeladene Agent Card und öffentliche Agenten-URLs gegen die A2A-v1.0-Discovery-Anforderungen.
Fügen Sie JSON, eine öffentliche Agent-URL, ein oder ziehen Sie eine JSON-Datei in den Editor.
Abdeckung des Agent Card Validators
Der Agent Card Validator ist für Entwickler konzipiert, die A2A-Agenten veröffentlichen, für interne Plattformteams, die Agentenmetadaten prüfen, und für Marketplace-Betreiber, die kontrollieren, ob eine eingereichte Agent Card genügend Informationen für einen zuverlässigen Aufruf enthält.
Füge während der Entwicklung ein lokales JSON-Dokument ein, lade eine Agent Card aus deinem Repository hoch, oder nutze die Live-URL-Validierung gegen eine bereitgestellte Domain, um öffentliche Discovery-Pfade zu überprüfen.
Prüft Pflichtfelder gegen die v1.0-Spezifikation: name, description, version, supportedInterfaces mit protocolBinding und protocolVersion pro Schnittstelle, capabilities, Content-Modi, und mindestens einen Skill mit erforderlichen Tags.
Erkennt Strukturen von vor v1.0 — url auf oberster Ebene, preferredTransport, protocolVersion, provider.name, stateTransitionHistory — und zeigt dir genau, wohin jedes Feld in v1.0 verschoben wurde.
Überprüft, ob securitySchemes und Sicherheitsanforderungen für nicht-öffentliche Endpunkte deklariert sind, markiert Nicht-HTTPS-URLs, und scannt nach Werten, die wie eingebettete API-Schlüssel, JWTs, oder Bearer-Tokens aussehen.
Ruft /.well-known/agent-card.json und das ältere /.well-known/agent.json von einer Live-Domain ab und bestätigt, dass beide parsbares Agent Card-JSON zurückgeben.
Wo Validierung ansetzt
Eine Agent Card, die letzten Monat die Prüfung bestanden hat, kann Discovery heute immer noch brechen — ein Endpunkt verschiebt sich, ein Skill ändert sich, ein Redeploy verwirft die well-known Route. Plattformteams und Marketplace-Prüfer behandeln Validierung als wiederholbares Gate, nicht als einmalige Prüfung.
Der einfachste CI-Schutz braucht nichts weiter als curl: Bestätige, dass der well-known Pfad mit parsbarem JSON antwortet, bevor der Traffic auf ein neues Deployment umschaltet.
# 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"])'Fix-Leitfaden
Nutze den Bericht des Agent Card Validators, um zuerst Pflichtfelder zu beheben, und verbessere dann Discovery-, Vertrauens- und Migrationsdetails.
Ersetze Platzhalter-Endpunkt-URLs durch die bereitgestellte HTTPS-A2A-Service-URL.
Verschiebe url und preferredTransport auf oberster Ebene in ein geordnetes supportedInterfaces-Array — der erste Eintrag ist die bevorzugte Schnittstelle.
Füge das erforderliche version-Feld auf oberster Ebene hinzu, das den Agenten selbst beschreibt, und füge jedem Skill Tags hinzu.
Benenne provider.name in provider.organization um und erweitere kurze Beschreibungen, damit Clients wissen, wann sie den Agenten aufrufen sollen.
Deklariere Sicherheitsmetadaten, wann immer der Agenten-Endpunkt nicht vollständig öffentlich ist — und bette niemals das Credential selbst ein.
Veröffentliche dieselbe gültige Agent Card unter /.well-known/agent-card.json (und unter dem älteren agent.json-Pfad, solange Clients noch beide prüfen).
FAQ
Bring die Grundlagen in Ordnung, bevor dein Agent einen A2A-Client erreicht.
Gültige Beispiele vergleichenDie Prüfungen folgen der A2A-v1.0-Agent Card-Struktur — supportedInterfaces, Protokollversionen pro Schnittstelle, erforderliche Skill-Tags, provider.organization. Agent Card von vor v1.0 werden nicht rundweg abgelehnt: Legacy-Felder erscheinen als Warnungen mit dem genauen v1.0-Ersatz.
Die v1.0-Spezifikation registriert /.well-known/agent-card.json, aber frühere A2A-Implementierungen verwendeten /.well-known/agent.json. Die Prüfung beider erkennt Discovery-Lücken, bevor Clients scheitern.
Warnungen blockieren nicht wie JSON-Fehler, weisen aber meist auf Metadaten hin, die den Agenten leichter auffindbar, vertrauenswürdig und aufrufbar machen — oder auf Felder von vor v1.0, die neuere Clients nicht mehr lesen werden.
Zu drei Zeitpunkten: während der Bearbeitung einer Agent Card in der Entwicklung, als CI-Gate vor dem Deployment, und nach der Veröffentlichung — füge die Live-Service-URL ein, um zu bestätigen, was Clients tatsächlich von beiden Discovery-Pfaden erhalten.
Bereit zur Validierung
Füge JSON ein, lege eine Agent Card ab, oder prüfe eine öffentliche URL im einheitlichen Validator-Arbeitsbereich.