Was ein SEO-MCP-Server vor der Verbindung offenlegen sollte

Vor der ersten Verbindung sollte ein Team mehr wissen als Endpoint und Toolzahl. Die nötigen Angaben passen auf eine klare Betriebsseite – wenn der Betreiber seine Grenzen tatsächlich kennt.

Betreiber und technischer Stand

Nenne Betreiber, Kontakt, Sicherheitskontakt, Protokollversion, Serverversion, unterstützte Transporte und den Zeitpunkt der letzten Prüfung. Produktname und Domain dürfen keine offizielle Nähe zum Model Context Protocol suggerieren.

Daten und Wirkung

Für jede Capability sollte erkennbar sein:

• welche Datenquelle verwendet wird,
• ob Daten gespeichert oder weitergegeben werden,
• welche Felder und Mandanten betroffen sein können,
• ob der Aufruf Kosten erzeugt,
• ob er externe Zustände verändert,
• welche Limits durchgesetzt werden.

Ein pauschales „read-only“ reicht nicht, wenn Exporte, kostenpflichtige Analysen oder gespeicherte Jobs möglich sind.

Autorisierung und Aufbewahrung

Der Betreiber sollte erklären, welche Identität der Server sieht, welche Scopes verlangt werden und wie Workspaces getrennt bleiben. Ebenso wichtig: Wie lange werden Inputs, Ergebnisse und Auditdaten aufbewahrt? Wer kann sie löschen oder exportieren?

Betriebs- und Korrekturweg

Status, bekannte Einschränkungen, Incident-Kontakt und Änderungslog gehören zur nutzbaren Oberfläche. Bei einer sicherheitsrelevanten Änderung muss ein Team feststellen können, ob seine bestehende Verbindung betroffen ist.

Für seomcp.de gilt eine zusätzliche harte Grenze: Eine solche technische Betriebsoberfläche wird erst sinnvoll, wenn ein realer, geprüfter Dienst existiert. Redaktionelle Einordnung bleibt auf seo-mcp.de.

Die Angaben müssen auffindbar und aktuell sein

Eine verstreute Mischung aus README, Marketingseite und Changelog macht die Prüfung unnötig schwer. Sinnvoll ist ein stabiler Einstieg, der auf Toolverträge, Authentifizierung, Preise, Datenschutz, Sicherheitskontakt und Status verweist. Maschinenlesbare Metadaten können diesen Einstieg ergänzen, ersetzen aber keine verständliche Darstellung für die Person, die eine Verbindung genehmigt.

Zeitabhängige Angaben tragen ein Prüfdatum. Wird eine Capability entfernt, ein Scope erweitert oder das Kostenmodell geändert, braucht es einen sichtbaren Eintrag im Änderungslog. Besonders relevant sind Breaking Changes und neue Schreibwirkungen.

Ein Server sollte außerdem sagen, was er nicht anbietet: keine beliebigen Remote-URLs, kein Publishing, keine kundenübergreifenden Abfragen oder keine garantierte Vollständigkeit. Solche Negativgrenzen sind oft entscheidender als die Anzahl verfügbarer Tools. Sie erlauben einem Team, eine Verbindung bewusst abzulehnen oder mit einem engeren Einsatzbereich freizugeben.