Was ist A2A? Agent2Agent: Spezifikation & Sicherheit (2026)

A2A beschreibt die Arbeitsteilung mit MCP offiziell so: „MCP ist vertikal und vertieft einen einzelnen Agenten; A2A ist horizontal und verbindet Agenten über Grenzen hinweg.“ In A2A ist die aufgerufene Seite ein „undurchsichtiger“ Agent: Er schlussfolgert selbst und verwaltet seinen Zustand selbst, der Aufrufer sieht nicht, welche Modelle oder Tools er intern nutzt, und beide Seiten interagieren über mehrere Runden ausschließlich über den Lebenszyklus einer Aufgabe (Task). Auch taiwanische Behördendokumente behandeln A2A bereits: Das Referenzhandbuch für KI-Anwendungen im öffentlichen Sektor V1.0 des Ministeriums für Digitale Angelegenheiten (im Dokument angegebenes Bereitstellungsdatum 115-01-28, Minguo-Kalender) enthält auf Seite 14 einen Unterabschnitt „A2A: Kommunikationsprotokoll zwischen KI-Agenten“, der erläutert, dass es sich auf die Kommunikation „Client–Remote“ konzentriert.

Die Governance von A2A durchlief drei Phasen. Am 2025-06-23 kündigte die Linux Foundation die Übernahme an; Gründungsmitglieder waren AWS, Cisco, Google, Microsoft, Salesforce, SAP und ServiceNow. Am 2025-08-29 ging das von IBM geführte ACP in A2A auf und wurde eingestellt. Die eigentliche Entscheidungsgewalt liegt bei einem Technical Steering Committee (TSC) mit 9 Sitzen, ein Sitz pro Unternehmen: Google, Microsoft, Cisco, AWS, Salesforce, ServiceNow, SAP, IBM und Bloomberg. Über Vorschläge wird mit gitvote in GitHub-Issues mit dem Label TSC Review abgestimmt; so fasste etwa #1942 41 Issues zu acht Themen für v1.1 zusammen und wurde am 2026-06-25 mit 5 Ja- zu 0 Nein-Stimmen angenommen (Schwelle 51 %).

Im August 2026 trat A2A der Agentic AI Foundation (AAIF) als Growth-Stage-Projekt bei und steht damit unter derselben Stiftung wie MCP. Die Quellen nennen unterschiedliche Daten: Der AAIF-Blog und Axios schreiben 2026-08-17, der offizielle A2A-Blog und die Spezifikationsseite 2026-08-27, der Bericht von Forbes ist auf 08-19 datiert. Möglicherweise war 08-17 die öffentliche Ankündigung der Stiftung und 08-27 der Beitrag des Projekts selbst, doch keine Quelle bestätigt diese Erklärung; dieser Artikel nennt daher beide Daten und wählt nicht stellvertretend für die Leser eines aus. Diginomica zählt A2A als 5. von der AAIF betreutes Projekt nach MCP, goose, AGENTS.md und agentgateway; Sekundärquellen betonen zudem, dass es sich nur um eine organisatorische Änderung handelt und die beiden Spezifikationen nicht zusammengeführt wurden.

Das A2A-Governance-Dokument legt fest, dass „18 Monate nach der Gründung über die Zusammensetzung in der stabilen Phase entschieden wird“. Ab Juni 2025 gerechnet fällt das etwa auf Dezember 2026, und die AAIF-Ankündigung sagt nichts darüber, ob das TSC neu besetzt wird. Dies ist eine Schlussfolgerung: Die Zusammensetzung des TSC könnte sich in naher Zukunft ändern und sollte beobachtet werden.

Alle Methoden wurden in A2A v1.0 umbenannt: message/send heißt jetzt SendMessage, message/stream SendStreamingMessage, tasks/resubscribe SubscribeToTask, und ListTasks kam neu hinzu. REST-Pfade folgen nun dem AIP-Stil, etwa POST /tasks/{id}:cancel, und das Präfix /v1 entfiel. Das HTTP-Fehlerformat wechselte von application/problem+json nach RFC 9457 zu google.rpc.Status; reason wird in Großbuchstaben mit Unterstrichen geschrieben (z. B. TASK_NOT_FOUND), domain ist fest "a2a-protocol.org". Die Recherchenotizen deuten diese Überarbeitung so, dass A2A im Stil der Google-API-Designrichtlinien neu gestaltet wurde; dies ist eine Schlussfolgerung.

Die größte inkompatible Änderung am Datenmodell ist die Abflachung von Part. Die bisherigen TextPart, FilePart, DataPart und das Diskriminatorfeld kind wurden entfernt; ein Part enthält jetzt genau eines von text, raw (Bytes), url oder data, und der Typ ergibt sich daraus, welches Feld vorhanden ist, statt aus kind. mimeType wurde in mediaType umbenannt, file.fileWithUri in url. Laut Community-Berichten lesen viele Parser noch immer part.kind, was die häufigste Ursache für Interoperabilitätsfehler zwischen 0.3 und 1.0 ist. Die Agent Card ist nun um supportedInterfaces[] herum aufgebaut; jede Schnittstelle trägt eigene Werte für url, protocolBinding, protocolVersion und optional tenant. Clients wählen in Array-Reihenfolge und SOLLTEN (SHOULD) einen Fallback implementieren.

Die Versionsaushandlung hat eine kaum beachtete Voreinstellung: Ist der Header A2A-Version leer, gilt 0.3. Clients senden nur Major.Minor; ein Server ohne Unterstützung antwortet mit −32009 VersionNotSupportedError. Ein Agent kann in supportedInterfaces Schnittstellen mit unterschiedlichem protocolVersion aufführen, sodass 0.3 und 1.0 nebeneinander bestehen. Die offizielle Migration hat drei Phasen: erst beide Formate parsen, dann 1.0 ausgeben und 0.3 lesen, schließlich nur noch 1.0. Atlassian Forge und MuleSoft haben jeweils Migrationsleitfäden für 0.3→1.0 veröffentlicht – ein Zeichen, dass jemand die Kosten der inkompatiblen Änderungen tatsächlich trägt.

Die Task-Semantik enthält einige Details, die man erst bei vollständiger Lektüre der Spezifikation entdeckt. taskId wird immer vom Server erzeugt; bringt der Client eine contextId mit, darf der Agent sie nur annehmen oder ablehnen, aber keine eigene erzeugen; stimmen taskId und contextId nicht überein, MUSS der Agent ablehnen. Wer an einen Task in einem der vier Endzustände (COMPLETED, FAILED, CANCELED, REJECTED) eine weitere Nachricht sendet, erhält UnsupportedOperationError; um weiterzumachen, eröffnet man im selben Kontext einen neuen Task und verknüpft ihn über referenceTaskIds mit dem ursprünglichen. Die Zustandsmaschine kennt zwei „Unterbrechungs“-Zustände, TASK_STATE_INPUT_REQUIRED und TASK_STATE_AUTH_REQUIRED, und ein blockierendes SendMessage kehrt auch bei einem Unterbrechungszustand zurück.

