Client, Server, Tool, Resource und Prompt richtig auseinanderhalten

Ein MCP-System besteht nicht aus einem „Agenten, der auf eine API zugreift“. Der Client, der Server und die angebotenen Primitive haben getrennte Verantwortungen. Wer diese Grenzen unscharf lässt, baut schnell Tools, deren Wirkung weder für den Nutzer noch für das Modell erkennbar ist.

Der Client führt den Dialog

Der Client ist die AI-Anwendung, in der die Nutzerabsicht ankommt. Er kennt die verfügbaren Server und kann angebotene Funktionen aufrufen. Der Client sollte Zustimmung einholen, Ergebnisse verständlich darstellen und mit Fehlern umgehen.

Er ist aber nicht die letzte Sicherheitsgrenze. Ein manipulierter oder schlecht konfigurierter Client darf keine Operation ausführen können, die der Server selbst nicht autorisiert hat.

Der Server setzt den Vertrag durch

Der Server beschreibt und implementiert seine Capabilities. Er validiert Eingaben, ordnet den Aufruf einer Identität und einem Mandanten zu, prüft Rechte und führt die begrenzte Operation aus.

Für einen SEO-Server bedeutet das zum Beispiel:

• Property und Workspace serverseitig prüfen,
• maximale Zeilen- oder URL-Zahl erzwingen,
• kostenpflichtige Aufrufe gegen ein Budget prüfen,
• private Felder aus Antworten entfernen,
• jeden relevanten Zugriff protokollieren.

Die Toolbeschreibung hilft dem Modell bei der Auswahl. Sie ist kein Ersatz für diese Kontrollen.

Resource oder Tool?

Eine Resource eignet sich für adressierbaren Kontext, den der Client lesen kann. Denkbar wäre eine bereits gespeicherte Audit-Zusammenfassung für eine konkrete Projekt-ID. Ein Tool ist eine Operation mit Eingaben und einem Ergebnis, etwa das Filtern eines Keyword-Inventars oder das Starten eines begrenzten Crawls.

Eine brauchbare Faustregel:

Wenn der Aufruf etwas berechnet, Kosten auslöst, Zustand erzeugt oder eine Entscheidung durchsetzt, behandle ihn als Operation und dokumentiere seine Wirkung ausdrücklich.

Ein Prompt ist dagegen eine wiederverwendbare Gesprächs- oder Arbeitsvorlage. Er kann einen Ablauf strukturieren, darf aber nicht als versteckte Berechtigungslogik missverstanden werden.

Lange Arbeit gehört in einen sichtbaren Lebenszyklus

Ein Crawl oder eine umfangreiche Anreicherung passt oft nicht in eine kurze synchrone Antwort. Die Spezifikation 2026-07-28 führt Tasks als Erweiterung für länger laufende Arbeit. Entscheidend ist nicht nur, dass ein Task gestartet werden kann. Nutzer und Systeme brauchen auch Status, Abbruch, Fehlergrund und ein dauerhaft zuordenbares Ergebnis.

Für SEO sollte ein Task mindestens festhalten:

1. wer ihn gestartet hat,
2. welche Property und welcher Scope betroffen sind,
3. welches Limit und Budget galten,
4. welcher Datenstand verwendet wurde,
5. ob das Ergebnis vollständig, teilweise oder fehlgeschlagen ist.

Ein Beispiel ohne Mehrdeutigkeit

„Zeige auffällige Seiten“ ist kein stabiler Toolvertrag. Besser ist eine Operation wie list_declining_pages mit Property-ID, Vergleichsfenster, Mindestimpressionen, Land, Gerät und maximaler Ergebniszahl. Die Antwort nennt Zeitraum, Datenfrische, Filter und fehlende Daten.

Der Nutzen entsteht nicht durch den Toolnamen, sondern durch den engen, nachvollziehbaren Vertrag.