WordPress MCP Server

Dies ist ein Model Context Protocol (MCP)-Server für WordPress, mit dem Sie über einen MCP-kompatiblen Client wie Claude für Desktop auf natürliche Weise mit Ihrer WordPress-Website interagieren können. Dieser Server stellt verschiedene WordPress-Daten und -Funktionen als MCP-Tools bereit.

Verwendung

Claude Desktop

1. Laden Sie Claude Desktop herunter und installieren Sie es.

2. Öffnen Sie die Claude-Desktop-Einstellungen und navigieren Sie zum Reiter „Entwickler".

3. Kopieren Sie den Inhalt der Datei claude_desktop_config.json.example.

4. Klicken Sie auf „Konfiguration bearbeiten", um die Datei claude_desktop_config.json zu öffnen.

5. Fügen Sie den Inhalt der Beispieldatei in die Konfigurationsdatei ein. Ersetzen Sie die Platzhalterwerte durch Ihre tatsächlichen Werte für die WordPress-Website. Um die Anwendungsschlüssel zu generieren, befolgen Sie diese Anleitung – Anwendungskennwörter.

6. Speichern Sie die Konfiguration.

7. Starten Sie Claude Desktop neu.

Related MCP server: WordPress MCP Server

Funktionen

Dieser Server stellt Tools zur Interaktion mit zentralen WordPress-Daten bereit und unterstützt Multi-Site-Verwaltung – verwalten Sie mehrere WordPress-Websites über eine einzige MCP-Serverinstanz.

Multi-Site-Verwaltung (3 Tools)

Verwalten Sie mehrere WordPress-Websites über einen einzigen MCP-Server:

• list_sites: Alle konfigurierten WordPress-Websites auflisten

• get_site: Details zu einer bestimmten Website-Konfiguration abrufen

• test_site: Verbindung zu einer bestimmten WordPress-Website testen

Alle Inhalts- und Taxonomie-Tools unterstützen einen optionalen Parameter site_id, um bestimmte Websites anzusprechen.

Einheitliche Inhaltsverwaltung (9 Tools)

Behandelt ALLE Inhaltstypen (Beiträge, Seiten, benutzerdefinierte Beitragstypen) mit einem einzigen Satz intelligenter Tools:

• list_content: Beliebigen Inhaltstyp mit Filtern und Paginierung auflisten

• get_content: Bestimmten Inhalt nach ID und Typ abrufen

• create_content: Neuen Inhalt beliebigen Typs erstellen

• update_content: Vorhandenen Inhalt beliebigen Typs aktualisieren, einschließlich gezielter Teilbearbeitungen

• delete_content: Inhalt beliebigen Typs löschen

• discover_content_types: Alle verfügbaren Inhaltstypen auf Ihrer Website finden

• find_content_by_url: Intelligenter URL-Auflöser, der Inhalte von jeder WordPress-URL finden und optional aktualisieren kann, einschließlich gezielter Teilbearbeitungen

• get_content_by_slug: Suche nach Slug über alle Inhaltstypen hinweg

• get_content_summary: Gibt eine minimale Zusammenfassung (ID, Titel, Slug, Status, Auszug, Taxonomien, Wortanzahl, Yoast-SEO-Felder) für Audit- und Nachschlage-Workflows zurück. Suche nach id oder url.

Einheitliche Taxonomieverwaltung (8 Tools)

Behandelt ALLE Taxonomien (Kategorien, Schlagwörter, benutzerdefinierte Taxonomien) mit einem einzigen Satz von Tools:

• discover_taxonomies: Alle verfügbaren Taxonomien auf Ihrer Website finden

• list_terms: Begriffe in einer beliebigen Taxonomie auflisten

• get_term: Bestimmten Begriff nach ID abrufen

• create_term: Neuen Begriff in einer beliebigen Taxonomie erstellen

• update_term: Vorhandenen Begriff aktualisieren

• delete_term: Begriff aus einer beliebigen Taxonomie löschen

• assign_terms_to_content: Begriffe einem beliebigen Inhaltstyp zuweisen

• get_content_terms: Alle Begriffe für beliebige Inhalte abrufen

Spezialisierte Tools

• Medien:

  • list_media: Alle Medienelemente auflisten (unterstützt Paginierung und Suche).

  • get_media: Ein bestimmtes Medienelement nach ID abrufen.

  • create_media: Ein neues Medienelement von einer URL oder einem lokalen Dateipfad erstellen.

  • update_media: Ein vorhandenes Medienelement aktualisieren.

  • delete_media: Ein Medienelement löschen.

  • edit_media: Legacy-Alias für update_media, aus Gründen der Abwärtskompatibilität beibehalten.