Die Garantien für Streaming und Push sind schwächer, als die meisten annehmen. Das Flag final in TaskStatusUpdateEvent wurde in 1.0 entfernt; das Ende des Streams wird nun durch das „Schließen der Verbindung“ signalisiert. Ein Verbindungsabbruch mitten im Task sieht für den Client daher genauso aus wie ein abgeschlossener Task, und erst ein erneuter Aufruf von GetTask oder SubscribeToTask schafft Klarheit. Die Spezifikation kennt auch keinen Wiederaufsetzmechanismus über Event-IDs; das ist als v1.1-Thema #1986 gelistet. Push-Benachrichtigungen senden eine StreamResponse per HTTP POST an den Webhook des Clients, Content-Type application/a2a+json; die Spezifikation verlangt vom Agenten nur mindestens einen Zustellversuch wobei das Timeout etwa 10–30 Sekunden betragen SOLLTE, und der Empfänger SOLLTE idempotent verarbeiten und MUSS die taskId prüfen. Mit anderen Worten: Push ist „mindestens einmal, ohne Reihenfolgegarantie, mit unsignierter Payload“; dies ist eine aus der Spezifikation abgeleitete Schlussfolgerung. Auch die Idempotenz ist nur halb umgesetzt: SendMessage „KANN“ (MAY) über messageId deduplizieren, muss es aber nicht.

Bei zwei Angaben zu Datum und Anzahl widersprechen sich die Quellen. Zum Veröffentlichungsdatum von v1.0: Das CHANGELOG nennt 2026-03-12, ein Übersichtsartikel (arXiv:2507.10644 v4) Januar 2026, und die Pressemitteilung der Linux Foundation zum einjährigen Bestehen bezeichnet v1.0 nur als erste stabile Version, ohne Datum; dieser Artikel folgt dem CHANGELOG als Primärquelle. Zur Zahl der SDKs: Die Linux Foundation sprach im 2026-04 von 5 „produktionsreifen“ Sprachen, die offizielle A2A-Ankündigung listet 6 (Python, Go, Java, JS, .NET und Rust), wobei das ausführlich getestete Rust-SDK eine Community-Version ist.

Im vergangenen Jahr hieß es oft: „MCP hat jetzt Tasks, also braucht man A2A nicht mehr.“ Die tatsächliche Richtung der MCP-Revision 2026-07-28 ist jedoch genau umgekehrt. Die MCP-Revision 2025-11-25 führte zwar experimentelle Tasks ein (SEP-1686), um lang laufende Anfragen zu verfolgen, abzufragen und Ergebnisse später abzuholen, mit Zuständen (working, input_required, completed, failed, cancelled), die fast eins zu eins A2A entsprechen. Die Revision 2026-07-28 entfernte jedoch Sessions und den initialize-Handshake und machte MCP zustandslos (SEP-2567, SEP-2575), verschob Tasks aus dem Kern in die offizielle Erweiterung io.modelcontextprotocol/tasks (SEP-2663), ersetzte servergesteuerte Anfragen durch MRTR (InputRequiredResult plus beim erneuten Senden angehängte inputResponses) (SEP-2322) und erklärte Sampling, Roots und Logging für deprecated (SEP-2577).

Diese Änderungen bedeuten, dass die MCP-Maintainer bewusst den „agentischen“ Weg aufgegeben haben, bei dem sich der Server das LLM des Aufrufers zum Schlussfolgern ausleiht; dies ist eine Schlussfolgerung. Ein MCP-Server, der selbst schlussfolgern will, muss sein eigenes Modell mitbringen und ist dann faktisch ein undurchsichtiger Agent, der nur äußerlich wie ein Tool aussieht. Der Task von MCP behandelt „das spätere Abholen eines lang laufenden Tool-Aufrufs“, der Task von A2A „eine mehrstufige Zusammenarbeit, bei der beide Seiten Fragen stellen können“, dazu kommen Agent-Card-Erkennung, Skill-Deklarationen und Artefakt-Streaming. Auch in umgekehrter Richtung gibt es ein Fehlerszenario: Zwingt man deterministische Abfragen wie Preis- oder Steuersatzabfragen in den Lebenszyklus aus Task, Message und Artifact, steigen Latenz und Implementierungsaufwand, und das LLM des Aufrufers erhält kein feingranulares Tool-Schema; auch dies ist eine Schlussfolgerung. Die Recherchenotizen fanden keine dokumentierten Vorfälle, in denen „MCP für Agent-zu-Agent eingesetzt wurde und scheiterte“ oder „Tools in A2A verpackt wurden und scheiterten“.

Zur Verbreitung: Neben den GitHub-Topic-Zahlen zeigt ein nicht systematischer PyPI-Vergleich rund 10,9 Millionen Downloads für das A2A-SDK gegenüber rund 257 Millionen für das MCP-SDK. Sekundärquellen zufolge nutzt der UCP-Endpunkt von Shopify MCP als Transportschicht, d. h. gängige Commerce-Agenten docken über MCP an. Zu den Cloud-Plattformen: AWS AgentCore Runtime kann A2A-Server bereitstellen (JSON-RPC, POST /, Port 9000, OAuth 2.0 oder SigV4); die A2A-Unterstützung in Microsoft Foundry ging im Juni 2026 in die Public Preview; Google Agent Registry liest Well-known-Karten, die automatische Erkennung ist aber auf dasselbe Projekt beschränkt. Unter den großen Modellanbietern, die die Recherchenotizen abdecken, hat Anthropic derzeit keine native A2A-Unterstützung; das zugehörige Claude-Code-Issue #104852 wurde erst Ende Oktober 2026 eröffnet.

In der Praxis ist die Wahl einfach: Sollen KI-Assistenten Ihre deterministischen Funktionen aufrufen (Angebote, Steuersatzabfragen, Sendungsverfolgung), nutzen Sie MCP; erst wenn zwei Agenten, die jeweils selbst schlussfolgern und verschiedenen Organisationen angehören, mehrstufig zusammenarbeiten müssen, brauchen Sie A2A. Das öffentliche MCP von HowBridge gehört zur ersten Kategorie; wie man es anbindet, zeigt unser MCP-Tutorial zum Sammelversand.

