So stellen Sie eine benutzerdefinierte WordPress Ability über MCP bereit

Eine benutzerdefinierte WordPress Ability kann über einen MCP-Adapter projiziert werden, doch die Transportfreigabe darf ihren Vertrag zu Berechtigungen, Validierung, Nebenwirkungen oder Nachweisen nicht erweitern.

KI ist hier vor allem als Organisator von Nachweisen, Vergleichs-Engine und Schreibassistenz nützlich. Sie kann eine komplexe WordPress-Aufgabe leichter prüfbar machen, aber keine fehlende Autorität schaffen, keine nicht beobachteten Fakten zertifizieren und keine Empfehlung stillschweigend in eine Handlungsberechtigung umwandeln.

In einem Satz: Eine benutzerdefinierte WordPress Ability kann über einen MCP-Adapter projiziert werden, doch die Transportfreigabe darf ihren Vertrag zu Berechtigungen, Validierung, Nebenwirkungen oder Nachweisen nicht erweitern.

Was Ihnen dieser Leitfaden ermöglicht

Eine benutzerdefinierte Ability für MCP-Erkennung und -Ausführung vorbereiten und überprüfen, mit expliziten Schemas, begrenzten Berechtigungen, Negativtests und clientspezifischer Validierung.

• Eine getestete benutzerdefinierte Ability mit stabilem Vertrag.
• Eine Entscheidung zur MCP-Freigabe und ein Konfigurationsprotokoll.
• Nachweise für Erkennungs-, Ausführungs-, Verweigerungs- und fehlerhafte-Eingabe-Tests.
• Clientspezifische Einrichtungsnotizen, die keine universelle Kompatibilität implizieren.

Das fertige Artefakt sollte für die entscheidungsverantwortliche Person verständlich und für jemanden reproduzierbar sein, der nicht am ursprünglichen Prompt beteiligt war. Eine flüssige Antwort genügt nicht. Jede wesentliche Schlussfolgerung braucht eine Quelle, einen Umfang und einen Verifikationsweg. Wenn die Nachweise etwas nicht belegen können, ist die korrekte Ausgabe ein explizites Unbekanntes oder eine testbare Hypothese.

Vorzubereitende Nachweise und Eingaben

• Eine registrierte und getestete WordPress Ability.
• Die aktuelle Dokumentation für den WordPress MCP Adapter und den Client.
• Die Konfiguration für Authentifizierung und WordPress-Identität.
• Sichere lokale oder Staging-Fixtures.
• Die installierte WP Agent Control-Abdeckung, wenn sie die WordPress-Identität bereitstellt.

Entfernen Sie Anmeldedaten, geheime Werte und nicht relevante personenbezogene Daten, bevor Sie Nachweise an einen Assistenten übergeben. Bewahren Sie die Kennungen, Versionen, Zeitstempel, Gebietsschemata, Einheiten und Quellbezeichnungen, die zur Interpretation des Restes erforderlich sind. Ein Screenshot ohne URL, Status oder Datum kann nützlicher Kontext sein, ist aber selten ausreichende Autorität für eine Produktionsentscheidung.

Beginnen Sie nicht mit einer allgemeinen Aufforderung wie „prüfen Sie dies“, „beheben Sie dies“ oder „machen Sie es besser“. Definieren Sie die Entscheidung, die die Arbeit stützen soll, die einbezogene Population, die für jedes Feld maßgebliche Quelle, die zulässigen Vorgänge und die weiterhin verbotenen Aktionen. Für diese Aufgabe sind authentifizierter WordPress-Zugriff oder ein kontrollierter Export erforderlich.

MCP ist Transport und Erkennung

Es hilft einem Client, Tools zu verstehen und aufzurufen. Es ersetzt weder die WordPress-Autorisierung noch die Ability-Validierung oder eine rechenschaftspflichtige Freigabe.

Client-Unterstützung ist spezifisch

Claude Code, Codex und andere Clients können sich bei Konfiguration, Tool-Darstellung, Freigabe-UX und Transportunterstützung unterscheiden. Testen Sie jeden benannten Pfad.

Eine Verweigerung ist Teil des Vertrags

Eine nicht autorisierte Ausführung sollte vorhersehbar fehlschlagen und dokumentiert werden. Erweitern Sie die WordPress-Identität nicht, damit eine Demo gelingt.

Beobachtung, Schlussfolgerung und Autorität getrennt halten

Eine kontrollierte Überprüfung sollte mindestens vier Zustände unterscheiden:

1. Beobachtet: direkt in einem benannten Datensatz, einer Datei, Antwort, gerenderten Seite oder ausgeführten Prüfung vorhanden.
2. Abgeleitet: eine plausible, durch Nachweise gestützte, aber nicht direkt belegte Interpretation.
3. Empfohlen: eine vorgeschlagene menschliche Entscheidung oder nächste Aktion.
4. Autorisiert und überprüft: eine separat genehmigte Änderung, die ausgeführt und anschließend anhand von Akzeptanzkriterien geprüft wurde.