• Benutzer:

  • list_users: Alle Benutzer mit Filter-, Sortier- und Paginierungsoptionen auflisten.

  • get_user: Einen bestimmten Benutzer nach ID abrufen.

  • create_user: Einen neuen Benutzer erstellen.

  • update_user: Einen vorhandenen Benutzer aktualisieren.

  • delete_user: Einen Benutzer löschen.

• Kommentare:

  • list_comments: Alle Kommentare mit Filter-, Sortier- und Paginierungsoptionen auflisten.

  • get_comment: Einen bestimmten Kommentar nach ID abrufen.

  • create_comment: Einen neuen Kommentar erstellen.

  • update_comment: Einen vorhandenen Kommentar aktualisieren.

  • delete_comment: Einen Kommentar löschen.

• Plugins:

  • list_plugins: Alle auf der Website installierten Plugins auflisten.

  • get_plugin: Details zu einem bestimmten Plugin abrufen.

  • activate_plugin: Ein Plugin aktivieren.

  • deactivate_plugin: Ein Plugin deaktivieren.

  • create_plugin: Ein neues Plugin erstellen.

• Plugin-Repository:

• search_plugins: Im WordPress.org-Repository nach Plugins suchen.

• get_plugin_info: Detaillierte Informationen zu einem Plugin aus dem Repository abrufen.

• Datenbankabfragen:

• execute_sql_query: Schreibgeschützte SQL-Abfragen gegen die WordPress-Datenbank ausführen (erfordert ein benutzerdefiniertes Endpunkt-Setup).

Wesentliche Vorteile

Medien-Upload-Workflows

Laden Sie einen lokalen Screenshot von demselben Computer hoch, auf dem der MCP-Server läuft:

{
  "file_path": "./screenshots/homepage.png",
  "title": "Homepage Screenshot",
  "alt_text": "Homepage screenshot showing the hero section"
}

Laden Sie Medien von einer entfernten URL hoch:

{
  "source_url": "https://example.com/assets/hero-image.png",
  "title": "Hero Image",
  "caption": "Imported from the design system"
}

Verwenden Sie die zurückgegebene Medien-ID als Beitragsbild für neue Inhalte:

{
  "content_type": "post",
  "title": "Release Notes",
  "content": "<p>Launch summary...</p>",
  "featured_media": 123
}

Intelligente URL-Auflösung

Das Tool find_content_by_url kann:

• Jede WordPress-URL nehmen und automatisch den entsprechenden Inhalt finden