Eine A2A Agent Card deklariert über securitySchemes eines von fünf Authentifizierungsverfahren: API Key, HTTP Auth, OAuth2, OIDC und mTLS. v1.0 entfernte die OAuth-Flows implicit und password, fügte Device Code hinzu und empfiehlt PKCE für alle Clients. Die Spezifikation verlangt von Servern „MUST authenticate every incoming request“, doch die Autorisierung ist implementation-specific, und Anmeldedaten müssen out-of-band beschafft werden; wenn ein Task in den Zustand AUTH_REQUIRED wechselt, hält die Spezifikation ausdrücklich fest: „Agents MUST NOT treat the state transition alone as authorization“. Abschnitt 13 „Sicherheitsaspekte“ erwähnt weder Prompt Injection noch Delegation oder Token Exchange noch OpenTelemetry und enthält keine eigene Anforderung zur Mandantentrennung. Eine Analyse von Semgrep aus der Zeit von v0.3 stellte fest, dass A2A „supports but does not enforce Agent Card signing“, dass Lebensdauer und Scope von Tokens nicht durch das Protokoll begrenzt sind und dass ein Task mehrere parallele Streams haben kann, sodass ein gestohlenes Session-Token den Stream des Opfers unbemerkt mithören kann.

Selbst eine signierte Agent Card lässt sich derzeit nicht garantiert SDK-übergreifend verifizieren. Die Spezifikation kanonisiert die Karte nach RFC 8785 (JCS) unter Ausschluss des Felds signatures und wendet dann JWS an; der protected header MUSS alg und kid enthalten. Issue #2122 (eröffnet am 2026-08-10, Stand 2026-10-31 noch offen) dokumentiert gemessene Abweichungen: a2a-python 1.1.2 und @a2a-js/sdk 1.0.1 erzeugen bei der Kanonisierung unterschiedliche Bytes. Python maskiert Nicht-ASCII-Zeichen als \uXXXX, sortiert nach Codepoint statt nach UTF-16-Einheiten und gibt Zahlen als 1e-06 aus, während ECMAScript 0.000001 ausgibt; die Spezifikation verlangt, dass REQUIRED-Felder auch mit Standardwert erscheinen, doch proto3 kennt kein Presence-Konzept, sodass description: "" und skills: [] verworfen werden; auch typ ist mehrdeutig. PR #2319 korrigierte die Beispiele der Spezifikation, aber die Ausgabe von a2a-go weicht weiterhin ab. Eine weitere Einschränkung: Eine gültige Signatur beweist nur, dass die Karte nicht manipuliert wurde, nicht aber die Identität des Ausstellers, und die Community weist darauf hin, dass die Spezifikation keinen Mechanismus hat, der eine Karte an die Laufzeitumgebung bindet, die den Aufruf tatsächlich ausführt.

Manche Angriffe funktionieren auch bei voll spezifikationskonformem Verhalten. A2ABreak (arXiv:2609.10871, v3 2026-10-24) extrahierte mit einem LLM aus der natürlichsprachlichen Spezifikation 37 Zustände, 76 Übergänge und 929 formale Aussagen und fand 11 neue Schwachstellen, die alle „keinen Implementierungsfehler erfordern und von einem spezifikationskonformen Gegner ausgenutzt werden können“, etwa clientübergreifende Context-Injection durch ungeschützte Context-Identifier, Identitätsverlust nach mehreren Sprüngen in einer Delegationskette und Agenten, die unbelegte Fähigkeiten behaupten. Eine Studie zu Namenskollisionen (arXiv:2609.27624) weist darauf hin, dass die Spezifikation name als „human-readable metadata, not as a stable identity“ einordnet und keine Kollisionsregeln definiert; bei 6 der 7 vom Autor untersuchten Open-Source-Implementierungen würden clientseitige Integrationen Anfragen an einen vom Angreifer kontrollierten Endpunkt senden, was der Autor als wiederkehrende Klasse von Implementierungsschwachstellen und nicht als allgemeine Protokollschwachstelle einstuft. Unit 42 von Palo Alto Networks zeigte mit Google ADK einen Proof of Concept für Session Smuggling: Ein bösartiger Agent entlockte mit „Rückfragen“ Systemanweisungen und brachte den Client dazu, buy_stock aufzurufen und ohne Autorisierung 10 Aktien zu kaufen; Unit 42 stellt klar, dass dies keine Protokollschwachstelle ist, jedes zustandsbehaftete Mehrrundenprotokoll betroffen sein kann und keine Ausnutzung in freier Wildbahn beobachtet wurde. Die Community meldete zudem, dass ein bösartiger Server Anweisungen in den Feldern description oder skills der Agent Card verstecken kann, die das Host-LLM dann als Anweisungen ausführt.

Auch die akademische Evidenz zu agentenübergreifenden Angriffen stützt die Sicht, dass „Vertrauen zwischen Agenten nicht vorausgesetzt werden darf“. Triedman et al. (COLM 2025) zeigten, dass bösartige Webinhalte den Kontrollfluss von Multi-Agenten-Systemen kapern können; mit GPT-4o gelang die Ausführung beliebigen Codes in 58–90 % der Versuche. Die begutachtete Übersichtsarbeit von Ferrag et al. in ICT Express (2026) verfolgt Angriffe von Prompt Injection bis zur Protokollebene und deckt MCP und A2A ab.

Die CVE-Nummern in der folgenden Tabelle sind exakt aus den Recherchenotizen übernommen. Die Notizen selbst vermerken, dass diese Nummern ungewöhnlich sind und einige Einträge nur in einer einzigen Datenbank auftauchen (so hat CVE-2026-90790 im Repo a2a-python kein zugehöriges GHSA und erscheint nur bei OpenCVE). Abfragen der Repo-Advisories für a2a-js, a2a-go und a2a-dotnet ergaben leere Ergebnisse, was jedoch an fehlenden Berechtigungen liegen kann und nicht zwingend bedeutet, dass es keine Schwachstellen gibt. Aus der Tabelle lassen sich drei Lehren ziehen; das Folgende ist Schlussfolgerung. Erstens: Die Agent Card ist vom Angreifer kontrollierbare Eingabe, bis hin zu Header-Namen, die die Gegenseite vorgeben kann. Zweitens: Die Spezifikation schreibt nur „SHOULD validate webhook URLs“, und SDKs in zwei Sprachen bekamen dadurch SSRF. Drittens: Die Spezifikation sagt „Autorisierung entscheidet die Implementierung“, und das beliebteste SDK, das für Java, autorisierte standardmäßig gar nicht; der Fix wurde zudem über eine Android-Plattformbesonderheit umgangen.