KI-Ausgaben beginnen gewöhnlich in den ersten drei Zuständen. Sie werden nicht allein deshalb autorisiert, weil sie detailliert, intern stimmig oder technisch überzeugend sind. Bewahren Sie diese Unterscheidung in Tabellen, Berichten, Tickets und öffentlichen Fallstudien.

Ein sicherer Workflow

1. Vervollständigen und testen Sie die zugrunde liegende Ability vor der MCP-Freigabe.
2. Bestätigen Sie Adapterversion, Transport und Authentifizierungspfad.
3. Stellen Sie nur die vorgesehene Ability und Metadaten bereit.
4. Verbinden Sie einen sicheren Client mit einer dedizierten WordPress-Identität.
5. Testen Sie Erkennung und eine gültige schreibgeschützte oder begrenzte Fixture.
6. Testen Sie nicht autorisierte, ungültige und außerhalb des Umfangs liegende Anfragen.
7. Protokollieren Sie Client-, Modell-, Adapter-, WordPress- und Plugin-Versionen.
8. Widerrufen Sie die Testidentität und bewahren Sie reproduzierbare Nachweise auf.

Diese Abfolge platziert bewusst eine rechenschaftspflichtige Überprüfung zwischen Analyse und Implementierung. Wenn eine spätere Phase breiteren Zugriff benötigt, erstellen Sie eine neue Aufgabe, eine neue Identität oder eine explizite Berechtigungsänderung. Stufen Sie die analytische Identität nicht stillschweigend hoch, weil sie eine korrekte Grenze erreicht hat.

Prompt-Vorlage

Ersetzen Sie jeden Wert in eckigen Klammern, bevor Sie den Prompt verwenden. Fügen Sie keine Passwörter, API-Schlüssel, Authentifizierungs-Cookies, privaten Kundendatensätze oder nicht relevanten personenbezogenen Daten ein.

Sie prüfen [TASK SCOPE] für [SITE, REPOSITORY OR DATASET] und verwenden dabei nur die bereitgestellten Nachweise.

Ziel:
Eine benutzerdefinierte Ability für MCP-Erkennung und -Ausführung vorbereiten und überprüfen, mit expliziten Schemas, begrenzten Berechtigungen, Negativtests und clientspezifischer Validierung.

Geben Sie die folgenden Felder zurück:
- Ability
- Adapterversion
- Client
- Transport
- Identität
- Berechtigung
- Erkennungsergebnis
- Gültige Ausführung
- Verweigerte Ausführung
- Ungültige Eingabe
- Nachweis
- Bekannte Grenze

Regeln:
1. Stellen Sie Abilities nicht bereit, bevor ihre direkten Tests erfolgreich sind.
2. Bewahren Sie Ability-Namen, Schemas und Kennungen exakt.
3. Behaupten Sie keine Kompatibilität mit ungetesteten Clients oder Versionen.
4. Verwenden Sie Full Power nicht, um eine Verweigerung zu umgehen.
5. Nehmen Sie keine Anmeldedaten in Konfigurationsbeispiele auf.

Für jeden Befund:
- benennen Sie die exakte Quelle, den Datensatz, die URL, Datei, Zeile, Objekt-ID, den Status oder die Dataset-Zeile;
- bewahren Sie Daten, Versionen, Einheiten, Gebietsschemata, Kennungen und Nenner;
- trennen Sie Beobachtung, Schlussfolgerung, Empfehlung und Unbekanntes;
- geben Sie an, welche Nachweise nicht verfügbar waren;
- ändern Sie weder WordPress, Quellcode, Commerce-Daten, Analysen, externe Systeme noch veröffentlichte Inhalte.

Warum dieser Prompt so strukturiert ist

Der Prompt schafft einen Nachweisvertrag, bevor er nach Empfehlungen fragt. Er macht fehlende Daten sichtbar, verringert die Wahrscheinlichkeit, dass ein Modell einen unvollständigen Datensatz mit plausibler Prosa ergänzt, und erzeugt eine Ausgabe, die systematisch überprüft werden kann. Strukturierte Felder erleichtern zudem den Vergleich wiederholter Durchläufe oder die Übergabe einer genehmigten Teilmenge an einen späteren Implementierungsworkflow.

Eine Produktionsimplementierung kann JSON-Schema, typisierte Tool-Eingaben oder automatisierte Validierung hinzufügen. Diese Mechanismen verbessern die Konsistenz, belegen aber nicht, dass der Quellnachweis wahr, vollständig oder aktuell ist. Menschliche Überprüfung und systemspezifische Verifikation bleiben erforderlich.

Empfohlene Zugriffsgrenze

