So schreibt man einen MCP-Kompatibilitätsbericht ohne Scheingenauigkeit

Ein guter Kompatibilitätsbericht beginnt nicht mit „funktioniert“ oder „funktioniert nicht“. Er beginnt mit der engsten Aussage, die der Test tatsächlich trägt.

Beispiel: „Toolliste und ein read-only Keyword-Aufruf wurden am 22. August 2026 mit Client X, Serverrelease Y und MCP 2026-07-28 reproduziert.“ Diese Formulierung ist weniger spektakulär als „vollständig kompatibel“, aber wesentlich nützlicher.

Aufbau des Berichts

1. Behauptung: Welcher Pfad wurde geprüft?
2. Umgebung: Versionen, Transport, Auth-Modus, Plan und Region.
3. Fixture: Inputs, erwartete Felder und erlaubte Abweichungen.
4. Ergebnis: erfolgreich, teilweise, fehlgeschlagen oder nicht prüfbar.
5. Negative Fälle: Welche ungültigen Requests wurden getestet?
6. Grenzen: Was wurde ausdrücklich nicht geprüft?
7. Verfall: Welches Ereignis oder Datum macht den Befund stale?

Abweichungen nicht glattbügeln

Wenn ein Feld fehlt, Pagination anders arbeitet oder ein Client eine Capability nicht anzeigt, gehört das in den Bericht. Ein Workaround wird separat beschrieben und nicht als Standardverhalten ausgegeben.

Ebenso wichtig sind Kosten und Limits. Ein Test mit fünf Zeilen sagt nichts über den produktiven Abruf von 50.000 Zeilen, solange der größere Pfad nicht geprüft wurde.

Was seo-mcp.de aktuell sagen darf

Die bestehende Matrix dokumentiert Anbieterangaben, aber keine reproduzierten Laufzeittests. Der nächste belastbare Schritt ist ein kleiner Fixture-Lauf mit benanntem Client und Server. Bis dahin bleibt der Status „Doku geprüft · kein Laufzeittest“.

Der Bericht braucht ein wiederverwendbares Belegpaket

Zum veröffentlichten Text gehört ein bereinigtes Paket aus Fixture-Version, Konfiguration, Requestbeispielen und den relevanten Antwortfeldern. Secrets, private Endpoints und Kundendaten werden entfernt. Die Bereinigung muss trotzdem genug Struktur übrig lassen, damit ein zweites Team den Pfad nachbauen kann.

Screenshots allein reichen dafür nicht. Sie können eine Nutzeroberfläche belegen, aber keine vollständigen Header, Schemas oder Fehlerrückgaben. Ebenso wenig sollte ein unbearbeitetes Terminalprotokoll veröffentlicht werden, wenn es Tokens oder interne Pfade enthalten kann.

Der Bericht erhält eine stabile ID und verweist auf Korrekturen. Bei einem späteren Retest bleibt die alte Fassung nachvollziehbar; der neue Stand ersetzt nicht rückwirkend das historische Ergebnis. So wird aus einer Momentaufnahme eine belastbare Versionsspur.

Wenn kein zweites Team den Test mit den veröffentlichten Angaben wiederholen könnte, ist der Bericht eher eine Beobachtung als ein Reproduktionsnachweis.