Außerhalb von A2A zerfällt das Problem der Agentenidentität in drei Schichten. Die erste ist die Workload-Identität und beantwortet „Welches Programm ist das?“: Die Autoren von draft-klrc-aiagent-auth kommen u. a. von Amazon, Zscaler, Ping Identity und OpenAI; der Entwurf wurde von der IETF-Arbeitsgruppe WIMSE übernommen und durch draft-ietf-wimse-aims ersetzt, und sein Ansatz ist, die bestehenden WIMSE- und OAuth-2.0-Familien wiederzuverwenden und „kein neues Protokoll zu erfinden“. Die zweite ist Autorisierung und Delegation und beantwortet „In wessen Auftrag, und was darf er?“: Das Beispiel von Ping Identity zeichnet mit dem act-Claim von RFC 8693 Token Exchange den gesamten Delegationspfad auf und beschränkt mit may_act den nächsten Sprung; RFC 8693 wurde jedoch ursprünglich für den Austausch zwischen Servern „nachdem die Einwilligung bereits erfolgt ist“ entworfen und deckt die Einwilligung eines Nutzers gegenüber einem bestimmten Agenten nicht nativ ab.

Die dritte Schicht ist die extern überprüfbare Identität und beantwortet „Warum sollte ein Fremder ihm vertrauen?“. Cloudflare Web Bot Auth signiert HTTP-Anfragen mit Ed25519 plus RFC 9421, doch Cloudflare prüft derzeit die Nonce nicht und verlässt sich gegen Replay-Angriffe vor allem auf eine kurze Gültigkeit von etwa 1 Minute; der Entwurf ANS v2 verifiziert Domains über ACME und kennt drei Stufen: Bronze, Silver (plus DANE) und Gold (plus SCITT-Transparenzlog). A2A berührt diese Schicht nur über die Kartensignatur, und die Signatur ist optional. Kommerzielle Produkte sind bereits am Markt: Okta Agent SSO ist seit 2026-08-24 allgemein verfügbar und nutzt ID-JAG; Microsoft Entra Agent ID unterstützt ID-JAG nicht nativ, und zum Datum der allgemeinen Verfügbarkeit machen die Quellen unterschiedliche Angaben (2026-04 oder 2026-05). Bei unternehmensübergreifendem A2A müssen beide Seiten daher wohl an ihren jeweiligen Grenzen Tokens umwandeln; dies ist eine Schlussfolgerung.

Auch Regierungen arbeiten daran, diese Lücke zu schließen. Am 2026-02-17 kündigte CAISI des US-amerikanischen NIST die AI Agent Standards Initiative an, deren drei Säulen industriegeführte Standards, communitygeführte Open-Source-Protokolle sowie Forschung zu Agentensicherheit und -identität sind; die Initiativseite verwendet jedoch nur allgemeine Begriffe wie „interoperable agent protocols“ und nennt weder A2A noch MCP. Das NIST-NCCoE-Projekt „Software and AI Agent Identity and Authorization“ veröffentlichte am 2026-09-29 eine Zusammenfassung der Stellungnahmen zu seinem Konzeptpapier, mit über 600 antwortenden Organisationen oder Einzelpersonen. Der NIST-Blogbeitrag „Design Tenets for Agent Identity Management Systems“ vom 2026-10-27 formuliert 10 Gestaltungsprinzipien, darunter: Agenten sollen eine eigene Identität haben, die mit dem Auftraggeber verknüpft ist, wobei sich die Rechte bei jeder Delegationsstufe verengen; minimale Rechte; kurzlebige und widerrufbare Autorisierung; risikobasiertes Eingreifen von Menschen; signierte Mandate, die den Handlungsrahmen festlegen; und manipulationssichere Aufzeichnungen. Es handelt sich um einen Blogbeitrag, nicht um einen formellen Standard.

Die akademische Forschung weist in dieselbe Richtung. South et al. schlagen vor, OAuth 2.0/OIDC um agentenspezifische Anmeldedaten zu erweitern und prüfbare Delegationsketten aufzubauen; eine Positionsfassung derselben Forschung erschien im ICML 2025 Position Paper Track. Chan et al. plädieren auf der FAccT 2024 für drei Arten von Maßnahmen – Agentenkennungen, Echtzeitüberwachung und Aktivitätsprotokolle –, um die Sichtbarkeit von Agenten zu erhöhen.

AP2 ist nicht mehr die Version, die man aus 2025 kennt. v0.2.0 baut den Mechanismus auf Checkout Mandate und Payment Mandate um, jeweils in eine offene (open) und eine geschlossene (closed) Stufe geteilt und mit SD-JWT umgesetzt; das offene Mandat speichert den öffentlichen Schlüssel des Agenten im cnf-Claim. Die wichtigste Neuerung ist der Human-Not-Present-Ablauf: Der Nutzer signiert zunächst auf einer vertrauenswürdigen Oberfläche mit seinem eigenen Schlüssel ein offenes Mandat und legt Bedingungen fest; später signiert der Agent mit dem Agentenschlüssel ein geschlossenes Mandat, und beide werden über sd_hash verknüpft. Händler oder Credential-Anbieter können unresolved_constraint zurückgeben und den Ablauf damit auf „Mensch anwesend“ zurückholen. Die Spezifikation empfiehlt Händlern außerdem, das Checkout-JWT mit nicht deterministischen Signaturen (ECDSA) statt mit Ed25519 zu signieren, um Rainbow-Table-Angriffe zu verhindern. Am wichtigsten: Die AP2-Spezifikation erklärt Streitbeilegung, Aufbewahrung und Abruf für out of scope und verspricht lediglich einen nicht abstreitbaren kryptografischen Audit-Trail. Die Recherchenotizen stellen zudem fest, dass die AP2-Spezifikation als Erweiterungsweg die Extension Points von UCP empfiehlt, während A2A im Haupttext der Spezifikation gar nicht behandelt wird; AP2 verschiebt sich damit von „einer A2A-Erweiterung“ hin zu „einer Sicherheitsschicht in Commerce-Protokollen“. Dies ist eine Schlussfolgerung.

Zahlungserweiterungen hängen sich über den Extension-Mechanismus von A2A selbst an: Sie werden in AgentCapabilities als AgentExtension (uri, description, required, params) deklariert, und der Client fordert die Aktivierung über den Header A2A-Extensions an. Erweiterungen dürfen keine Kerndatenstrukturen ändern und keine enum-Werte hinzufügen und nur über metadata arbeiten; inkompatible Änderungen erfordern eine neue URI, und bei einer nicht unterstützten Version gilt „MUST NOT fall back“. a2a-x402 (spec v0.1) ist eine solche Erweiterung: Der Händler sendet payment-required, der Client signiert und antwortet mit payment-submitted, und nach der On-Chain-Abrechnung sendet der Händler payment-completed.