Verwenden Sie für die in diesem Leitfaden beschriebene Phase Hängt von der separat autorisierten Phase ab. Die genauen Fähigkeiten einer Identität müssen aus der installierten Produktversion, dem veröffentlichten Abdeckungsvertrag und der tatsächlich verwendeten Verbindungsmethode hervorgehen.

Was außerhalb dieser Aufgabe bleiben muss

• Produktionsausführung
• Offenlegung von Anmeldedaten
• Breite Tool-Freigabe
• Berechtigungserweiterung
• Behauptungen universeller Kompatibilität

Eine verweigerte Aktion kann ein nützlicher Nachweis dafür sein, dass die Kontrollgrenze funktioniert. Reagieren Sie nicht auf eine erwartete Verweigerung, indem Sie ein weitreichendes Administratorkonto oder Full Power gewähren. Stellen Sie zunächst fest, ob die Aktion überhaupt zum aktuellen Mandat gehört. Wenn ja, erstellen Sie eine separat autorisierte Phase mit der engsten erforderlichen Fähigkeit.

Wie WP Agent Control passt

Der geführte private Ordner für Claude Code oder Codex verwendet WordPress REST und ein Anwendungspasswort mit einem eigenen schreibgeschützten Profil. Bestehende Read Only-, Draft-, Content Editor- und Publisher-Profile bleiben unter den erweiterten Optionen erhalten. Sie werden nicht automatisch in OAuth umgewandelt und übernehmen weder temporäre Remote-Aufgaben noch deren genaue Freigaben.

Rufen Sie nach der Verbindung strukturierte Websiteinformationen ab und untersuchen Sie ausgewählte veröffentlichte Seiten. Dafür ist keine temporäre Aufgabe nötig. Öffentliche Seiten lassen sich auch ohne das Plugin besuchen; Agent Control ergänzt strukturierten Zugriff und den Übergang zu autorisierten WordPress-Arbeiten.

Ihre KI verbinden: docs first profile · Funktionen und Kompatibilität ansehen: coverage

Prüfliste

• ☐ Aufgabe, Population, Zeitraum, Umgebung und Entscheidung sind explizit.
• ☐ Jede wesentliche Beobachtung ist mit einem exakten Nachweis verknüpft oder als Hypothese gekennzeichnet.
• ☐ Stabile IDs, URLs, Versionen, Daten, Einheiten, Gebietsschemata und Nenner bleiben erhalten.
• ☐ Fehlende Nachweise und Abdeckungsgrenzen bleiben sichtbar.
• ☐ Die analytische oder Forschungsidentität führte keine verbotene Mutation aus.
• ☐ Eine qualifizierte verantwortliche Person überprüfte gegebenenfalls Sicherheits-, Zugänglichkeits-, Rechts-, Commerce- oder Release-Auswirkungen.
• ☐ Jede Implementierung hat ein separates Mandat, Zugriffslevel, Backup und einen Verifikationsplan.
• ☐ Temporäre Identitäten, Fixtures und sensible Nachweise werden nach der Aufgabe widerrufen, zurückgesetzt oder entsorgt.

Häufige Fehlermodi

• Transport-zuerst-Entwicklung: Das Team debuggt MCP, während der zugrunde liegende Ability-Vertrag noch instabil ist.
• Übergriffiges Demokonto: Eine weitreichende Administratoridentität verdeckt Berechtigungsfehler und erzeugt unsichere Dokumentation.
• Client-Vermischung: Eine in einem Client getestete Einrichtung wird in einen anderen mit anderer Konfigurationssemantik kopiert.
• Stille Nebenwirkungen: Ein als analytisch beschriebenes Tool verändert WordPress oder ein externes System.

Ein wiederkehrender querschnittlicher Fehler ist Berechtigungsdrift: Die ursprüngliche Aufgabe stößt auf eine Grenze, und der Operator erweitert den Zugriff, bevor er feststellt, ob der fehlende Vorgang notwendig, unterstützt oder sicher ist. Dies zerstört den Nachweiswert der Verweigerung und erschwert die Zuordnung späterer Ergebnisse.

Erweiterter Hinweis

Behandeln Sie MCP als Projektion eines geregelten Ability-Vertrags. Erkennungsmetadaten, Ausführungsautorisierung und beobachtete Rückgabe sollten als getrennte Ebenen getestet werden, damit eine Transportänderung die operative Autorität nicht stillschweigend vergrößern kann.

Verwandte Leitfäden

• Leitfaden zur WordPress Abilities API für KI-Workflows
• Eine WordPress-Berechtigungstestmatrix für KI-Agenten erstellen
• Claude Code mit WordPress verbinden
• So verbinden Sie Codex mit WordPress

Weiter

Fahren Sie mit dem relevantesten unterstützenden Leitfaden fort und verwenden Sie den Leitfaden zu Zugriffsebenen vor jeder authentifizierten Aufgabe. Wenn temporärer WordPress-Zugriff nicht mehr benötigt wird, schließen Sie mit dem Widerruf der Identität ab.