mcp-content-ops

Ein MCP-Server, der einem Agenten erlaubt, mit CMS-Inhalten zu arbeiten. Die Tools sind der langweilige Teil – suchen, lesen, einen Entwurf anlegen, ein Feld setzen, veröffentlichen. Der Teil, der Nachdenken erforderte, ist das, was passiert, bevor eines davon überhaupt ausgeführt wird.

Die meisten Content-MCP-Server, die wir uns angesehen haben, übergeben dem Modell einen API-Client und Zugangsdaten mit den Berechtigungen, die das Integrationskonto gerade zufällig hat – in einer CMS also meist alles. Die Demo funktioniert. Dann bittet jemand den Agenten darum, „die Produktseiten aufzuräumen“, und er veröffentlicht vierzig Entwürfe, weil im System nie gesagt wurde, dass er das nicht dürfe.

Die Eingrenzung

Vier Prüfstufen, in dieser Reihenfolge, und keine davon steht im Tool-Schema:

1. Argumentvalidierung gegen das veröffentlichte Schema. Unbekannte Eigenschaften werden abgelehnt statt verworfen – ein Modell, das sich ein Argument ausdenkt, hat das Tool missverstanden, und ein stilles Verwerfen würde das verbergen.

2. Standardmäßig verweigern. Schreibvorgänge sind deaktiviert, es sei denn, die Konfiguration aktiviert sie. Es gibt nirgendwo in Policy eine permissive Standardeinstellung.

3. Typ- und Feld-Allowlisten. Dass ein Typ lesbar ist, bedeutet nicht, dass er beschreibbar ist, und ein beschreibbarer Typ bedeutet nicht, dass jedes seiner Felder beschreibbar ist.

4. Strukturierte Protokollierung jedes Aufrufs – erlaubt oder abgelehnt – mit Begründung.

Der Typ, an dem ein Aufruf gemessen wird, stammt aus dem gespeicherten Objekt, niemals aus den Argumenten. Wer dem Aufrufer erlaubt zu behaupten, welche Art von Objekt er bearbeitet, lässt ihn auch bestimmen, welche Regel gilt.

Ein abgelehnter Aufruf kommt als normales Tool-Ergebnis mit gesetztem isError zurück, nicht als JSON-RPC-Fehler. Das Modell soll sehen, warum abgelehnt wurde, und sich anpassen; ein Protokollfehler bedeutet, dass der Client kaputt ist – das ist ein anderes Gespräch.

Related MCP server: ToolBridge

Ausführen

pip install -e ".[dev]"
python -m content_ops.server policy.example.json
pytest -q

Das CMS dahinter ist ein In-Memory-Stub in cms.py – vier Methoden, sieh gegen Content-API austauschbar.

Was es nicht tut

Absichtlich kein Löschwerkzeug. Keine Ressourcen oder Prompts, nur Tools. Keine Authentifizierung: Dies ist ein stdio-Server, und Vertrauensgrenze ist der Prozess, der ihn gestartet hat. Der Schema-Validator deckt die Teilmenge ab, die unsere eigenen Tool-Schemas verwenden, nicht das gesamte JSON Schema.

Warum kein SDK

Das MCP Python SDK ist gut und für einen größeren Server ist der richtige Ansatz. Dieser Server implementiert drei Methoden über stdio, und das Wire-Format ist klein genug dafür, dass eine Abhängigkeit, die sich im Tempo der jeweiligen SDKs bewegt, das größere Risiko war.