Die Transaktionszahlen von x402 stammen überwiegend aus künstlich erzeugtem Volumen. Chainalysis zählt bis zum ersten Quartal 2026 kumuliert über 100 Millionen x402-Transaktionen auf der Base-Chain, doch der Anstieg im vierten Quartal 2025 war „überwiegend durch Meme-Coin-Farming getrieben“, und die wöchentliche Bindungsrate fiel von 87 % auf 5 %. Coinbase gab Ende April 2026 rund 165 Millionen Transaktionen und kumuliert rund 50 Millionen US-Dollar an; dies ist eine Herstellerangabe. Artemis schätzt, dass über 95 % Protokollsignale oder Tests sind, und eine weitere Tracking-Website schätzt das echte Handelsvolumen auf etwa 28.000 US-Dollar pro Tag.

Kartennetzwerke und Plattformen verfahren in der Praxis nach dem Prinzip „mehrere Protokolle akzeptieren, starke Authentifizierung mit anwesendem Menschen als Sicherheitsventil“. Im März 2026 stellte OpenAI Instant Checkout in ChatGPT wieder auf ein Modell mit Händler-Apps um; ein Sprecher sagte: „Instant Checkout is moving to Apps“. Am 2026-07-02 gab Visa bekannt, dass Agenten in Europa bereits echte Käufe abgeschlossen haben, mit über 30 Partner-Kartenausgebern; alle Transaktionen nutzten Payment Passkeys, um die starke Kundenauthentifizierung (SCA) zu erfüllen. Der Haftungsrahmen ist weiterhin leer: Chargebacks911 warnt, dass die Infrastruktur für Streitfälle und Haftung „largely unaddressed“ sei; Taylor Wessing kommt zu dem Ergebnis, dass ein Kauf durch einen Agenten, der die vom Kunden festgelegten Bedingungen überschreitet, im EU-Rahmen grundsätzlich als nicht autorisierte Transaktion gilt; Ant International, Visa und Mastercard begannen erst am 2026-09-10, einen interoperablen Know-Your-Agent-Rahmen zu erkunden. PSD3/PSR der EU sind bislang nur bis zum Standpunkt des Rates in erster Lesung vom 2026-10-29 gelangt und noch nicht im Amtsblatt (Official Journal) veröffentlicht; eine Stichwortsuche in der Begründung des Rates zur PSR findet keine Bestimmungen zu KI oder autonomen Agenten. Auch das US-amerikanische CFPB hat keine Leitlinien zu Agentenzahlungen.

Die akademische Forschung zeigt einen weiteren blinden Fleck. Debi et al. (IEEE IMNS 2026) testeten einen AP2-Shopping-Agenten im Red-Teaming und zeigten, dass indirekte und direkte Prompt Injection die Produktreihenfolge manipulieren und sensible Nutzerdaten abgreifen können – ein signiertes Mandat schützt also nicht den Denkprozess vor der Signatur. Jiang et al. (arXiv:2609.00060) analysierten x402, MPP, ACP und AP2 formal mit Tamarin und zeigten die Sicherheitsabhängigkeiten auf, die entstehen, wenn Absicht, delegierte Befugnisse und Abrechnung auf mehrere Parteien verteilt sind. Die Agentifizierung in der Logistik läuft derzeit über MCP: Der MCP-Server von Flexport ermöglicht es den KI-Assistenten von Kunden, Frachtraum zu vereinbarten Tarifen zu buchen und eine Booking-ID zu erhalten. Die Recherchenotizen fanden kein Beispiel, in dem Frachtkosten über AP2 oder x402 abgerechnet wurden.

Laut der Pressemitteilung der Linux Foundation zum einjährigen Bestehen vom 2026-04-09 hat A2A über 150 unterstützende Organisationen und Produktiveinsätze in Lieferkette, Finanzwesen, Versicherung und IT-Betrieb; dies ist eine Herstellerangabe: Die Mitteilung nennt keine Nutzer und liefert weder Prozess- noch Erfolgskennzahlen. Die am häufigsten zitierten Beispiele, ein Artikel zum Microsoft Agent Framework für .NET und das Google-Codelab zum Purchasing Concierge, sind Codebeispiele, keine Einsatzberichte. Tyson Foods wird oft als A2A-Lieferkettenfall beworben, doch apis.io bewertet seine A2A Agent Card mit 0/8, und gegenüber Handelspartnern setzt das Unternehmen weiterhin auf EDI und APIs.

Der direkteste Gegenbeweis sind Tests. Im April 2026 zog ein Autor aus einer öffentlichen Registry eine Stichprobe von 50 Agenten, die A2A-Unterstützung angaben; nur etwa 0–2 lieferten unter dem Well-known-Pfad eine gültige Karte, und 0 beantworteten einen Task korrekt. Derselbe Autor schickte am 2026-09-09 24 Anfragen an 12 Organisationen und am 2026-10-27 36 Anfragen an 18 Organisationen und erhielt beide Male 0 Karten. Die Stichproben wählte der Autor selbst, es handelt sich also nicht um eine Vollerhebung, doch sie weisen in dieselbe Richtung. Was tatsächlich läuft, ist Interoperabilität innerhalb einer Cloud-Plattform: AWS AgentCore, Microsoft Foundry und Google Agent Registry.

Auch die Evidenz zu Multi-Agenten-Architekturen selbst spricht gegen organisationsübergreifendes A2A. MAST (NeurIPS 2025 Datasets & Benchmarks Track) analysierte 1.642 Ausführungsspuren und identifizierte 14 Fehlermodi in drei Kategorien: Systemdesign, Fehlausrichtung zwischen Agenten und Aufgabenverifikation; die 7 untersuchten modernsten Open-Source-Multi-Agenten-Systeme hatten Fehlerquoten zwischen 41 % und 86,7 % (die Autoren betonen, dass verschiedene Benchmarks nicht direkt vergleichbar sind). „Towards a Science of Scaling Agent Systems“ von Autoren u. a. von Google Research und dem MIT testete in v1/v2 und der Google-Blogfassung 180 Konfigurationen: Unabhängige Multi-Agenten-Setups verstärkten Fehler um das 17,2-Fache, zentral koordinierte um das 4,4-Fache, und bei sequenziellen Denkaufgaben verschlechterten sich alle Multi-Agenten-Varianten um 39–70 %; die v3 vom 2026-04-08 erweiterte auf 260 Konfigurationen und 6 Benchmarks und hielt an den Befunden 17,2-fach und 4,4-fach fest. Der Engineering-Blog von Anthropic (kein begutachteter Fachartikel) berichtet, dass sein Multi-Agenten-Recherchesystem den Einzelagenten Claude Opus 4 um 90,2 % übertraf, aber etwa 15-mal so viele Tokens wie ein normaler Chat verbrauchte, und nennt Bereiche, „in denen alle Agenten denselben Kontext teilen müssen oder viele Abhängigkeiten zwischen Agenten bestehen“, als ungeeignet. Organisationsübergreifendes A2A vereint genau diese ungünstigen Bedingungen: Beide Seiten teilen keinen Kontext, es gibt keinen gemeinsamen Prüfer, und Geschäftsprozesse (Angebot→Bestellung→Zahlung→Versand) sind sequenziell; dies ist eine Schlussfolgerung.

