Leitfrage und Entscheidungsgrenze

Wie wird aus einer Nutzerabsicht ein kleiner, semantisch eindeutiger und sicher autorisierbarer Capability-Vertrag?

Der Designer übersetzt Nutzerabsichten in kleine, testbare Capability-Verträge statt technische API-Endpunkte ungefiltert zu spiegeln.

Architektur und Verantwortlichkeiten

Ein Tool liegt an der Grenze zwischen modellgesteuerter Auswahl und deterministischer Fachlogik. Der Host entscheidet über Sichtbarkeit und Freigabe; der Server validiert Schema, Identität, Objektzugriff und Invarianten; das Backend bleibt für fachliche Wahrheit verantwortlich. Resources und Prompts folgen anderen Kontrollmodellen und dürfen nicht als Ersatz für schlecht geschnittene Tools dienen.

Analytische Methode

Der Entwurf beginnt mit Verb, Fachobjekt und Wirkung. Danach folgen inputSchema, optionales outputSchema, Vorbedingungen, idempotente Identifikation, Fehlerklassen, Seiteneffekt, Scope, Objektberechtigung und Auditfelder. JSON Schema 2020-12 prüft Struktur, nicht Buchbarkeit oder fachliche Wahrheit. Diese Regeln werden separat als Domain Validation formuliert.

  • Name und Zweck
  • Ein- und Ausgabeschema
  • Vorbedingungen
  • Nebenwirkungen und Rechte
  • Fehler und Testfälle

Travel-Fallstudie

Aus mehreren Preis- und Verfügbarkeitsendpunkten entsteht ein Tool `revalidate_offer`, das Offer-ID, Zeitpunkt, neue Gesamtsumme und geänderte Bedingungen zurückgibt.

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

API-Spiegel wie executeRequest oder updateBooking verschieben technische Komplexität und riskante Entscheidungen zum Modell. Freitextparameter, versteckte Defaults und polymorphe Mega-Schemas erhöhen Mehrdeutigkeit. Annotationen wie readOnlyHint sind Hinweise des Servers und keine Sicherheitsgarantie.

Erforderliche Evidenz

Ein reviewfähiger Vertrag enthält gültige und ungültige Beispiele, Grenzwerte, erwartete Protokoll- und Toolfehler, Datenschutzklassifikation und Testvektoren. Für revalidate_offer müssen ursprüngliche Offer-ID, Prüfzeitpunkt, neue Summe, Währung, Differenz und geänderte Bedingungen eindeutig sein.

Messgrößen und Abnahmekriterien

Gemessen werden Schemafehler, fachliche Ablehnungen, falsche Toolauswahl, Korrekturversuche des Modells, Ergebnisvalidierung, Seiteneffektfehler und Vertragsbrüche zwischen Versionen.

Ergebnis und weiterführende Analyse

Am Ende steht ein reviewfähiger Capability-Steckbrief für Architektur, Fachbereich und Security.

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.