Was Sie testen sollten, bevor ein MCP-Server zu den Nutzern kommt

Was eine funktionierende Demo nicht beweist

Eine Demo kann mit einem Nutzer, großzügigen Zugangsdaten, gesunden APIs und wohlwollenden Eingaben bestehen. Jede dieser Bedingungen verdeckt eine Klasse von Fehlern. Schreiben Sie die folgenden Tests gegen einen Staging-Server mit Testidentitäten: mindestens zwei normale Nutzer mit unterschiedlichen Rechten, ein Nutzer ohne Zugriff und ein Client, der so registriert ist wie später in Produktion.

Vertragstests: Die Tool-Liste ist eine Schnittstelle

Clients, Prompts und Evaluierungssets hängen an Namen, Beschreibungen und Schemas der Tools, eine stille Änderung ist also eine inkompatible Änderung. Die aktuelle Spezifikation erlaubt, dass die Tool-Liste je nach Autorisierung der Anfrage variiert. Sie halten den Stand deshalb je Testidentität fest.

• tools/list stimmt je Identität mit dem geprüften Stand überein, und jede Abweichung braucht eine genehmigte Änderung
• Jedes strukturierte Ergebnis besteht die Prüfung gegen sein Ausgabeschema, was die Spezifikation verlangt, sobald eines deklariert ist
• Falsche Typen, unerwartete Felder und Werte außerhalb des Bereichs werden mit einer Meldung abgelehnt, die das Problem benennt

Negative Autorisierungstests

Bei einem Server, der über den HTTP-Autorisierungsablauf geschützt ist, sollte jeder Fall die Ablehnung prüfen, das Ausbleiben von Nebenwirkungen und das Fehlen von Daten in der Fehlermeldung:

• Kein Token oder ein abgelaufenes: HTTP 401 mit einem WWW-Authenticate-Header, der auf die Resource-Metadaten verweist
• Ein korrekt signiertes Token für einen anderen Empfänger: abgelehnt, weil der Server nur Tokens für sich selbst akzeptieren darf
• Ein gültiges Token ohne den nötigen Scope: 403 mit insufficient_scope-Challenge, sofern Server und Clients die empfohlene Erweiterung umsetzen
• Nutzer A fragt über ein gültiges Tool nach dem Datensatz von Nutzer B: abgelehnt, ohne Inhalte des Datensatzes in der Meldung
• Ein von Nutzer A erzeugtes und von Nutzer B wiederverwendetes Zustands-Handle: abgelehnt, denn ein Handle darf nicht als Authentifizierung gelten
• Ein Schreibvorgang ohne passende Freigabe oder mit nach der Freigabe geändertem Inhalt: abgelehnt
• Die Request-Logs der Fachsysteme im Staging weisen die eigene Testidentität des Servers über Client-ID, Audience oder Schlüssel-Fingerprint aus und enthalten nie das eingehende Token oder einen Wert von Zugangsdaten

Ausfälle in den Systemen hinter dem Server

MCP unterscheidet Protokollfehler, etwa ein unbekanntes Tool oder eine fehlerhafte Anfrage, von Fehlern bei der Tool-Ausführung, die mit isError auf true zurückkommen. Tests sollten bestätigen, dass jeder Ausfall in der richtigen Kategorie landet. Injizieren Sie im Staging Fehler: Timeouts im Fachsystem, Rate-Limit-Antworten, Serverfehler, abgeschnittene Antworten und Antworten, die langsamer sind als das Timeout des Clients. In jedem Fall sollte das Tool einen Ausführungsfehler liefern, mit dem das Modell etwas anfangen kann, ohne Stacktrace, internen Hostnamen oder Token im Text. Prüfen Sie außerdem, dass die eigenen Rate Limits des Servers, die die Spezifikation verlangt, tatsächlich greifen.

Tests für Zustandsänderungen bei jedem Schreibvorgang

1. 1

   Wiederholen

   Senden Sie denselben bestätigenden Aufruf zweimal und erwarten Sie einen Datensatz. Lassen Sie dann den Schreibvorgang im Fachsystem gelingen, aber die Antwort in ein Timeout laufen, wiederholen Sie und erwarten Sie weiterhin einen Datensatz.

2. 2

   Unterbrechen

   Lassen Sie einen mehrstufigen Schreibvorgang auf halber Strecke scheitern. Wo die Schreibvorgänge im Fachsystem nicht atomar sein können, hält der Server einen dauerhaft gespeicherten Zwischenstand, und ein Kompensations- oder Abgleichschritt schließt die Arbeit ab oder macht sie rückgängig. Das Tool-Ergebnis sagt, in welchem Zustand der Vorgang ist.

3. 3

   Abbrechen

   Bereiten Sie eine Änderung vor und bestätigen Sie sie nie: Nichts ändert sich. Bestätigen Sie nach Ablauf des Handles: Ein Ausführungsfehler erklärt, dass ein neuer Vorschlag nötig ist.

4. 4

   Kollidieren

   Ändern Sie den Datensatz im Fachsystem zwischen Vorbereitung und Bestätigung. Das Tool meldet einen Konflikt, statt zu überschreiben.

Führen Sie diese Tests gegen eine Sandbox des Fachsystems mit synthetischen Datensätzen aus, nie gegen die Produktion.

Den Plan in der CI und vor Client-Updates ausführen

Der MCP Inspector hat einen Kommandozeilenmodus für Skripte mit dokumentierten Exit-Codes: 3, wenn der Server eine Authentifizierung verlangt, 5, wenn ein Tool-Aufruf isError liefert oder das Tool fehlt, und 6, wenn die strikte Prüfung ein Portabilitätsproblem im Schema findet. Weil Exit-Code 5 sowohl eine Ablehnung durch eine Regel als auch ein fehlendes Tool bedeutet, prüft das Beispiel, dass das Tool existiert und der Fehler die erwartete Meldung enthält. Mit dem Flag stored-auth-only scheitert ein CI-Lauf sofort, statt auf eine Browser-Anmeldung zu warten. URL, Tools und Meldung sind hypothetisch.

set -euo pipefail
SERVER="https://mcp.staging.internal/mcp"
inspect() { npx @modelcontextprotocol/inspector --cli "$SERVER" --transport http --stored-auth-only "$@"; }

# Contract: both tools are listed, and schemas pass the strict check
inspect --method tools/list --format json \
  | jq -e '.result.tools | map(.name) | (index("find_orders") != null and index("prepare_return") != null)' > /dev/null
inspect --method tools/list --strict > /dev/null

# Business rule: a return outside the policy window comes back as a tool error (exit 5)
# with the expected rule message, not merely as a missing tool
set +e
out=$(inspect --method tools/call --tool-name prepare_return --tool-arg order_number=SO-00000001 --format json)
code=$?
set -e
test "$code" -eq 5
echo "$out" | jq -e '.result.isError == true and (.result.content[0].text | test("return window"))' > /dev/null

Der Inspector deckt das Protokollverhalten ab. Fälle zu Identität, Freigaben und Zustandsänderungen, einschließlich der Prüfung, dass ein abgelehnter Aufruf in der Sandbox nichts angelegt hat, brauchen meist ein eigenes Test-Harness, das Testnutzer wechselt und das Fachsystem prüft. Führen Sie den ganzen Plan erneut aus, wenn sich Protokollrevision, SDK oder ein unterstützter Client ändern. Die Revision vom 2026-07-28 hat zum Beispiel Protokoll-Sessions entfernt, was Tests bricht, die davon ausgingen.

MCP-Server-Entwicklung