FACT COPY · DE
Faktenfassung: Capability- und Tool-Designer
Strukturierte Vorlage für verständliche Tools, Ressourcen und Prompts.
Originalseite: https://travel-mcp.com/de/praxiswissen/capability-designer/
Sachliche Zusammenfassung
Der Designer übersetzt Nutzerabsichten in kleine, testbare Capability-Verträge statt technische API-Endpunkte ungefiltert zu spiegeln. Wie wird aus einer Nutzerabsicht ein kleiner, semantisch eindeutiger und sicher autorisierbarer Capability-Vertrag?
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.