Leitfrage und Entscheidungsgrenze

Welche MCP-Muster sind mit heutigen Protokoll- und Systemfähigkeiten robust betreibbar, und welche hängen von experimentellen Funktionen oder unbeherrschten Fachrisiken ab?

Der Atlas trennt heute robuste Muster von experimentellen oder besonders risikoreichen Szenarien.

Architektur und Verantwortlichkeiten

Die Machbarkeit wird in vier Stufen geprüft: Kontext lesen, Entscheidung vorbereiten, reversible Aktion ausführen und wirtschaftlich verbindliche Transaktion steuern. MCP standardisiert Discovery und Aufruf; es liefert weder aktuelle Verfügbarkeit noch Buchungsgarantien. Diese kommen aus den zuständigen Travel-Systemen. Jede höhere Stufe erweitert deshalb nicht nur den Toolumfang, sondern auch Identität, Zustimmung, Audit, Idempotenz und Wiederanlauf.

Analytische Methode

Für jedes Szenario werden erforderliche MCP-Capabilities, Clientunterstützung, Backendreife, Datenqualität, Latenzbudget und Rückabwicklung dokumentiert. Ein Feature gilt nicht als verfügbar, weil es in einer Draft-Spezifikation oder einem SDK auftaucht. Maßgeblich sind ausgehandelte Capability, getestete Clientversion und reproduzierbares Verhalten der konkreten Serverversion.

  • Informationszugriff
  • Recherche und Vergleich
  • vorbereitende Prozessschritte
  • verbindliche Transaktionen
  • mehrstufige agentische Abläufe

Travel-Fallstudie

Verfügbarkeiten abfragen ist meist leichter beherrschbar als eine Buchung; Zahlung, Storno und Erstattung erfordern zusätzliche fachliche Zustände und Kontrollen.

Das Beispiel gilt erst dann als belastbar, wenn Quellen, Zustände, Rechte und Fehlerpfade genauso konkret dokumentiert sind wie der gewünschte Normalfall.

Typische Fehlkonstruktionen

Typischer Machbarkeitsfehler ist die Gleichsetzung von syntaktisch erfolgreichem tools/call mit fachlich erfolgreicher Reiseoperation. Ebenso falsch ist es, eine Registry-Listung als Interoperabilitäts- oder Sicherheitsnachweis zu behandeln. Bei Remote-Servern können zusätzlich Autorisierung, Rate Limits, Datenresidenz oder fehlende Sandboxzugänge den realen Einsatz verhindern.

Erforderliche Evidenz

Robust bedeutet: definierter Vertrag, kontrollierte Identität, verlässliche Quelle, strukturierter Fehler, beobachtbarer Zustand und sicherer Abbruch. Experimentell bedeutet nicht wertlos, aber es verlangt Kapselung und einen alternativen Prozess. Nicht prüfbar bedeutet, dass eine Behauptung bis zum Nachweis nicht als Portalwissen veröffentlicht wird.

Messgrößen und Abnahmekriterien

Bewertet werden technische Erfolgsquote, fachliche Erfolgsquote, Aktualität, Anteil kontrolliert behandelter Ausnahmen, Wiederholbarkeit, Mean Time to Recovery und notwendige menschliche Eingriffe. Die Reifestufe wird durch das schwächste kritische Glied begrenzt.

Ergebnis und weiterführende Analyse

Jedes Szenario erhält eine Reifestufe, technische Voraussetzungen, Grenzen und ein nachvollziehbares Risikoprofil.

Primärquellen und wissenschaftliche Einordnung

Die Darstellung folgt der versionierten MCP-Spezifikation. Normative Anforderungen werden von Architektur- und Betriebsempfehlungen getrennt; experimentelle Funktionen sind entsprechend gekennzeichnet.