• Inhaltstypen anhand von URL-Mustern erkennen (z. B. /dokumentation/ → benutzerdefinierter Beitragstyp „Dokumentation")

• Den Inhalt optional in einem einzigen Vorgang aktualisieren

• Funktioniert mit Beiträgen, Seiten und allen benutzerdefinierten Beitragstypen

Audit- und Nachschlage-Zusammenfassungen

Das Tool get_content_summary gibt eine minimale Darstellung mit fester Form eines einzelnen Inhaltselements zurück. Es wurde für Audit- und Nachschlage-Workflows entwickelt, bei denen die vollständige WP-REST-Antwort – die bei Rezeptbeiträgen aufgrund des gerenderten Recipe-Maker-Karten-HTMLs mehr als 50 KB überschreiten kann – übertrieben ist.

Suche nach ID (mit optionalem content_type, standardmäßig post):

{
  "id": 4274,
  "content_type": "post"
}

Suche nach URL (der Inhaltstyp wird anhand der URL erkannt):

{
  "url": "https://example.com/blog/easy-smoked-asparagus/"
}

id und url schließen sich gegenseitig aus – geben Sie genau eines davon an.

Die Form der Antwort ist festgelegt:

{
  "id": 4274,
  "title": "Easy Smoked Asparagus & Hot Honey",
  "slug": "easy-smoked-asparagus",
  "status": "publish",
  "link": "https://example.com/blog/easy-smoked-asparagus/",
  "excerpt": "Smoky asparagus with hot honey.",
  "date_modified": "2026-04-30T10:14:00",
  "categories": [12, 7],
  "tags": [33],
  "featured_media": 9012,
  "word_count": 875,
  "yoast_focus_keyword": "smoked asparagus",
  "yoast_meta_title": "Easy Smoked Asparagus | Example",
  "yoast_meta_description": "Smoky charred asparagus finished with chili-lime hot honey."
}

Hinweise zu den Feldern:

• title und excerpt werden auf reinen Text reduziert (HTML-Tags entfernt, grundlegende Entitäten dekodiert).

• word_count bevorzugt yoast_head_json.schema.@graph[].wordCount, wenn Yoast SEO aktiv ist; andernfalls wird es aus dem gerenderten Beitragsinhalt ohne HTML berechnet.

• yoast_meta_title und yoast_meta_description werden aus yoast_head_json des Beitrags gelesen. Sie sind null, wenn Yoast SEO nicht aktiv ist.

• yoast_focus_keyword wird aus meta._yoast_wpseo_focuskw gelesen. WordPress Core legt nur Metaschlüssel offen, die mit show_in_rest registriert sind, und Yoast SEO registriert diesen Schlüssel standardmäßig nicht – daher ist dieses Feld normalerweise null, sofern es nicht von einem Begleit-Plugin registriert wird (siehe PR #17 für den Kontext zum breiteren Problem der REST-Offenlegung von Metaschlüsseln).

• Dieses Tool umgeht intern das in PR #16 hinzugefügte Kürzen der Antwort, um yoast_head_json lesen zu können. Die Kürzung gilt weiterhin für alle anderen Tools.

Universelle Inhaltsoperationen

Alle Inhaltsoperationen verwenden einen einzigen Parameter content_type:

{
  "content_type": "post", // for blog posts
  "content_type": "page", // for static pages
  "content_type": "product", // for WooCommerce products
  "content_type": "documentation" // for custom post types
}

Gezielte Inhaltsbearbeitungen

update_content und find_content_by_url.update_fields können den vorhandenen rohen WordPress-Inhalt patchen, ohne das gesamte Dokument erneut zu senden.

Um den exakten Abgleich zu erleichtern, akzeptieren sowohl get_content als auch find_content_by_url den Parameter include_raw_content: true. Wenn diese Option aktiviert ist, wird die Antwort mit dem WordPress-Bearbeitungskontext abgerufen und enthält ein Feld content_raw auf oberster Ebene, das dem entspricht, was content_edit.target_text benötigt.

{
  "content_type": "page",
  "id": 7,
  "include_raw_content": true
}

Hängen Sie eine kurze Versionshinweis am Ende eines Beitrags an:

{
  "content_type": "post",
  "id": 42,
  "content_edit": {
    "operation": "append",
    "value": "\n<p>Update: Early access is now open.</p>",
    "content_format": "html"
  }
}

Ersetzen Sie ein eindeutiges HTML-Fragment oder einen Markierungskommentar an Ort und Stelle:

{
  "content_type": "page",
  "id": 7,
  "content_edit": {
    "operation": "replace",
    "target_text": "<!-- pricing-card -->\n<p>Old price</p>\n<!-- /pricing-card -->",
    "value": "<!-- pricing-card -->\n<p>New price</p>\n<!-- /pricing-card -->",
    "content_format": "html"
  }
}

Hinweise:

• Gerendertes WordPress-HTML kann sich von content.raw unterscheiden, da Entitäten maskiert und Markup erweitert werden kann. Verwenden Sie daher include_raw_content, wenn Sie einen exakten target_text benötigen.

• target_text muss exakt mit dem gespeicherten rohen WordPress-Inhalt übereinstimmen.

• Wenn derselbe target_text mehrmals vorkommt, übergeben Sie occurrence, um das 1-basierte Vorkommen auszuwählen.

• Für Beiträge, die als Gutenberg-Blöcke gespeichert sind, setzen Sie content_edit.convert_to_blocks, wenn Sie Markdown oder HTML einfügen, das zu Blöcken werden soll.

Universelle Taxonomieoperationen

Alle Taxonomieoperationen verwenden einen einzigen Parameter taxonomy:

{
  "taxonomy": "category", // for categories
  "taxonomy": "post_tag", // for tags
  "taxonomy": "product_category", // for WooCommerce
  "taxonomy": "skill" // for custom taxonomies
}

Der Parameter taxonomy akzeptiert entweder den Taxonomie-Slug oder dessen rest_base (diese können sich bei benutzerdefinierten Taxonomien unterscheiden, z. B. Slug dokumentations_kategorie mit rest_base dokumentations-kategorien). Die Tools lösen die Kennung über /wp/v2/taxonomies auf und melden bei unbekannten Taxonomien einen Fehler, anstatt zu raten. assign_terms_to_content überprüft den Schreibvorgang anhand der WordPress-Antwort und meldet einen Fehler, wenn die Begriffe nicht tatsächlich gespeichert wurden.

Rezeptkarten (WP Recipe Maker)

Websites mit WP Recipe Maker (WPRM) speichern Rezeptkarten im benutzerdefinierten Beitragstyp wprm_recipe, auf den per Shortcode aus dem umgebenden Blogbeitrag verwiesen wird. Die einheitlichen Inhaltstools verarbeiten diese Rezepte direkt – es ist keine rezeptspezifische Tool-Familie erforderlich.

Rezepte lesen – get_content, list_content, find_content_by_url und get_content_by_slug funktionieren alle mit content_type: "wprm_recipe". WPRM stellt die vollständige strukturierte Rezeptdaten als Feld recipe in der REST-Antwort bereit, einschließlich Zutaten, Anleitung, Zeiten, Ausrüstung, Nährwerten, Notizen und Bewertung.

Rezepte schreiben – Übergeben Sie die Rezeptdaten über custom_fields.recipe an create_content oder update_content. WPRM greift in die WordPress-REST-Einfügeaktion (rest_insert_wprm_recipe) ein und liest recipe aus dem Stammverzeichnis des Anforderungstexts. Daher wird jedes Feld akzeptiert, das vom WPRM-Datenmodell dokumentiert ist.

Die recipe-Daten müssen über custom_fields übergeben werden (die im Stammverzeichnis des Anforderungstexts verteilt werden). Der Parameter meta verschachtelt seine Werte unter einem meta-Schlüssel, der den REST-Hook von WPRM nie erreicht.

Beispiel für eine Aktualisierung:

{
  "content_type": "wprm_recipe",
  "id": 4274,
  "custom_fields": {
    "recipe": {
      "name": "Easy Smoked Asparagus",
      "summary": "Smoky asparagus with hot honey.",
      "servings": "4",
      "servings_unit": "people",
      "prep_time": "5",
      "cook_time": "60",
      "total_time": "65",
      "ingredients": [
        {
          "name": "",
          "ingredients": [
            { "uid": 0, "amount": "1", "unit": "Bunch", "name": "Asparagus Spears", "notes": "" },
            { "uid": 1, "amount": "1", "unit": "tbsp", "name": "Olive Oil", "notes": "" }
          ]
        }
      ],
      "instructions": [
        {
          "name": "",
          "instructions": [
            { "uid": 0, "name": "", "text": "Preheat smoker to 225°F.", "ingredients": [] },
            { "uid": 1, "name": "", "text": "Drizzle with oil, season, smoke 1 hour.", "ingredients": [] }
          ]
        }
      ],
      "notes": "Thicker spears need more time."
    }
  }
}

Gruppierte Zutaten und Anleitungen – Rezepte können Elemente in benannte Gruppen aufteilen, z. B. „Für die Soße" / „Für das Hähnchen". Jeder Eintrag im äußeren Array ingredients (bzw. instructions) ist eine Gruppe mit eigenem name und innerem Array:

{
  "ingredients": [
    { "name": "For the sauce",   "ingredients": [ /* items */ ] },
    { "name": "For the chicken", "ingredients": [ /* items */ ] }
  ]
}

Häufig verwendete Rezeptfelder:

Gang, Küche und Schlüsselwort werden als WPRM-Taxonomien gespeichert (wprm_course, wprm_cuisine, wprm_keyword). Verwalten Sie sie mit den einheitlichen Taxonomie-Tools (list_terms, create_term, …) und verknüpfen Sie sie mit assign_terms_to_content mit einem Rezept.

WPRM synchronisiert recipe.summary beim Speichern automatisch zurück in das WordPress-Feld post_content. Wenn Sie möchten, dass sich der Beitragstext und die Rezeptzusammenfassung unterscheiden, übergeben Sie content explizit zusammen mit custom_fields.recipe.

Konfiguration

Einzelne-Website-Konfiguration

Für die Verwaltung einer einzelnen WordPress-Website verwenden Sie die folgenden Umgebungsvariablen:

WORDPRESS_API_URL=https://your-wordpress-site.com
WORDPRESS_USERNAME=wp_username
WORDPRESS_PASSWORD=wp_app_password

Multi-Site-Konfiguration

Um mehrere WordPress-Websites über einen einzigen MCP-Server zu verwalten, verwenden Sie nummerierte Umgebungsvariablen:

# Site 1 (Production)
WORDPRESS_1_URL=https://production-site.com
WORDPRESS_1_USERNAME=admin
WORDPRESS_1_PASSWORD=app_password_1
WORDPRESS_1_ID=production
WORDPRESS_1_DEFAULT=true
WORDPRESS_1_ALIASES=prod,main

# Site 2 (Staging)
WORDPRESS_2_URL=https://staging-site.com
WORDPRESS_2_USERNAME=admin
WORDPRESS_2_PASSWORD=app_password_2
WORDPRESS_2_ID=staging
WORDPRESS_2_ALIASES=stage,dev

# Site 3 (Development)
WORDPRESS_3_URL=https://dev-site.com
WORDPRESS_3_USERNAME=admin
WORDPRESS_3_PASSWORD=app_password_3
WORDPRESS_3_ID=development

Optionen für die Multi-Site-Konfiguration:

• WORDPRESS_N_URL: WordPress-Website-URL (erforderlich)

• WORDPRESS_N_USERNAME: WordPress-Benutzername (erforderlich)

• WORDPRESS_N_PASSWORD: WordPress-Anwendungspasswort (erforderlich)

• WORDPRESS_N_ID: Website-Kennung (optional, Standardwert siteN)

• WORDPRESS_N_DEFAULT: Auf true setzen, um dies zur Standard-Website zu machen (optional, erste Website ist Standard)

• WORDPRESS_N_ALIASES: Durch Kommas getrennte Aliase für die Website-Erkennung (optional)

Der Server unterstützt bis zu 10 Websites. Bei Verwendung einer Multi-Site-Konfiguration akzeptieren alle Tools einen optionalen Parameter site_id, um bestimmte Websites anzusprechen.

Verwendung mit npx und .env-Datei

Sie können diesen MCP-Server direkt mit npx ausführen, ohne ihn global zu installieren:

npx -y @instawp/mcp-wp

Stellen Sie sicher, dass Sie eine .env-Datei in Ihrem aktuellen Verzeichnis mit den folgenden Variablen haben:

WORDPRESS_API_URL=https://your-wordpress-site.com
WORDPRESS_USERNAME=wp_username
WORDPRESS_PASSWORD=wp_app_password

# Optional: Custom SQL query endpoint (default: /mcp/v1/query)
WORDPRESS_SQL_ENDPOINT=/mcp/v1/query

# Optional: Comma-separated list of top-level fields to strip from
# WordPress REST API responses before they are returned to the MCP
# client. Defaults to "yoast_head,yoast_head_json" — read-only schema
# markup that adds ~10KB to every response but is rarely useful to the
# LLM. Set to an empty string to disable trimming.
MCP_WP_STRIP_FIELDS=yoast_head,yoast_head_json

User-Agent

Jede ausgehende Anfrage, die dieser Server stellt – der WordPress-REST-Client, der von allen Tools verwendet wird, der SQL-Endpunkt, die beiden api.wordpress.org-Abfragen und Remote-Medien-Downloads – sendet den Standard-User-Agent axios/<version> von axios.

Setzen Sie WORDPRESS_USER_AGENT, um ihn überall zu überschreiben:

WORDPRESS_USER_AGENT=MyAgency-MCP/1.0 (+https://example.com)

Lassen Sie es ungesetzt, es sei denn, ein CDN oder eine WAF vor Ihrer Website lehnt den Standard ab; ein leerer oder nur aus Leerzeichen bestehender Wert wird als ungesetzt behandelt. Vermeiden Sie ein nacktes Mozilla/5.0 – es ist eine bekannte Bot-Signatur und genau das, was mehrere Edge-Server blockieren (siehe #28), weshalb hier nichts dergleichen gesendet wird.

Antwort-Kürzung

Standardmäßig entfernt der Server die Felder der obersten Ebene yoast_head und yoast_head_json aus jeder WordPress-REST-API-Antwort, bevor er sie an den MCP-Client zurückgibt. Diese Felder enthalten Yoast SEOs vorgerendertes Schema-Markup, das das LLM fast nie benötigt, aber bei jeder Anfrage Tokens kostet.

• Die Kürzung gilt sowohl für Einzelobjekt-Antworten als auch für Arrays von Objekten.

• Nur Felder der obersten Ebene werden entfernt; verschachtelte Objekte bleiben unberührt.

• Überschreiben Sie die Liste mit der Umgebungsvariablen MCP_WP_STRIP_FIELDS (durch Kommas getrennt). Setzen Sie sie auf eine leere Zeichenfolge, um die Kürzung vollständig zu deaktivieren.

Einschränkungen bei Meta-Feldern

Der Parameter meta bei create_content, update_content und find_content_by_url (mit update_fields.meta) wird direkt an den WordPress-Endpunkt /wp/v2/{type}/{id} weitergeleitet. Der WordPress-Kern verwirft stillschweigend jeden Meta-Schlüssel, der nicht über register_post_meta(..., ['show_in_rest' => true]) registriert wurde. Der MCP-Server hat keine eigene Zulassungsliste – er verlässt sich darauf, dass WordPress durchsetzt, welche Schlüssel persistent gespeichert werden.

Das bedeutet, dass SEO-Plugin-Schlüssel standardmäßig nicht über diesen MCP-Server beschreibbar sind, einschließlich:

• Yoast SEO: _yoast_wpseo_* (focuskw, metadesc, title, opengraph-, twitter-, canonical, meta-robots-*, primary_category, …)

• Rank Math: rank_math_* (title, description, focus_keyword, robots, facebook_, twitter_, primary_category, …)

• All in One SEO (v4+): speichert SEO-Daten in einer eigenen Tabelle (wp_aioseo_posts), nicht in wp_postmeta – auf keine Weise über das meta-Feld adressierbar.

Der Server erkennt, wenn WordPress Schlüssel, die Sie gesendet haben, verworfen hat, und stellt dem Tool-Ergebnis einen Warning:-Block voran, der diese auflistet. Dadurch wird das stille Verwerfen für den LLM-Aufrufer sichtbar, aber WordPress kann nicht dazu gebracht werden, die Schlüssel zu akzeptieren.

Um SEO-Meta-Schreibvorgänge zu ermöglichen, installieren Sie ein kleines WordPress-Begleit-Plugin, das register_post_meta für jeden gewünschten Schlüssel mit show_in_rest => true und einem geeigneten auth_callback aufruft. Ein separates Plugin mcp-wp-seo-bridge wird derzeit konzipiert, um genau dies zu tun.

Welche Schlüssel funktionieren HEUTE

Plugin-Schlüssel, die der Plugin-Autor bereits für REST registriert hat – zum Beispiel Genesis-Layout-Meta (_genesis_layout), WP-Recipe-Maker-Felder (wprm-*) oder ConvertKits _wp_convertkit_post_meta. Um zu prüfen, welche Schlüssel auf Ihrer Website hin- und zurückübertragen werden, schreiben Sie über update_content einen Testwert und prüfen Sie den meta-Block in der Antwort – wenn der Schlüssel erscheint, wurde er gespeichert.

Die gleiche Einschränkung gilt für Term-Meta bei den unified-taxonomies-Tools (create_term, update_term).

Aktivieren des SQL-Abfragetools (optional)

Das Tool execute_sql_query ermöglicht es Ihnen, schreibgeschützte SQL-Abfragen gegen Ihre WordPress-Datenbank auszuführen. Dies ist eine optionale Funktion, die das Hinzufügen eines benutzerdefinierten REST-API-Endpunkts zu Ihrer WordPress-Website erfordert.

Sicherheitshinweise:

• Dieses Tool akzeptiert aus Sicherheitsgründen nur schreibgeschützte Abfragen (SELECT, WITH...SELECT, EXPLAIN)

• Abfragen, die INSERT, UPDATE, DELETE, DROP oder andere ändernde Anweisungen enthalten, werden abgelehnt

• Mehrfachanweisungs-Abfragen werden blockiert, um SQL-Injection zu verhindern

• Abfragen und Ergebnisse werden in logs/wordpress-api.log protokolliert – vermeiden Sie sensible Daten in Abfragen

• Dieses Tool erfordert Berechtigungen auf Admin-Ebene (Fähigkeit manage_options)

Konfiguration: Standardmäßig erwartet das Tool den Endpunkt unter /mcp/v1/query. Sie können dies anpassen, indem Sie die Umgebungsvariable WORDPRESS_SQL_ENDPOINT setzen (z. B. WORDPRESS_SQL_ENDPOINT=/custom/v1/query).

Um diese Funktion zu aktivieren, fügen Sie Ihrer WordPress-Website den folgenden Code hinzu (über ein benutzerdefiniertes Plugin oder die functions.php Ihres Themes):

add_action('rest_api_init', function() {
    register_rest_route('mcp/v1', '/query', array(
        'methods' => 'POST',
        'callback' => function($request) {
            global $wpdb;

            $query = $request->get_param('query');

            // Additional security check
            if (!current_user_can('manage_options')) {
                return new WP_Error('unauthorized', 'Unauthorized', array('status' => 401));
            }

            // Only allow SELECT queries
            if (stripos(trim($query), 'SELECT') !== 0) {
                return new WP_Error('invalid_query', 'Only SELECT queries allowed', array('status' => 400));
            }

            $results = $wpdb->get_results($query, ARRAY_A);

            if ($wpdb->last_error) {
                return new WP_Error('query_error', $wpdb->last_error, array('status' => 400));
            }

            return array(
                'results' => $results,
                'num_rows' => count($results)
            );
        },
        'permission_callback' => function() {
            return current_user_can('manage_options');
        }
    ));
});

Nachdem Sie diesen Code hinzugefügt haben, können Sie das Tool execute_sql_query verwenden, um Abfragen wie die folgenden auszuführen:

SELECT * FROM wp_posts WHERE post_type = 'post' AND post_status = 'publish' LIMIT 10

Entwicklung

Voraussetzungen

• Node.js und npm: Stellen Sie sicher, dass Node.js (Version 18 oder höher) und npm installiert sind. Node 18 reicht aus, um den Server auszuführen. Für Beiträge wird Node 20 oder neuer benötigt, da die Test-Tooling (Vitest 4) dies erfordert – CI läuft mit 20.x und 22.x.

• WordPress-Website: Sie benötigen eine aktive WordPress-Website mit aktivierter REST-API.

• WordPress-API-Authentifizierung: Richten Sie die Authentifizierung für die WordPress-REST-API ein. Dies erfordert in der Regel ein Authentifizierungs-Plugin oder eine Methode (wie Anwendungspasswörter).

• MCP-Client: Sie benötigen eine Anwendung, die mit dem MCP-Server kommunizieren kann. Derzeit wird Claude Desktop empfohlen.

Installation und Einrichtung

1. Repository klonen:

   git clone <repository_url>
   cd wordpress-mcp-server

2. Abhängigkeiten installieren:

   npm install

3. Eine .env-Datei erstellen:

   Erstellen Sie eine .env-Datei im Stammverzeichnis Ihres Projektverzeichnisses und fügen Sie Ihre WordPress-API-Anmeldedaten hinzu.

   Für eine einzelne Website:

   WORDPRESS_API_URL=https://your-wordpress-site.com
   WORDPRESS_USERNAME=wp_username
   WORDPRESS_PASSWORD=wp_app_password

   Für mehrere Websites:

   WORDPRESS_1_URL=https://site1.com
   WORDPRESS_1_USERNAME=admin
   WORDPRESS_1_PASSWORD=app_password_1
   WORDPRESS_1_ID=site1
   WORDPRESS_1_DEFAULT=true
   
   WORDPRESS_2_URL=https://site2.com
   WORDPRESS_2_USERNAME=admin
   WORDPRESS_2_PASSWORD=app_password_2
   WORDPRESS_2_ID=site2

   Ersetzen Sie die Platzhalter durch Ihre tatsächlichen Werte.

4. Server erstellen:

   npm run build

5. Claude Desktop konfigurieren:

   • Öffnen Sie die Claude-Desktop-Einstellungen und navigieren Sie zum Tab „Developer".

   • Klicken Sie auf „Edit Config", um die Datei claude_desktop_config.json zu öffnen.

   • Fügen Sie unter dem Abschnitt mcpServers eine neue Serverkonfiguration hinzu. Sie müssen den absoluten Pfad zur Datei build/server.js und Ihre WordPress-Umgebungsvariablen angeben.

   • Speichern Sie die Konfiguration.

Server ausführen

Sobald Sie Claude Desktop konfiguriert haben, sollte der Server automatisch starten, wann immer Claude Desktop startet.

Sie können den Server auch direkt über die Befehlszeile zum Testen ausführen:

npm start

oder im Entwicklungsmodus:

npm run dev

Tests ausführen

Das Repository verwendet Vitest für Unit-Tests. Die Tests befinden sich unter tests/ und decken den Multi-Site-SiteManager und die MCP-Tool-Registry-Verdrahtung ab.

npm test          # one-shot run
npm run test:watch  # watch mode

Tests laufen bei pull_request und bei Pushes auf main über .github/workflows/test.yml.

Veröffentlichung

Das Zusammenführen eines Fixes erreicht niemanden – npm liefert weiterhin die zuletzt veröffentlichte Version aus, bis eine Veröffentlichung läuft. Die Veröffentlichung wird durch .github/workflows/release.yml automatisiert, ausgelöst durch einen Versions-Tag:

# on main, with the fix already merged:
# 1. move the CHANGELOG's [Unreleased] block under a `[x.y.z] - <date>` heading and commit it
# 2. bump and tag — `npm version` writes package.json, commits, and creates the vx.y.z tag
npm version patch          # or minor / major
# 3. push the commit and the tag; the tag is what triggers the publish
git push origin main --follow-tags

Bearbeiten Sie den CHANGELOG vor npm version. Wenn Sie den Commit danach ändern, zeigt der Tag auf den Commit vor der Änderung, und der Workflow würde von diesem aus veröffentlichen.

Der Workflow weigert sich zu veröffentlichen, wenn Tag und package.json nicht übereinstimmen oder wenn diese Version bereits auf npm vorhanden ist; er erstellt dann, führt die Tests aus, veröffentlicht mit Provenance und bestätigt, dass die Registry tatsächlich die neue Version ausliefert, bevor er Erfolg meldet.

Wenn ein Tag existiert, aber die Veröffentlichung fehlgeschlagen ist (oder vor diesem Workflow liegt), führen Sie ihn erneut aus über Actions → Release → Run workflow, lassen Sie die Branch-Auswahl auf main (dort wird die Workflow-Datei gelesen) und übergeben Sie den Tag-Namen in der Eingabe. Zwei Einschränkungen: Der Baum des Tags muss bereits das unten beschriebene Feld repository enthalten, und die Provenance-Bescheinigung zeichnet den Ref auf, von dem der Workflow ausgelöst wurde, nicht den Tag – für eine echte Veröffentlichung ziehen Sie es daher vor, eine Version neu zu schneiden und den Tag-Push-Pfad zu verwenden.

Wenn die Veröffentlichung erfolgreich ist, aber der Verifizierungsschritt rot wird (eine Registry, die länger als zwei Minuten langsam blieb), prüfen Sie npmjs.com, bevor Sie etwas tun: Die Version ist veröffentlicht, und ein erneuter Lauf wird nun wie vorgesehen an der bereits-auf-npm-Schutzfunktion scheitern. In diesem Fall muss nichts repariert werden.

Einrichtung, einmalig: Der Workflow benötigt ein npm-Automatisierungstoken mit Veröffentlichungsrechten für den @instawp-Bereich, gespeichert als Repository-Secret NPM_TOKEN (Settings → Secrets and variables → Actions). Ein Automatisierungs-Token im Speziellen – ein klassisches Veröffentlichungstoken schlägt in CI auf einem 2FA-erzwungenen Konto fehl.

npms Trusted Publishing würde das gespeicherte Token vollständig entfernen, aber es benötigt npm ≥ 11.5.1 und setup-node liefert derzeit npm 10.x mit Node 22 aus, daher ist es hier nicht nutzbar, ohne auch npm innerhalb des Jobs zu aktualisieren.

Das Veröffentlichen mit Provenance erfordert, dass das Feld repository in package.json mit diesem Repository übereinstimmt – die Registry lehnt die Veröffentlichung andernfalls ab. Entfernen Sie es nicht.

Sicherheit

• Übertragen Sie Ihre API-Schlüssel oder Geheimnisse niemals an die Versionskontrolle.

• Verwenden Sie HTTPS für die Kommunikation zwischen Client und Server.

• Validieren Sie alle vom Client empfangenen Eingaben, um Injection-Angriffe zu verhindern.

• Implementieren Sie eine ordnungsgemäße Fehlerbehandlung und Ratenbegrenzung.

Projektübersicht

Architektur

Der Server verwendet eine einheitliche Tool-Architektur, um die Komplexität zu reduzieren:

src/
├── server.ts                    # MCP server entry point
├── wordpress.ts                 # WordPress REST API client
├── cli.ts                      # CLI interface
├── config/
│   └── site-manager.ts         # Multi-site management
├── types/
│   └── wordpress-types.ts      # TypeScript definitions
└── tools/
    ├── index.ts                # Tool aggregation
    ├── site-management.ts      # Site management (3 tools)
    ├── unified-content.ts      # Universal content management (8 tools)
    ├── unified-taxonomies.ts   # Universal taxonomy management (8 tools)
    ├── media.ts               # Media management (5 canonical tools + edit_media alias)
    ├── users.ts               # User management (~5 tools)
    ├── comments.ts            # Comment management (~5 tools)
    ├── plugins.ts             # Plugin management (~5 tools)
    ├── plugin-repository.ts   # WordPress.org plugin search (~2 tools)
    └── sql-query.ts           # Database queries (1 tool)

Hauptfunktionen

• Multi-Site-Unterstützung: Verwalten Sie mehrere WordPress-Websites von einer einzigen MCP-Serverinstanz aus

• Intelligente URL-Auflösung: Automatische Erkennung von Inhaltstypen aus URLs und Auffinden der entsprechenden Inhalte

• Universelles Inhaltsmanagement: Ein einziges Toolset verwaltet Beiträge, Seiten und benutzerdefinierte Beitragstypen

• Universelles Taxonomie-Management: Ein einziges Toolset verwaltet Kategorien, Tags und benutzerdefinierte Taxonomien

• Typsicherheit: Vollständige TypeScript-Unterstützung mit Zod-Schema-Validierung

• Umfassende Protokollierung: Detaillierte API-Anfrage-/Antwortprotokollierung für die Fehlersuche

• Fehlerbehandlung: Sanfte Fehlerbehandlung mit informativen Meldungen

Erste Schritte

1. Klonen Sie das Repository und installieren Sie die Abhängigkeiten mit npm install

2. Erstellen Sie eine .env-Datei mit Ihren WordPress-Anmeldedaten

3. Erstellen Sie das Projekt mit npm run build

4. Konfigurieren Sie Claude Desktop mit dem Server

5. Beginnen Sie, Ihre WordPress-Website mit natürlicher Sprache zu verwalten!

Beiträge

Sie können gerne Issues eröffnen oder Pull Requests einreichen, um dieses Projekt zu verbessern. Schauen Sie sich CLAUDE.md für detaillierte Entwicklungsrichtlinien an.