Warum eine gute Dokumentation noch keinen Laufzeittest ersetzt

Eine Anbieter-Dokumentation kann zuverlässig belegen, was der Anbieter öffentlich beschreibt: Zugangsvoraussetzungen, Transport, Toolgruppen oder Planlimits. Sie kann nicht belegen, dass genau dein Client mit genau diesem Serverstand und genau deinem Account funktioniert.

Diese Unterscheidung klingt klein, verändert aber die Aussage.

Drei Befunde, drei Formulierungen

Dokumentiert: Die Primärquelle beschreibt eine Capability oder Verbindung. Zulässige Formulierung: „Der Anbieter dokumentiert …“

Verbunden: Ein Client hat den Server erreicht und beispielsweise eine Toolliste erhalten. Das belegt noch keinen fachlichen Aufruf.

Reproduziert: Ein versionierter Fixture-Pfad lief mit festgehaltenen Eingaben, erwarteter Antwort und relevanten Fehlerfällen.

Wer aus der ersten Stufe „vollständig kompatibel“ macht, überspringt Transport-, Auth-, Schema- und Produktgrenzen.

Warum ein erfolgreicher Demo-Call ebenfalls nicht reicht

Ein kleiner Aufruf kann funktionieren, während Pagination, große Ergebnismengen, Token-Erneuerung oder Mandantentrennung scheitern. Auch Kosten werden in einer Demo oft nicht sichtbar.

Der Test muss deshalb zu der späteren Nutzung passen. Ein Team, das nur gespeicherte Keyword-Daten liest, braucht einen anderen Beleg als ein Team, das Live-Crawls über einen Agenten starten will.

Der Status auf seo-mcp.de

Die aktuelle Anbietermatrix beruht auf datierten Primärquellen. Sie ist ausdrücklich kein Laufzeitbenchmark. Jede Zeile trägt diesen Status direkt am Befund.

Das ist keine Schwäche, die durch optimistischere Sprache verdeckt werden sollte. Es ist die Grenze der vorhandenen Evidenz – und damit die klare Aufgabenliste für die nächsten Fixtures.

Was aus der Dokumentationsprüfung in das Fixture wandert

Die Dokumentation ist trotzdem wertvoll. Aus ihr entstehen die erwarteten Transportwege, Authentifizierungsschritte, Toolnamen, Schemas und Planvoraussetzungen des späteren Tests. Diese Erwartungen werden vor dem Lauf festgehalten, damit ein unerwartetes Ergebnis nicht nachträglich passend erklärt wird.

Bei jeder Quelle notieren wir URL, Beobachtungsdatum und den genauen Geltungsbereich. Ändert der Anbieter seine Dokumentation, wird der alte Befund nicht überschrieben, sondern als veraltet behandelt. So lässt sich später unterscheiden, ob ein Test wegen einer echten Laufzeitabweichung, einer geänderten Produktgrenze oder einer überholten Erwartung scheiterte.

Ein sauberer Prüfpfad lautet deshalb: Primärquelle lesen, enge Erwartung formulieren, Versionen fixieren, positiven und negativen Pfad ausführen, Ergebnis protokollieren. Erst danach darf aus „dokumentiert“ ein „reproduziert“ werden.