WordPress MCP vs Headless CMS MCP: Welcher Stack passt zu AI-Agenten?

WordPress MCP hat nun eine offizielle Route: die Abilities API, die in WordPress 6.9 ankam, plus den MCP Adapter, der Abilities in Tools umwandelt, die ein Agent aufrufen kann. Gut. Headless-CMS haben diesen Punkt früher erreicht mit eigenen First-Party-Servern, während Git-basierte Sites viel von diesem Durcheinander vermeiden, indem sie jeden Agent-Edit durch einen Pull Request zwingen, bevor er Production erreichen kann. Keiner dieser Stacks ist standardmäßig sicher. Der echte Unterschied liegt darin, wo die Sicherheit lebt: in der Box oder in der Arbeit, die du daran herum leistest. Dieser Beitrag vergleicht Stacks statt Plugin gegen Plugin und gibt dir dann eine Checkliste und eine vorsichtige Sicht darauf, wo Agent-betriebene Sites bis 2027 leben könnten.

Was MCP ändert: deine Site bekommt einen Agenten, der schreiben kann

Schreibgeschützter MCP ist eine wohlerzogenere Suchbox. Ein Agent ruft Posts ab, fasst sie zusammen und erkennt Lücken, und wenn der Agent die Arbeit falsch macht, wird die Site nicht beschädigt. Nichts bricht.

Schreibzugriff ist anders. Sobald ein Server Create-, Update-, Publish- und Delete-Tools verfügbar macht, wird der Agent zu einem arbeitenden Nutzer deiner Site mit jedem Recht, das sein Token trägt. Er kann um 3 Uhr morgens eine Preisseite umschreiben. Er kann einen Entwurf veröffentlichen, den niemand genehmigt hat, und er kann durch Text, den er auf dem Weg liest, sowohl zu Fehlern als auch zu Erfolgen gedrängt werden. Mehr dazu in Kürze.

CMS-Wahl hört daher auf, hauptsächlich um Redakteure und Templates zu gehen. Sie wird zur Berechtigungsfrage, und vier Unterfragen leisten den meisten der schwierigen Arbeit.

1. Wie fein kannst du eingrenzen, was der Agent tun darf?
2. Kann er im Entwurf bleiben, oder geht jeder Schreibvorgang live?
3. Gibt es ein Audit-Log und kannst du es rückgängig machen?
4. Kann ein Mensch das Ergebnis sehen, bevor es die Öffentlichkeit sieht?

Das ist jetzt kein Nischenproblem mehr. Das UK AISI zählte öffentlich veröffentlichte MCP-Tools, die in einem Jahr von etwa 5.000 auf 177.000 stiegen, mit Downloads von 80.000 auf 14 Millionen. Das sind viele Server, denen man vertrauen oder nicht vertrauen muss. Wenn du eine Routine zum Treffen dieser Entscheidung möchtest, habe ich eine geschrieben in Claude Code Skills, Plugins und MCP-Server prüfen, und das breitere Bild des Betriebs von MCP in der Produktion ist im MCP-Server Production Stack-Beitrag.

WordPress, die offizielle Route: die Abilities API und der MCP Adapter

Die Abilities API landete in WordPress 6.9. Sie gibt Core, Themes und Plugins eine Standardmethode, um zu deklarieren, was sie können, mit Input-Schemas und Permission-Callbacks. Der MCP Adapter sitzt über dieser Schicht. Er wird als das offizielle WordPress-Paket für MCP-Integration beschrieben, lebt unter der WordPress GitHub-Organisation und gehört zur AI Building Blocks for WordPress-Initiative. Seine Aufgabe ist eng, aber wichtig: Abilities als MCP-Tools, Ressourcen und Prompts verfügbar machen.

Was die README dokumentiert:

• HTTP- und STDIO-Transporte, plus eine McpTransportInterface für benutzerdefinierte Protokolle. Clients verbinden sich über WP-CLI über STDIO oder indem sie einen HTTP-Client auf /wp-json/mcp/mcp-adapter-default-server zeigen.
• Ein Feature, das es granulare Berechtigungen nennt: Transport-Authentifizierung pro Server und Berechtigungsprüfungen pro Ability.
• Fähigkeiten sind standardmäßig privat. Das Setzen von meta.public (oder meta.mcp.public) auf true macht eine Fähigkeit öffentlich.
• Der Standard-Server bietet drei Meta-Tools: mcp-adapter/discover-abilities, mcp-adapter/get-ability-info und mcp-adapter/execute-ability.
• Pluggbare Fehlerbehandlung und Observability über McpErrorHandlerInterface und McpObservabilityHandlerInterface.