Die technischen Lücken sind größer als die Lücken in der Spezifikation. Bei der Delegation an den nächsten Agenten reißen Traces ab: Das Python-SDK erzeugt nur lokale Spans, und es gibt keinen Standardweg, W3C Trace Context zwischen Agenten weiterzugeben (Issue #2103). Das Community-SDK für Rust meldete 7 TCK-Fehler, die sich beim Abgleich als Mängel der Testsuite selbst herausstellten; derselbe Bericht besagt, dass die SDKs für JS, Go und Java auf beiden Bindings 21/21 bestanden. Auch der Agentenverkehr auf Verbraucherseite ist noch gering: HUMAN Security zählte 2025 ein Wachstum des Agentenverkehrs von 7.851 % gegenüber dem Vorjahr, aber nur 2,3 % davon fanden auf Checkout-Seiten statt; eine Sekundärquelle, die Daten von Cloudflare Radar aus dem August 2026 zitiert, beziffert KI-Bots auf etwa 7 % der HTML-Anfragen, wovon „Handeln in Echtzeit im Auftrag von Nutzern“ nur 5,8 % ausmacht; multipliziert ergibt das rund 0,4 % – diese Rechnung ist eine Schlussfolgerung und wurde noch nicht mit den Rohdaten bestätigt. Akamai warnt, dass E-Commerce-Websites über 90 % der KI-Bots lediglich überwachen, während betrügerische Agentenaktivität zunimmt. Die Recherchenotizen fanden keinen Beleg dafür, dass persönliche Agenten wie ChatGPT, Gemini oder Claude über A2A gewöhnliche Unternehmensagenten aufrufen; das ist allerdings nur ein fehlender Beleg, keine offizielle Bestätigung.

Befragungen durch Regierungen und internationale Organisationen zeigen, dass der Bedarf echt ist. Die OECD Artificial Intelligence Papers No. 65 halten auf Seite 16 fest, dass die befragten Praktiker offene Protokolle bevorzugen und Agent-zu-Agent-Kommunikationsprotokolle wie A2A als wichtigen Treiber der Multi-Agenten-Koordination sehen, zugleich aber eine Bindung an das Ökosystem eines einzelnen Anbieters befürchten.

Taiwan: Das Grundlagengesetz über künstliche Intelligenz umfasst 20 Artikel. Artikel 3 definiert künstliche Intelligenz als „System mit der Fähigkeit zum autonomen Betrieb“, was KI-Agenten einschließen kann, doch das Wort „Agent“ kommt im Gesetz nicht vor; Artikel 4 nennt sieben Grundsätze, darunter menschliche Autonomie und Aufsicht, Transparenz und Erklärbarkeit sowie Rechenschaftspflicht; nach Artikel 16 treibt das Ministerium für Digitale Angelegenheiten ein mit internationalen Rahmen anschlussfähiges Risikoklassifizierungsrahmenwerk voran; Artikel 17 verpflichtet die Regierung, Haftungszuordnung und Zurechnungsvoraussetzungen für Hochrisiko-KI festzulegen und Abhilfe-, Entschädigungs- oder Versicherungsmechanismen zu schaffen; Artikel 18 verlangt, dass die Behörden die betreffenden Vorschriften binnen zwei Jahren nach Inkrafttreten anpassen. Gestützt auf Artikel 16 veröffentlichte das Ministerium für Digitale Angelegenheiten am 115-07-07 (Minguo-Kalender) das Risikoklassifizierungsrahmenwerk für KI v1.0 (Schreiben Digitalstrategie Nr. 1150015933, mit sofortiger Wirkung), in dem der Risikotyp B6 „Handlungen autonomer KI-Agenten außerhalb ihrer Autorisierung“ festhält: „Multi-Agenten-Systeme können durch gegenseitiges Auslösen der Agenten eher Kettenreaktionen hervorrufen, die weder Entwickler noch Nutzer vorhergesehen haben, sodass Menschen nur schwer rechtzeitig eingreifen und korrigieren können.“ Die per Schreiben vom 115-05-29 erlassene Leitlinie des Ministeriums für Gesundheit und Soziales zu generativer KI in medizinischen Einrichtungen stellt ausdrücklich fest, dass KI-Agentensysteme „vorerst nicht in den Anwendungsbereich dieser Leitlinie fallen“.

Auch bestehendes taiwanisches Recht gilt für Agentenszenarien. Artikel 4 des Gesetzes zum Schutz personenbezogener Daten bestimmt, dass, wer im Auftrag personenbezogene Daten erhebt, verarbeitet oder nutzt, im Anwendungsbereich des Gesetzes als die beauftragende Stelle gilt; die Übergabe personenbezogener Daten an einen Agenten entbindet also nicht von der Haftung, nur weil „eine KI es tut“. Artikel 21 regelt Beschränkungen internationaler Übermittlungen. Zu beachten ist, dass mehrere am 114-11-11 geänderte Artikel (darunter die Neufassung von Artikel 21 und der neu eingefügte Artikel 20-1) verkündet, aber noch nicht in Kraft sind; das Inkrafttreten bestimmt der Exekutiv-Yuan. Das Gesetz über elektronische Signaturen erwähnt weder KI noch Agenten; ob eine von einem Agenten stellvertretend geleistete Signatur als eigene Signatur der Person vermutet werden kann, ist gesetzlich nicht geregelt und lässt sich in diesem Artikel nicht belegen.

China: Mit der Bekanntmachung über nationale Standards Nr. 22 von 2026 genehmigten und veröffentlichten die State Administration for Market Regulation und die Standardization Administration of China am 2026-05-22 die Reihe GB/Z 185.1–185.7-2026 „Künstliche Intelligenz – Vernetzung intelligenter Agenten“, insgesamt 7 technische Leitdokumente (Gesamtarchitektur, Identitätscode, Identitätsverwaltung, Agentenbeschreibung, Agentenerkennung, Agenteninteraktion und Tool-Aufruf durch Agenten). Die National Public Service Platform for Standards Information führt ihren Status als „gültig“, die Volltexte wurden am 2026-06-18 veröffentlicht, und die SAMR hielt am 2026-06-26 eine eigene Pressekonferenz ab. Der in den offiziellen Dokumenten verwendete Protokollname lautet AIP (Agent Interconnection Protocol); keine der gefundenen offiziellen Seiten erwähnt A2A oder MCP, und ob beide kompatibel sind, ist nicht belegt. Die am 2026-05-08 gemeinsam von der Cyberspace Administration of China, der National Development and Reform Commission und dem Ministerium für Industrie und Informationstechnologie herausgegebenen Durchführungsleitlinien zur normgerechten Anwendung und innovativen Entwicklung intelligenter Agenten bündeln die Förderung von AIP, eine Registrierungsplattform für Agenten und die digitale Identität von Agenten zu einem Paket und verlangen, dass „von Agenten ausgeführte Handlungen den vom Nutzer autorisierten Rahmen nicht überschreiten dürfen“. Dieser Weg unterscheidet sich vom Ansatz der A2A-Community, „keine offizielle Registry“ bereitzustellen.

EU: Der AI Act (Verordnung (EU) 2024/1689) trat am 2024-08-01 in Kraft; die Pflichten für KI-Modelle mit allgemeinem Verwendungszweck gelten seit 2025-08-02, die allgemeine Anwendung und die Transparenzpflichten ab 2026-08-02. Die Hochrisikopflichten wurden durch die Verordnung (EU) 2026/1744 (veröffentlicht im Amtsblatt am 2026-07-24) verschoben: Anhang III auf 2027-12-02, Anhang I auf 2028-08-02. Für PSD3 und PSR hat der Rat am 2026-10-29 seinen Standpunkt in erster Lesung angenommen; die zweite Lesung im Europäischen Parlament steht noch aus, und eine Veröffentlichung im Amtsblatt ist nicht erfolgt.

USA, Singapur, Vereinigtes Königreich: CISA, NSA und weitere Five-Eyes-Behörden veröffentlichten am 2026-04-30/05-01 „Careful Adoption of Agentic AI Services“ und empfehlen, Zugriffsrechte zu beschränken und mit risikoarmen, nicht sensiblen Anwendungsfällen zu beginnen. Das US-amerikanische CFPB hat keine Leitlinien zu Agentenzahlungen; sein entsprechender Vorschlag für eine Auslegungsregel aus 2025 wurde am 2025-05-15 zurückgezogen. Das Model AI Governance Framework for Agentic AI v1.5 der singapurischen IMDA (veröffentlicht 2026-05-20, aktualisiert 06-05) nennt in Abschnitt 1.1.1 ausdrücklich A2A für die Kommunikation zwischen Agenten und MCP für die Kommunikation zwischen Agenten und Tools und benennt rekursive Delegation und organisationsübergreifende Identität als derzeitige Lücken. Die am 2026-03-09 veröffentlichte (am 10-30 aktualisierte) Leitlinie der britischen CMA hält fest: „if an AI agent you use does something illegal, you are responsible“ – Unternehmen haften also für rechtswidrige Handlungen der von ihnen eingesetzten Agenten. Die öffentliche Konsultation (Call for Evidence) des britischen ICO zu agentischer KI endet am 2026-11-20.

Issue #1942 fasste 41 Issues zu acht Themen für v1.1 zusammen; ein taskübergreifendes Agentengedächtnis (#893) liegt außerhalb des verfolgten Umfangs. Mehr über die Richtung als die Themenliste verraten die meistkommentierten Issues: #1672 Identitätsprüfung von Agenten in der Agent Card (rund 658 Kommentare), #1829 Nachrichtensignatur mit Ed25519 plus RFC 9421, #2028 Actor-Chain-Delegation, #2121 Weitergabe von Kosten und Budget sowie #1815 HTTP 402 zur Anzeige von „Zahlung erforderlich“. All dies sind Vertrauens- und Geschäftsfragen; zusammen mit dem neu geschaffenen Governance-Prozess für Erweiterungen schätzen die Recherchenotizen, dass sie eher als Erweiterungen denn als Änderungen der Kernspezifikation kommen werden. Dies ist eine Schlussfolgerung.

Auf die Frage „Wie findet ein persönlicher Agent den Agenten eines Unternehmens?“ gibt es derzeit keine eingesetzte offene Antwort. Die offizielle A2A-Dokumentation stellt ausdrücklich klar, dass kuratierte Registries nicht zum Umfang von A2A gehören; der Agent-Registry-Vorschlag in Discussion #741 zieht sich seit Langem hin, und Gutachter stellen seine Prämisse infrage, dass „Anbieter ihre Registry-Einträge selbst verwalten“. Für das Auffinden von Agenten anhand einer Domain gibt es bei der IETF vier konkurrierende Individual-Drafts: DNS-AID (ein SVCB-Eintrag, der auf /.well-known/agent-card.json verweist), AID (Abfrage eines _agent-TXT-Eintrags), ADP und DAN; keiner wurde bisher von einer Arbeitsgruppe übernommen, und ein Landscape-Draft vom Juli 2026 weist zudem darauf hin, dass der Namensraum koordiniert werden muss. Auf MCP-Seite ist die MCP Registry seit September 2025 bis heute im Vorschaustatus.

Auch für organisationsübergreifende Prüfung und Haftung fehlt ein Rahmen. Die A2A-Spezifikation enthält nur Anforderungen auf SHOULD-Ebene zur Protokollierung fehlgeschlagener Authentifizierungen und zur Ratenbegrenzung, und zum Stabilitätsstatus der OpenTelemetry-GenAI-Semantikkonventionen widersprechen sich die Quellen. Mit den heutigen Werkzeugen ist die kleinste aufbewahrbare Prüfeinheit ungefähr: taskId und contextId der eigenen Seite, der Fingerabdruck der Agent-Card-Signatur der Gegenseite und die act-Delegationskette des von der Gegenseite vorgelegten Tokens, jeweils von beiden Parteien aufbewahrt und später abgeglichen; dies ist eine Schlussfolgerung. Die Recherchenotizen fanden zudem keine empirische Forschung zu Denial-of-Wallet-Angriffen, die darauf abzielen, „das LLM-Budget der Gegenseite zu erschöpfen“.

A2A ähnelt heute stark dem frühen HTTP: Das Format ist standardisiert, die Vertrauensschicht muss jede Seite selbst ergänzen; der Unterschied ist, dass die aufgerufene Seite diesmal selbst schlussfolgert und sich sogar von der Gegenseite überzeugen lassen kann. Der Engpass liegt daher nicht in der Technik, sondern in der Frage, „wer für das Handeln des Agenten verantwortlich ist“, und diese Frage ist derzeit auf die IETF (Identität), die FIDO Alliance (Zahlungsabsicht), die Kartennetzwerke (Streitfälle) und nationale Aufsichtsbehörden verteilt – außerhalb der Reichweite des A2A-TSC. Daraus schließen wir, dass die wahrscheinlichste Form unternehmensübergreifender Agenten-Interoperabilität in den nächsten Jahren „eine A2A-Hülle um deterministische Tool-Aufrufe“ sein wird: Die aufgerufene Seite wirkt nach außen wie ein Agent, ist innen aber eine API, und echtes Schlussfolgern findet nur innerhalb der eigenen Vertrauensgrenze statt.

Die Leitlinien der Regierungen weisen in dieselbe Richtung. CISA, NSA und weitere Five-Eyes-Behörden empfehlen, mit risikoarmen, nicht sensiblen Anwendungsfällen zu beginnen und Zugriffsrechte zu beschränken; der IMDA-Rahmen Singapurs macht „Menschen substanziell verantwortlich halten“ und technische Kontrollen zu Kernbereichen; das taiwanische Ministerium für Digitale Angelegenheiten führt Kettenreaktionen durch sich gegenseitig auslösende Agenten als Risiko B6; und die britische CMA stellt klar, dass Unternehmen für rechtswidrige Handlungen der von ihnen eingesetzten Agenten haften.

Die folgende Tabelle stuft Einführungsoptionen für gewöhnliche Unternehmen nach Stärke der Belege ein. „Umsetzen“ bedeutet geringes Risiko und klaren Nutzen nach heutiger Beweislage; „Optional“ bedeutet geringe Kosten, aber keine gemessenen Fälle; „Zurückstellen“ und „Nicht umsetzen“ sind jeweils begründet und werden neu bewertet, sobald Auslösebedingungen eintreten.

Die Kernabfragen im grenzüberschreitenden E-Commerce und in der Logistik – Was kostet der Versand, wie hoch sind die Steuern, welche Zolltarifnummer und welche Einfuhrbestimmungen gelten für dieses Produkt? – sind von vornherein deterministische Berechnungen und damit genau die Art von Dienst, die externe Agenten am dringendsten brauchen und bei der sie am wenigsten Fehler machen. Laut dem Engineering-Blog von Anthropic verkürzte allein das Umschreiben von Tool-Beschreibungen die Bearbeitungszeit nachfolgender Agenten um 40 %; die Rückverlagerung von Instant Checkout zu Händler-Apps durch OpenAI zeigt, dass Transaktionen letztlich in den eigenen Ablauf des Händlers zurückkehren. Die Reihenfolge der Vorbereitung sollte daher lauten: zuerst Webseiten und strukturierte Daten lesbar machen, dann deterministische Tools als MCP bereitstellen, in Tool-Antworten Fortsetzungs-URLs mitliefern, die Transaktionen in den eigenen Ablauf zurückführen, und erst zuletzt einen A2A-Platzhalter erwägen.

Eine A2A-Platzhalterkarte bedeutet: unter /.well-known/agent-card.json eine Karte veröffentlichen, deren Skills auf bestehende deterministische Tools wie Angebote, Steuern und Prozessinformationen verweisen und hinter der direkt Programme aufgerufen werden, ohne dass ein LLM läuft. Dieser Ansatz ist kostengünstig und hat „Optionswert“, doch es gibt derzeit keinen gemessenen Fall, in dem ein kleines oder mittleres Unternehmen dadurch Traffic oder Umsatz gewonnen hätte; dies ist eine Schlussfolgerung. Wer tatsächlich einen A2A-Endpunkt öffnet, sollte mindestens: nur schreibgeschützte Skills anbieten, keinem Feld der Karte der Gegenseite vertrauen, private IPs in Push-URLs ablehnen und taskId, contextId, Identität des Aufrufers und traceparent protokollieren.

Was HowBridge heute tut (alles auf der HowBridge-Entwicklerseite überprüfbar): HowBridge bietet ein öffentliches MCP ohne API-Schlüssel und ohne OAuth (https://0523.tw/mcp/public) mit 8 schreibgeschützten, idempotenten Tools. Sie umfassen eine Vorstellung der Marke und Leistungen von HowBridge, die Schätzung der Sammelversandkosten von China nach Taiwan (See-Express/Luftfracht), die Schätzung taiwanischer Einfuhrabgaben, CCC-Zolltarifkandidaten anhand des Produktnamens, CCC-Zollsätze und Einfuhrbestimmungen, Übergrößenzuschläge für die Zustellung in Taiwan sowie den Ablauf des Sammelversands und die Regeln der vereinfachten Anmeldung; das Limit liegt bei 120 Anfragen pro Minute und IP, und das MCP ist in der offiziellen MCP Registry eingetragen (Name tw.0523/lucky-public). Antworten der Versandkostenschätzung enthalten eine Fortsetzungs-URL (continue_url), über die Nutzer auf der Website weitermachen können. Das Mitglieder-MCP (https://0523.tw/mcp) nutzt OAuth-2.1-Autorisierung und bietet 6 schreibgeschützte Tools, die nur die Rechnungen, Pakete, Voranmeldungen, Steuerbescheide und Einfuhranmeldungen des autorisierten Mitglieds selbst lesen können, standardmäßig mit 60 Anfragen pro Minute und 5.000 pro Tag. Die derzeit auf der HowBridge-Entwicklerseite aufgeführten Zugänge sind die Mitgliederdaten-API, das Mitglieder-MCP und das öffentliche MCP; einen A2A-Endpunkt gibt es nicht, und dieser Artikel bedeutet nicht, dass HowBridge A2A bereits unterstützt.

Wenn Sie sich von einem KI-Assistenten die Kosten für einen Versand von China nach Taiwan schätzen lassen möchten, können Sie direkt die Webversionen des Versandkostenrechners, des Einfuhrzollrechners und der Zolltarifsuche nutzen; die Tools und das öffentliche MCP verwenden dieselbe Berechnungslogik. Die Schätzungen dienen nur als Orientierung: Maßgeblich für die Versandkosten ist die Rechnung nach dem Vermessen beim Wareneingang im Lager, für die Steuern die Festsetzung durch den Zoll.