Liste zunächst auf, was Menschen von deinem Plug-in erwarten. Sein Name, seine Beschreibung, Skills, Tools und die Verbindung zu einem bestehenden Produkt wecken Erwartungen. Deine Implementierung sollte diese Erwartungen erfüllen. Wo sie das nicht tut, sollte eine bewusste Entscheidung dahinterstehen.
Daraus ergibt sich, welche Bestandteile dein Plug-in braucht:
- Füge einen Skill hinzu, wenn Anweisungen, Beispiele oder mitgelieferte Ressourcen das Modell durch den Ablauf führen können.
- Füge einen MCP-Server hinzu, wenn der Ablauf Live-Daten, Authentifizierung, kontrollierte Tools oder Code benötigt, der auf einer von dir betriebenen Infrastruktur ausgeführt wird.
- Ergänze den MCP-Server um eine Benutzeroberfläche nur dann, wenn die visuelle Interaktion einen Teil des Ablaufs wesentlich verbessert.
Von den Erwartungen der Nutzenden ausgehen
Stell dir vor, jemand hat dein Plug-in installiert, aber die Dokumentation nicht gelesen. Welche Anfragen würde diese Person berechtigterweise an das Plug-in stellen?
Sammle anhand der folgenden Quellen wahrscheinliche Anfragen:
- Aufgaben, die Menschen bereits mit deinem Produkt oder Dienst erledigen.
- Interviews mit Nutzenden, Supportanfragen, Suchanfragen und Funktionswünsche.
- Gängige Begriffe, mit denen Menschen dein Produkt, deine Daten und deine Arbeitsabläufe beschreiben.
- Bestehende Behelfslösungen, bei denen Daten zwischen Tools kopiert werden müssen.
- Name, Verzeichniseintrag, Screenshots und Einstiegs-Prompts des Plug-ins.
Berücksichtige direkte Anfragen, die dein Plug-in beim Namen nennen, und indirekte Anfragen, die das Ziel beschreiben. Ein Plug-in zur Projektverwaltung muss beispielsweise sowohl „Zeig mir mein Board für den Acme-Launch“ als auch „Was blockiert den Launch?“ bearbeiten können.
Beschränke die Ideensammlung nicht auf Arbeitsabläufe, die zu deiner aktuellen API passen. Erfasse zuerst die Erwartungen der Nutzenden. Vergleiche sie anschließend mit dem, was du sicher und zuverlässig unterstützen kannst.
Eine Übersicht der Anwendungsfälle erstellen
Halte für jeden Anwendungsfall Folgendes fest:
| Feld | Zu beantwortende Frage |
|---|---|
| Ziel der Person | Was möchte die Person erreichen? |
| Beispielanfragen | Wie könnte sie ihre Anfrage direkt oder indirekt formulieren? |
| Erwartetes Ergebnis | Was würde die Interaktion erfolgreich machen? |
| Erforderlicher Kontext | Welche Informationen, Kontozugriffe oder vorherigen Zustände sind erforderlich? |
| Funktion des Plug-ins | Kann ein Skill die Aufgabe erledigen oder ist ein MCP-Tool nötig? |
| Sicherheitsgrenze | Könnten dabei Daten offengelegt, Zustände verändert, Geld ausgegeben oder andere Personen betroffen werden? |
| Entscheidung zur Unterstützung | Wird der Anwendungsfall in der ersten Version unterstützt, auf später verschoben oder bewusst ausgeschlossen? |
Fasse Anfragen mit demselben Ziel zusammen. „Liste meine offenen Aufgaben auf“, „Was muss ich heute erledigen?“ und „Zeig mir überfällige Aufgaben“ können zu einem einzigen Anwendungsfall für die Aufgabenübersicht mit verschiedenen Filtern gehören, statt drei voneinander unabhängige Funktionen zu bilden.
Abdeckung prüfen
Gleiche jede Erwartung mit den vorgesehenen Funktionen des Plug-ins ab:
- Stelle sicher, dass jeder unterstützte Anwendungsfall einen vollständigen Ablauf von der Anfrage bis zu einem nützlichen Ergebnis bietet.
- Ermittle fehlende Skills, Tools, Daten, Berechtigungen oder Fehlerzustände.
- Achte auf Tools, die technische Operationen bereitstellen, ohne ein erkennbares Ziel der Nutzenden zu erfüllen.
- Prüfe, ob Schreibaktionen eine angemessene Autorisierung und Bestätigung vorsehen.
- Prüfe, ob das Plug-in seine Grenzen erklären und einen hilfreichen nächsten Schritt anbieten kann.
Ein Plug-in sollte keine umfassenden Funktionen suggerieren, wenn es nur einen kleinen Teil des erwarteten Ablaufs unterstützt. Wenn Nutzende Projekte erstellen, aber nicht auflisten, einsehen oder aktualisieren können, ergänze entweder die fehlenden Funktionen oder grenze die Positionierung des Plug-ins entsprechend ein.
Bewusste Ausschlüsse dokumentieren
Du musst nicht jede denkbare Anfrage unterstützen. Für jeden wichtigen Ausschluss solltest du aber einen guten Grund haben, zum Beispiel:
- Die Aktion würde ein unvertretbares Risiko für Sicherheit oder Datenschutz darstellen.
- Das zugrunde liegende Produkt oder die API unterstützt die Aktion nicht zuverlässig.
- Der Ablauf erfordert Berechtigungen, die das Plug-in nicht überprüfen kann.
- Ohne Informationen, auf die das Plug-in keinen Zugriff hat, wäre das Ergebnis irreführend.
- Der Anwendungsfall liegt außerhalb des Umfangs der ersten Version, und der Verzeichniseintrag des Plug-ins macht das deutlich.
Halte diese Entscheidungen fest. Sie sollten in die Grenzen der Skills, Tool-Beschreibungen, das Verhalten bei Ablehnungen, Testfälle und die Texte des öffentlichen Verzeichniseintrags einfließen.
Aus Anwendungsfällen Entscheidungen zur Umsetzung ableiten
Wähle für jeden unterstützten Anwendungsfall die kleinste Implementierung, die ihn vollständig abdecken kann:
- Erstelle einen Skill für wiederverwendbare Anweisungen und Ressourcen.
- Erstelle einen MCP-Server für Live-Daten und kontrollierte Aktionen.
- Ergänze den MCP-Server um eine Benutzeroberfläche, wenn Nutzende strukturierte Informationen einsehen, vergleichen, bearbeiten oder bestätigen oder darin navigieren müssen.
Verwende die Übersicht der Anwendungsfälle als Testplan. Ergänze repräsentative direkte und indirekte Anfragen sowie Ausnahmefälle und Anfragen außerhalb des vorgesehenen Umfangs. Prüfe dann, ob sich das fertige Plug-in bei jeder Anfrage wie beabsichtigt verhält.
Wenn das Plug-in Live-Daten oder kontrollierte Aktionen benötigt, fahre mit Tools definieren fort.