Standardmäßig privat ist der richtige Instinkt. Eine Fähigkeit, die niemand als öffentlich gekennzeichnet hat, kann von einem Agent nicht erreicht werden, egal wie clever der Prompt auch sein mag. Schauen Sie sich jetzt an, was auf dieser Liste fehlt: keine nur-für-Entwurf Agent-Rolle, kein eingebauter Genehmigungsschritt, kein Audit-Log. Die Observability-Hooks sind ein Ort, um eines zu bauen. Sie sind kein fertiges Audit-Trail.

Die Entwurfskontrolle lebt innerhalb der Fähigkeiten. Jemand muss sie schreiben. Ein Plugin eines Drittanbieters, MS WordPress Abilities, zeigt die Form dieser Arbeit recht gut. Es registriert 29 Fähigkeiten (26 benutzerdefinierte, plus drei Kern-Fähigkeiten, die sich für MCP-Sichtbarkeit angemeldet haben) und bietet ein zweistufiges Staging update, preview-post-update und dann apply-post-update, während patch-post-content kein Staging benötigt. Sinnvolles Design. Es ist immer noch die Wahl des Autors, nicht die von WordPress. Nach demselben README versendet der Kern und das offizielle KI-Plugin standardmäßig nur eine Handvoll Fähigkeiten.

Es ist auch noch am Entstehen. Ein Issue, das am 18. März 2026 eröffnet wurde, wies darauf hin, dass die Adapter-README immer noch von der Notwendigkeit der Abilities API sprach, nachdem diese in den Kern gemergt worden war (Issue 150). Am 24. Juni 2026 kommentierte ein Mitwirkender dort, dass neue Kern- und Site-Fähigkeiten in das KI-Plugin und die Abilities API gehören, nicht auf den Adapter, und dass viele Adapter-Dokumente immer noch das ältere Modell der Registrierung beliebiger Fähigkeiten und dem Setzen von mcp.public lehren. Dann, am 5. Februar 2026, sagte ein WordPress-KI-Maintainer, dass er kein Verzeichnis von Plugins kenne, das die Abilities API oder MCP-Unterstützung implementiert (Diskussion 204). Die Installationen sind offiziell. Der Katalog sicherer, nützlicher Fähigkeiten bleibt dünn.

WordPress, die Plugin-Route: viele Wahlmöglichkeiten, eine dünne Sicherheitsbilanz

Die andere WordPress-Route ist ein Plugin, das seinen eigenen MCP-Server mitbringt. Namen, die auf Vergleichsseiten von Anbietern auftauchen, sind Easy MCP AI, WPVibe, Novamira, Royal MCP, miniOrange Secure MCP Server und AI Engine. Ich behandle sie hier als eine Kategorie. Keine Bewertung. Ich wiederhole auch nicht ihre Feature-Ansprüche als Fakt. Eine Vorsichtsmaßnahme ist wichtig: Die beliebten Vergleichsseiten werden von Plugin-Anbietern betrieben, die sich selbst auflisten, also lesen Sie diese als Marketing mit einer Tabelle.

Das, was die Kategorie bietet, ist Geschwindigkeit. Installieren Sie das Plugin, fügen Sie ein Token in Ihren KI-Client ein, und Sie erhalten Tools für Beiträge, Medien und oft Benutzer und Einstellungen. Was es kostet, ist Vertrauen. Sie geben einem Autor eines Drittanbieters einen Endpunkt, der als WordPress-Benutzer fungieren kann, auf einer PHP-Site mit einem vollständigen Admin-Bereich dahinter.

Das einzige öffentliche Sicherheits-Record, das ich hier anführe, gehört einem Plugin, AI Engine:

