Die kleinste fachliche Funktion beschreiben
Statt einer universellen API-Abfrage bietet ein erster Server beispielsweise „Auftragsstatus lesen“ an. Eingaben beschränken sich auf eine zulässige Kennung; die Antwort enthält Status, Stand und erlaubte nächste Schritte. MCP beschreibt Werkzeuge mit Namen und Schemas. Der konkrete Toolvertrag muss zusätzlich festlegen, was bei unbekannten Kennungen, fehlenden Rechten und veralteten Daten passiert.
Anmeldung und Datenzugriff getrennt prüfen
Bei geschütztem HTTP-Zugriff beschreibt die MCP-Spezifikation einen OAuth-basierten Weg mit serverbezogenen Tokens. Der Server muss trotzdem prüfen, ob der angemeldete Nutzer den konkreten Auftrag sehen darf. Ein gültiges Token für den Dienst bedeutet nicht Zugriff auf jeden Datensatz. Für Mandantentrennung werden mindestens zwei Testkonten mit unterschiedlichen Daten eingesetzt.
Schreibaktionen explizit und wiederholbar gestalten
Lesen und Ändern erhalten getrennte Werkzeuge. Eine Änderung beschreibt das Ziel und den vorgesehenen neuen Zustand; die Anwendung zeigt diese Angaben vor der Freigabe. Wiederholte Anfragen werden über einen stabilen Vorgangsschlüssel erkannt. Ein Timeout darf nicht zu einer zweiten Bestellung führen. Nach der Aktion wird der tatsächliche Zustand gelesen und mit dem beabsichtigten Ergebnis verglichen.
Verbindungsaufbau und fachliche Wirkung testen
Eine erfolgreiche Tool-Liste beweist nur die Verbindung. Die Abnahme enthält gültige und ungültige Eingaben, fremde Datensätze, abgelaufene Anmeldung, begrenzte Antwortgrößen und Fehler ohne Geheimnisse. Ein gezielter End-to-End-Test zeigt schließlich, dass ein berechtigter Nutzer genau die vorgesehenen Daten erhält. Erst danach werden weitere Funktionen ergänzt.
Nachvollziehbar bleiben
Primärquellen
- MCP tools specification, 2025-11-25Quellenstand:
- MCP authorization specification, 2025-11-25Quellenstand:
