Leitfrage und Entscheidungsgrenze

Welche klar begrenzte Nutzeraufgabe wird durch MCP besser lösbar als durch eine direkte API-Integration, einen festen Workflow oder eine gewöhnliche Suchoberfläche?

Anwendungsfälle werden nicht als Werbeversprechen, sondern als überprüfbare Prozessmuster dargestellt.

Architektur und Verantwortlichkeiten

Ein belastbarer Use Case benennt Host, Clientbeziehungen, MCP-Server, Systems of Record und Trust Boundaries. Für eine Umbuchung können ein Order-Server, ein Offer-Server und ein Profildienst beteiligt sein. Der Host darf deren Ergebnisse nicht zu einem vermeintlich atomaren Vorgang verschmelzen: bestehende Order, neues Änderungsangebot, Zahlung und Lieferantenbestätigung bleiben getrennte Zustände mit jeweils eigener Autorität.

Analytische Methode

Die Analyse beginnt mit einer messbaren Nutzeraufgabe, nicht mit einem Server. Erfasst werden Auslöser, Eingaben, Varianten, beteiligte Rollen, Datenklassen, heutige Durchlaufzeit und Fehler. Danach wird jeder Prozessschritt als Lesen, Berechnen, Vorschlagen oder verbindliches Schreiben klassifiziert. Nur Schritte, die ein Modell sinnvoll auswählen oder mit Kontext unterstützen soll, sind Kandidaten für MCP; deterministische Massendatenflüsse bleiben häufig direkte Integrationen.

  • Nutzeraufgabe und Ausgangsproblem
  • beteiligte Systeme und Daten
  • benötigte MCP-Capabilities
  • Risiko, Zustimmung und Audit
  • messbare Erfolgskriterien

Travel-Fallstudie

Ein Serviceassistent liest Buchungsstatus und Tarifregeln aus getrennten Quellen, darf eine Umbuchung aber erst nach Preisrevalidierung und expliziter Zustimmung ausführen.

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

Unbrauchbare Use Cases versprechen eine durchgängige autonome Reiseplanung, ohne Offer-Gültigkeit, Lieferantenausfälle, Teilbuchungen, Rechte oder Kompensation zu modellieren. Ein erfolgreicher Demo-Pfad sagt nichts über Doppelaufrufe, abgelaufene Preise, unvollständige Reisendenangaben oder fehlende Supplier Confirmation aus. Diese Fälle gehören in den fachlichen Entwurf, bevor Toolnamen festgelegt werden.

Erforderliche Evidenz

Ein veröffentlichungsfähiger Use Case enthält Prozessdiagramm, Capability-Verträge, Datenherkunft, Freigabepunkte, Zustandsmodell, Negativtests und eine Baseline. Aussagen wie „schneller“ oder „personalisierter“ gelten erst als belegt, wenn Versuchsdesign, Nutzergruppe und Messgröße genannt sind.

Messgrößen und Abnahmekriterien

Geeignete Kennzahlen sind Time-to-Resolution, Anteil korrekt revalidierter Offers, notwendige manuelle Übergaben, fachliche Korrekturen, Abbruchquote, unzulässige Toolversuche und Kosten pro gelöstem Vorgang. Modellbewertung allein reicht nicht; entscheidend ist der autoritative Endzustand im Fachsystem.

Ergebnis und weiterführende Analyse

Eine vergleichbare Use-Case-Karte zeigt, wo MCP Mehrwert schaffen kann und welche Voraussetzungen fehlen.

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.