• CVE-2025-11749. In Versionen bis 3.1.3 war bei aktivierter No-Auth-URL-Option das MCP-Bearer-Token durch die öffentlichen REST-Routes der Site durchgesickert. Unauthentifizierte Angreifer konnten sich beim MCP-Endpunkt authentifizieren und Administrator-Konten erstellen. Behoben in 3.1.4 und am 5. November 2025 in NVD veröffentlicht (SentinelOne's Analyse, die das Leck beim Endpunkt /mcp/v1/ platziert und sagt, dass kein verifizierter öffentlicher Exploit-Code bestätigt wurde).
• CVE-2026-8719. Veröffentlicht 17. Mai 2026, bewertet mit hoch (CVSS 8.8). In Version 3.4.9 prüfte der MCP-OAuth-Bearer-Token-Pfad nicht die Administrator-Berechtigung, daher konnte ein Benutzer auf Subscriber-Ebene mit einem gültigen Token auf Admin-Level-MCP-Tools zugreifen und Administrator werden (GitHub advisory).
• Eine längere Liste. WPScan listet viele weitere auf, einschließlich eines MCP-Benutzer-Tools-Kontoübernahme auf Multisite (behoben in 3.6.1) und Administrator-Kontoerstellung über CSRF (behoben in 3.6.6).

Seien Sie fair darüber, was dies beweist. Es ist ein Plugin. Beliebte Plugins ziehen Überprüfung an, was teilweise der Grund ist, warum dieses eine Bilanz hat, und ein leeres Record anderswo ist kein Beweis für Sicherheit. Dennoch ist das Muster wichtig. Beide Haupt-Bugs sind Autorisierungsfehler an der MCP-Tür, genau dort, wo ein Agent seine Macht erhält. Denken Sie daran, diesen Teil zu merken.

Headless-CMS-MCP-Server: Sanity, Strapi, Contentful und Payload

Headless-Plattformen bauten ihre MCP-Server um das Datenmodell auf. Nicht um einen PHP-Admin. Dieser Unterschied zeigt sich in der Dokumentation.

Sanity

Sanity führt einen gehosteten Server unter https://mcp.sanity.io über Streamable HTTP, mit OAuth standardmäßig und Token-Auth als Option. Agents können GROQ-Abfragen ausführen, Releases verwalten und Dokumente mit Bewusstsein für Ihr Schema patchen. Die Einrichtung ist npx sanity@latest mcp configure. Das ältere lokale Paket @sanity/mcp-server ist veraltet. Das ist die aktuelle Route.

Die Dokumentation beschreibt Draft-First-Schreiben: create_documents erstellt Entwürfe, es sei denn, Sie übergeben eine releaseId, patch_documents speichert in der Entwurfs- oder Release-Version, und veröffentlichter Inhalt wird niemals direkt geändert. Veröffentlichung ist ein separates Tool. Patches auf jedes Dokument werden als eine einzelne Transaktion angewendet. Ein persönliches Token teilt Ihre Rolle und verknüpft Sie mit Änderungen im Revisionsverlauf, während ein Token im Authorization-Header innerhalb seiner eigenen Rolle und seines Umfangs agiert. Es gibt zwei Fallstricke. Der Server macht auch Entwicklung und Projektadministration verfügbar (Schema-Bereitstellung, Datasets, CORS-Origins), daher begrenzen Sie das Token sorgfältig. Und create_release plant nichts ein, was in Studio oder der HTTP Actions API passieren muss.

Strapi

Der MCP-Server von Strapi ist eingebaut und läuft in deiner eigenen Instanz. Er erschien erstmals in v5.47.0 und erreichte allgemeine Verfügbarkeit in v5.49.0 (Strapi blog, 3. September 2026). Standardmäßig ist er deaktiviert: server.mcp.enabled ist false. Er authentifiziert sich mit Admin-API-Token und stellt find-, create-, update-, publish- und unpublish-Tools pro Inhaltstyp bereit. Ein Token kann niemals die Berechtigungen seines Inhabers überschreiten, und das Deaktivieren des Inhabers widerruft ihn. Er erstellt keine Inhaltstypen und lädt keine Medien hoch; diese erfolgen weiterhin über die REST-API (Strapi).

Contentful und Payload

Contentful veröffentlicht einen offiziellen Open-Source-MCP-Server (MIT-Lizenz, npm-Paket @contentful/mcp-server), mit dem Agenten Einträge und Assets verwalten, Inhaltstypen aktualisieren und Jobs wie Tagging und Migrationen automatisieren können. Er benötigt ein Management-Zugriffstoken und eine Space-ID (Contentful). Ein separater Community-Server existiert und verweist auf den offiziellen. Payload fügt MCP über ein offizielles Plugin statt über einen eigenständigen Server hinzu. Soweit gehe ich hier mit Payload nicht.

Falls du Sanity breiter gegen WordPress abwägst, deckt Sanity vs WordPress for enterprise die Seite ohne MCP ab. Fang dort für diesen Teil der Entscheidung an.

Git-basiertes Jamstack: der Pull Request als Sicherheitsnetz

Das dritte Muster hat überhaupt keinen CMS-Server. Inhalte leben im Repo als Markdown, MDX oder typisiertes JSON, und die Site ist Astro oder Next.js. Ein Coding-Agent bearbeitet Dateien. Er öffnet einen Pull Request, der Host erstellt einen Preview-Deploy, und ein Mensch liest das Diff, bevor er merged. Vercel und Netlify unterstützen beide git-basierte Bereitstellung und Preview-Deploys, das ist alles, was dieses Muster von einem Host braucht.

Diese Pull-Request-Schleife ist nichts Exotisches. Next.js dokumentiert, wie es KI-Coding-Agenten unterstützt, und ein Microsoft Azure Static Web Apps Tutorial zeigt die Standard-Verdrahtung: ein GitHub Actions Workflow, der sich bei Pull Request opened, synchronize, reopened und closed auslöst, mit einem separaten Job, um den Preview herunterzureißen. Das ist gewöhnliche Bereitstellungsmaschinerie. Das ist Teil des Reizes.

Warum es sich für Agenten eignet, ist einfach. Jede Änderung ist ein überprüfbares Diff. Nichts erreicht Produktion, bis eine Person merged. Rollback ist ein git revert. Die öffentliche Site ist statische Ausgabe, es gibt also kein Admin-Login, das ein gestohlenes Agent-Token erreichen könnte.

Die Kosten sind aber real. Nicht-technische Redakteure bekommen Reibung, weil Git nicht ihr Werkzeug ist. Nichts hier ist ein dokumentierter MCP-Server mit Sicherheitsbilanz; der Agent ist ein Coding-Agent mit Repo-Zugang, deine Exponierung ist also der Umfang seines Git-Token und alles, was seine Shell anfassen kann. Supply-Chain-Hygiene gilt immer noch. Das habe ich in Next.js, Astro and Nuxt security in 2026 abgedeckt.

MCP-Risiken auf jedem Stack und die Kontrollen, die sie eindämmen

Die NSA veröffentlichte im Juni 2026 ein Cybersecurity Information Sheet zur MCP-Sicherheit, und Microsoft schrieb über den Stand der MCP-Sicherheit in 2026. Die Vokabeln beiseite, vier Risiken tauchen immer wieder auf.

• Geerbte Berechtigungen. Der Agent kann tun, was seine MCP-Server-Anmeldedaten tun können. Ein Admin-Token bedeutet einen Admin-Agent.
• Tool-Vergiftung. Tool-Beschreibungen werden vom Modell gelesen, also kann ein bösartiger oder kompromittierter Server Anweisungen in ihnen verstecken. Deshalb verdienen Drittanbieter-Server vor der Installation eine Überprüfung.
• Prompt-Injection. Inhalte, die der Agent liest (ein Kommentar, eine gescrapte Seite, ein Support-Ticket in einen Entwurf eingefügt), können Anweisungen tragen. Der Agent kann sie mit seinem eigenen Schreibzugriff befolgen.
• Über-privilegierte Token. Komfort drängt Menschen, ein breites Token auszuhändigen. Nicht machen.

Die Kontrollen sind langweilig. Sie funktionieren. Gib dem Agent Least-Privilege-Token, bevorzuge Read-Only- oder Draft-Only-Scopes, und stell menschliche Genehmigung vor Publish und Delete. Behalte Audit-Logs, die du wirklich lesen wirst. Rotiere Token, wenn jemand geht. Nichts davon ist stack-spezifisch, und das ist der Punkt. Der Stack entscheidet nur, wie viel der Arbeit bereits für dich erledigt ist.

Die Agent-Readiness-Bewertungskarte

Hier ist der Vergleich an einer Stelle. Bewertungen stammen aus dokumentierten Funktionen und der öffentlichen Dokumentation, mit den oben genannten Quellen. Niemand hat diese Stacks für diese Tabelle durch eine Test-Suite laufen lassen. Behandeln Sie es als dokumentierten Vergleich, nicht als Laborergebnis.

Stark bedeutet, die Dokumentation deckt es standardmäßig ab. Teilweise bedeutet dokumentiert, aber unvollständig, oder durch nur kurze Belege gestützt. Hängt von der Konfiguration ab bedeutet, der Stack entscheidet nicht. Ihre Konfiguration tut es. Schwach bedeutet dokumentierte Probleme.

Warum jede Bewertung, kurz gefasst.

WordPress + Adapter. Berechtigungen sind stark, weil jede Fähigkeit ihre eigene Prüfung trägt und Fähigkeiten privat sind, bis sie als öffentlich gekennzeichnet werden. Die Entwurfskontrolle hängt von den Fähigkeiten ab, die Sie installieren, wie das gestaffelte Update-Beispiel zeigte. Der Audit ist teilweise: Observability-Schnittstellen existieren, aber ein natives Audit-Log existiert nicht. Authentifizierung ist teilweise, mit dokumentierter Authentifizierung auf hoher Ebene pro Server. Die Bilanz ist teilweise, weil das Paket jung ist und seine Dokumentation sichtbar in Umstrukturierung ist.

WordPress Plugins. Nichts ist einheitlich über eine Kategorie hinweg, daher hängen die meisten Zellen vom Plugin ab. Die Bilanz ist schwach, wo dokumentiert: die AI Engine Einträge oben, und nur diese. Diese Unterscheidung ist wichtig.

Sanity. Mit Rollen umfasste Tokens, Entwürfe als Standard-Schreibweise, Releases und Revisionsverlauf rechtfertigen die starken Bewertungen. Vorschau ist teilweise, weil ein Release ein Staging-Konzept ist, aber der MCP-Server kann Releases nicht planen oder veröffentlichen. Die Bilanz ist teilweise im Sinne von kurz. Nicht schlecht.

Strapi. Pro-Content-Type Tools und Besitzer-gebundene Tokens sind stark bei Berechtigungen und Authentifizierung. Veröffentlichen und Veröffentlichung rückgängig machen sind separate Tools, und der Server bleibt ausgeschaltet, bis Sie ihn einschalten. Audit und Vorschau hängen davon ab, wie Sie Ihre Instanz betreiben. Self-Hosting bedeutet auch, dass Patching Ihre Sache ist.

Contentful. Der offizielle Server benötigt ein Management-Token und eine Space-ID, was sich als breiter Zugriff liest, also bewerte ich Berechtigungen und Authentifizierung als teilweise. Entwurfsverwaltung, Audit und Vorschau hängen davon ab, wie Sie Spaces und Rollen konfigurieren. Die wichtige Arbeit ist in dieser Konfiguration.

Payload. Ein offizielles Plugin existiert. Darüber hinaus habe ich keine primäre Dokumentation zum Bewerten, daher lesen sich alle Zellen als hängt von der Konfiguration ab. Das ist eine Lücke in dem, was ich überprüfen kann. Es ist kein Urteil.

Git-basierter Jamstack. Stark über vier Spalten, weil das Muster sie selbst bietet: Berechtigungen auf Branch-Ebene, ein Pull Request als Publish-Gate, Git-Verlauf und Reverts, Preview-Deploys. Die Authentifizierung hängt vom Code-Agent und seinem Git-Token ab. Der Datensatz ist unvollständig, weil es keine CMS-Admin-Oberfläche zu attackieren gibt. Agent-Tools tragen immer noch die gleichen MCP-Risiken wie alles andere.

Wie Sie heute je nach Situation wählen

Sie haben einen bestehenden WordPress-Bestand

Bleiben Sie dabei und seien Sie streng. Nutzen Sie den offiziellen Adapter, markieren Sie nur die Fähigkeiten, die Sie benötigen, als öffentlich, und schreiben oder wählen Sie Fähigkeiten, die Änderungen vor der Anwendung bereitstellen. Ein breites Third-Party-Plugin mit einem Admin-fähigen Token ist das riskanteste Setup in diesem gesamten Vergleich. Wenn Sie WordPress zuerst vom Front End aus lockern möchten, ist Headless-WordPress-Entwicklung ein Mittelweg.

Sie starten einen neuen Build

Wenn Agenten dabei helfen, ihn zu betreiben, starten Sie mit Headless oder Git-basiert. Sanity oder Strapi geben Ihnen Entwürfe und begrenzte Token ab Werk. Astro oder Next.js in einem Repo geben Ihnen Diffs und Vorschauen. Das ist ein starker Standard für neue Arbeiten.

Ihr Content-Team ist groß oder nicht technisch

Ein Team von Redakteuren, die in einer visuellen Oberfläche arbeiten, wird Pull Requests nicht genießen. Headless mit einem ordentlichen Editing-Studio passt besser zu ihnen, sofern der Agent auf Entwürfe beschränkt ist. Der WordPress-Editor ist hier wirklich gut. Das spricht für ihn.

Sie haben Compliance-Anforderungen

Fragen Sie, wo der Audit Trail lebt und wem er gehört. Git-Verlauf ist eine starke Antwort. Sanitys Revisionsverlauf ist eine andere. Für WordPress müssen Sie Logging selbst bauen. Selbstgehostete Optionen (Strapi, WordPress) halten Daten in Ihrer Infrastruktur, aber legen das Patching auf Sie ab, während ein gehosteter Server diese Last auf den Anbieter verlagert.

Bis 2027: Warum Jamstack das bessere Zuhause für KI-betriebene Websites sein könnte

Dieser Abschnitt ist Meinung, keine Feststellung, und ich halte ihn locker.

Warum Jamstack vorziehen könnte. Inhalte sind strukturiert und typisiert. Jede Agent-Änderung kann ein Diff sein, den ein Mensch überprüft. Preview-Deploys zeigen das Ergebnis, bevor es live geht. Rollback ist ein Git-Revert. Die öffentliche Website hat keine Admin-Oberfläche, die ein gestohlenes Agent-Token erreichen kann. Agenten sind gut beim Bearbeiten von Dateien und schlecht beim Vertrauenswürdigkeit sein, und dieses Setup ist genau für diese Kombination gebaut.

Warum WordPress nicht verlieren kann. Es hat die größte Installationsbasis und den größten Talentpool. Die Abilities API ist jetzt im Kern, mit einem offiziellen Adapter daneben. Plugin-Anbieter iterieren schnell. Schnelle Iteration behebt viel, auch wenn sie die obigen CVEs verursacht hat.

Was WordPress brauchen würde. MCP im Kern, mit Fähigkeiten, die standardmäßig auf Capabilities abgebildet sind. Draft-only Agent-Rollen. Ein natives Audit Log. Eine bessere Sicherheitsbilanz für MCP-Plugins. Das ist eine kurze Liste, und nichts davon ist unmöglich.

Wenn Sie diese Ansicht wägen und einen Umzug in Betracht ziehen, ist der Leitfaden zum Verlassen von WordPress der richtige Anfang.

Praktische Linie: Starten Sie für eine neue Website, auf der Agenten mithelfen, mit Jamstack oder Headless. Für einen bestehenden WordPress-Bestand nutzen Sie den offiziellen Adapter mit Least-Privilege-Fähigkeiten statt eines breiten Third-Party-Plugins. Seien Sie hier langweilig.

FAQ

Kann ich WordPress MCP im schreibgeschützten Modus ausführen?

Ja, theoretisch. Fähigkeiten sind standardmäßig privat, also geben Sie nur die Fähigkeiten frei, die Daten lesen, und lassen Sie alles, das schreibt, unregistriert oder unmarkiert. Der Adapter hat keinen einzelnen schreibgeschützten Schalter. Die Disziplin liegt darin, welche Fähigkeiten Sie registrieren.

Welche KI-Clients können sich verbinden?

Für WordPress alles, das MCP über HTTP oder STDIO spricht (über WP-CLI). Die Dokumentation von Sanity listet Claude Code, Cursor, VS Code, Lovable, Replit und v0 als kompatible Clients auf, und OAuth-Sessions dort verfallen normalerweise nach 7 Tagen. Die Clientwahl ist nicht der schwierige Teil.

Ist ein gehosteter MCP-Server sicherer als ein selbstgehosteter?

Es tauscht ein Risiko gegen ein anderes. Ein gehosteter Server wie der von Sanity verlagert das Patching auf den Anbieter, aber Sie verlassen sich auf deren Scoping und Ihre Token-Hygiene. Ein Server in Ihrer Instanz, wie der von Strapi, hält alles in Ihrer Infrastruktur. Updates sind Ihre Aufgabe.

Sollte ich stattdessen meinen eigenen MCP-Server bauen?

Nur dann, wenn Sie einen engen Satz an Tools benötigen, den die offiziellen nicht bieten. Ein kleiner, speziell angefertigter Server mit drei Tools ist einfacher zu durchdenken als ein breiter. Es gibt eine Anleitung zum Erstellen eines MCP-Servers mit Supabase und TypeScript. Halten Sie die Oberfläche klein.

Die schärfste Warnung ist die alltägliche: Ein Agent erbt alles, was sein Token tun kann, und der einzige öffentliche MCP-Sicherheitseintrag in diesem Vergleich ist die CVE-Liste eines WordPress-Plugins, was Grund genug ist, Token zu begrenzen, bevor Sie einen Stack wählen. Die obigen Bewertungen stammen aus Dokumentation und öffentlichen Hinweisen, nicht aus Tests. Behandeln Sie die Stack-Wahl als nachgeordnet gegenüber dem Berechtigungsmodell.