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 in natürlicher Sprache mit Ihrer WordPress-Site 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 zur Registerkarte „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-Site. Um die Anwendungsschlüssel zu generieren, folgen Sie dieser Anleitung – Anwendungspasswö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 den WordPress-Kerndaten bereit und unterstützt Multi-Site-Verwaltung – verwalten Sie mehrere WordPress-Sites von einer einzigen MCP-Serverinstanz aus.

Multi-Site-Verwaltung (3 Tools)

Verwalten Sie mehrere WordPress-Sites von einem einzigen MCP-Server aus:

• list_sites: Alle konfigurierten WordPress-Sites auflisten

• get_site: Details zu einer bestimmten Site-Konfiguration abrufen

• test_site: Verbindung zu einer bestimmten WordPress-Site testen

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

Einheitliche Inhaltsverwaltung (9 Tools)

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

• list_content: Beliebigen Inhaltstyp mit Filterung 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 Site finden

• find_content_by_url: Intelligenter URL-Auflöser, der Inhalte aus 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, title, slug, status, excerpt, taxonomies, word count, Yoast-SEO-Felder) für Audit- und Nachschlage-Workflows zurück. Nachschlagen per id oder url.

Einheitliche Taxonomie-Verwaltung (8 Tools)

Behandelt ALLE Taxonomien (Kategorien, Tags, benutzerdefinierte Taxonomien) mit einem einzigen Satz von Tools:

• discover_taxonomies: Alle verfügbaren Taxonomien auf Ihrer Site 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: Bestimmtes Medienelement nach ID abrufen.

  • create_media: Neues Medienelement aus einer URL oder einem lokalen Dateipfad erstellen.

  • update_media: Vorhandenes Medienelement aktualisieren.

  • delete_media: Medienelement löschen.

  • edit_media: Legacy-Alias für update_media, aus Kompatibilitätsgründen beibehalten.

• Benutzer:

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

  • get_user: Bestimmten Benutzer nach ID abrufen.

  • create_user: Neuen Benutzer erstellen.

  • update_user: Vorhandenen Benutzer aktualisieren.

  • delete_user: Benutzer löschen.

• Kommentare:

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

  • get_comment: Bestimmten Kommentar nach ID abrufen.

  • create_comment: Neuen Kommentar erstellen.

  • update_comment: Vorhandenen Kommentar aktualisieren.

  • delete_comment: Kommentar löschen.

• Plugins:

  • list_plugins: Alle auf der Site installierten Plugins auflisten.

  • get_plugin: Details zu einem bestimmten Plugin abrufen.

  • activate_plugin: Plugin aktivieren.

  • deactivate_plugin: Plugin deaktivieren.

  • create_plugin: Neues Plugin erstellen.

• Plugin-Repository:

• search_plugins: Plugins im WordPress.org-Repository durchsuchen.

• 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 benutzerdefinierten Endpunkt).

Wichtigste Vorteile

Medien-Upload-Workflows

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

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

Medien von einer entfernten URL hochladen:

{
  "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 aus URL-Mustern erkennen (z. B. /documentation/ → benutzerdefinierter Inhaltstyp documentation)

• Den Inhalt optional in einem einzigen Vorgang aktualisieren

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

Audit- und Nachschlage-Zusammenfassungen

Das Tool get_content_summary gibt eine minimale Darstellung mit fester Form eines einzelnen Inhalts zurück. Entwickelt für Audit- und Nachschlage-Workflows, 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.

Nachschlagen per ID (mit optionalem content_type, Standardwert post):

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

Nachschlagen per URL (der Inhaltstyp wird aus der URL erkannt):

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

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

Die Antwortform 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."
}

Feldhinweise:

• 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 mit entferntem 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 Meta-Schlüssel offen, die mit show_in_rest registriert sind, und Yoast SEO registriert diesen Schlüssel standardmäßig nicht – dieses Feld ist also normalerweise null, es sei denn, ein Begleit-Plugin registriert es (siehe PR #17 für den Kontext des breiteren Problems der Meta-Schlüssel-REST-Offenlegung).

• Dieses Tool umgeht intern die in PR #16 hinzugefügte Antwortkürzung, 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 das exakte Abgleichen zu erleichtern, akzeptieren get_content und find_content_by_url beide include_raw_content: true. Wenn aktiviert, 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
}

Eine kurze Versionshinweis am Ende eines Beitrags anhängen:

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

Ein eindeutiges HTML-Fragment oder einen Markerkommentar an Ort und Stelle ersetzen:

{
  "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 sein können. Verwenden Sie 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 mehrfach 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 Taxonomie-Operationen

Alle Taxonomie-Operationen 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 seine rest_base (sie können sich für benutzerdefinierte Taxonomien unterscheiden, z. B. Slug documentation_category mit rest_base documentation-categories). Tools lösen den Bezeichner über /wp/v2/taxonomies auf und melden einen Fehler bei unbekannten Taxonomien, 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)

Sites, die WP Recipe Maker (WPRM) ausführen, speichern Rezeptkarten in einem separaten benutzerdefinierten Inhaltstyp wprm_recipe, der per Shortcode aus dem umgebenden Blog-Beitrag referenziert wird. Die einheitlichen Inhaltstools verarbeiten diese Rezepte direkt – 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 Rezept-Payload als Feld recipe in der REST-Antwort bereit, einschließlich Zutaten, Anweisungen, Zeiten, Ausrüstung, Nährwerten, Notizen und Bewertung.

Rezepte schreiben – übergeben Sie die Rezept-Payload über custom_fields.recipe bei create_content oder update_content. WPRM hängt sich in die WordPress-REST-Einfügeaktion (rest_insert_wprm_recipe) ein und liest recipe aus dem Stamm des Anforderungstexts, sodass jedes von WPRMs Datenmodell dokumentierte Feld akzeptiert wird.

Die recipe-Payload muss über custom_fields übergeben werden (das auf der Stammebene des Anforderungstexts verteilt wird). 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 Anweisungen – 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 ingredients- (oder instructions-)Array 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 Stichwort 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 einem Rezept über assign_terms_to_content.

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

Konfiguration

Einzel-Site-Konfiguration

Für die Verwaltung einer einzelnen WordPress-Site 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-Sites von einem einzigen MCP-Server aus 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

Multi-Site-Konfigurationsoptionen:

• WORDPRESS_N_URL: URL сайта WordPress (обязательно)

• WORDPRESS_N_USERNAME: имя пользователя WordPress (обязательно)

• WORDPRESS_N_PASSWORD: пароль приложения WordPress (обязательно)

• WORDPRESS_N_ID: идентификатор сайта (необязательно, по умолчанию siteN)

• WORDPRESS_N_DEFAULT: установите true, чтобы сделать этот сайт сайтом по умолчанию (необязательно, первый сайт является сайтом по умолчанию)

• WORDPRESS_N_ALIASES: псевдонимы через запятую для определения сайта (необязательно)

Сервер поддерживает до 10 сайтов. При использовании мультисайтовой конфигурации все инструменты принимают необязательный параметр site_id для обращения к конкретным сайтам.

Использование с npx и файлом .env

Вы можете запустить этот MCP-сервер напрямую через npx, не устанавливая его глобально:

npx -y @instawp/mcp-wp

Убедитесь, что в вашей текущей директории есть файл .env со следующими переменными:

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

Пользовательский агент

Каждый исходящий запрос, который делает этот сервер — REST-клиент WordPress, используемый всеми инструментами, SQL-эндпоинт, два обращения к api.wordpress.org и удалённые загрузки медиафайлов — отправляет пользовательский агент axios по умолчанию axios/<version>.

Установите WORDPRESS_USER_AGENT, чтобы переопределить его везде:

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

Оставьте его неустановленным, если CDN или WAF перед вашим сайтом не отклоняет значение по умолчанию; пустое значение или значение из одних пробелов считается неустановленным. Избегайте голого Mozilla/5.0 — это хорошо известная сигнатура ботов, и именно её блокируют некоторые периферийные узлы (см. #28), поэтому здесь никто её не отправляет.

Обрезка ответов

По умолчанию сервер удаляет поля верхнего уровня yoast_head и yoast_head_json из каждого ответа REST API WordPress перед возвратом его MCP-клиенту. Эти поля содержат предварительно отрендеренную разметку схемы Yoast SEO, которая LLM почти никогда не нужна, но за которую приходится платить токенами при каждом запросе.

• Обрезка применяется как к ответам с одним объектом, так и к массивам объектов.

• Удаляются только поля верхнего уровня; вложенные объекты не затрагиваются.

• Переопределите список с помощью переменной окружения MCP_WP_STRIP_FIELDS (через запятую). Установите её в пустую строку, чтобы полностью отключить обрезку.

Ограничения поля meta

Параметр meta в create_content, update_content и find_content_by_url (с update_fields.meta) передаётся напрямую в эндпоинт WordPress /wp/v2/{type}/{id}. Ядро WordPress молча отбрасывает любой ключ meta, который не был зарегистрирован через register_post_meta(..., ['show_in_rest' => true]). У MCP-сервера нет собственного белого списка — он полагается на WordPress в вопросе того, какие ключи сохраняются.

Это означает, что ключи SEO-плагинов не доступны для записи через этот MCP-сервер по умолчанию, включая:

• 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+): хранит данные SEO в отдельной таблице (wp_aioseo_posts), а не в wp_postmeta — недоступно через поле meta никаким способом.

Сервер обнаруживает, когда WordPress отбросил какие-либо отправленные вами ключи, и добавляет блок Warning: в начало результата инструмента с их перечислением. Это делает молчаливое отбрасывание видимым для вызывающего LLM, но не может заставить WordPress принять эти ключи.

Чтобы включить запись SEO-метаданных, установите небольшой вспомогательный плагин WordPress, который вызывает register_post_meta для каждого нужного ключа с show_in_rest => true и соответствующим auth_callback. Отдельный плагин mcp-wp-seo-bridge находится в разработке именно для этой цели.

Какие ключи работают уже сейчас

Ключи плагинов, которые автор плагина уже зарегистрировал для REST — например, метаданные макета Genesis (_genesis_layout), поля WP Recipe Maker (wprm-*) или _wp_convertkit_post_meta от ConvertKit. Чтобы проверить, какие ключи проходят полный цикл на вашем сайте, запишите тестовое значение через update_content и проверьте блок meta в ответе — если ключ появился, значит, он сохранился.

То же ограничение применяется к метаданным терминов в инструментах unified-taxonomies (create_term, update_term).

Включение инструмента SQL-запросов (необязательно)

Инструмент execute_sql_query позволяет выполнять read-only SQL-запросы к вашей базе данных WordPress. Это необязательная функция, требующая добавления пользовательского REST API эндпоинта на ваш сайт WordPress.

Замечания по безопасности:

• Этот инструмент принимает только read-only запросы (SELECT, WITH...SELECT, EXPLAIN) для безопасности

• Запросы, содержащие INSERT, UPDATE, DELETE, DROP или другие изменяющие операторы, будут отклонены

• Многооператорные запросы блокируются для предотвращения SQL-инъекций

• Запросы и результаты записываются в logs/wordpress-api.log — избегайте включения конфиденциальных данных в запросы

• Этот инструмент требует прав уровня администратора (возможность manage_options)

Конфигурация: По умолчанию инструмент ожидает эндпоинт по адресу /mcp/v1/query. Вы можете изменить это, установив переменную окружения WORDPRESS_SQL_ENDPOINT (например, WORDPRESS_SQL_ENDPOINT=/custom/v1/query).

Чтобы включить эту функцию, добавьте следующий код на ваш сайт WordPress (через пользовательский плагин или functions.php вашей темы):

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');
        }
    ));
});

После добавления этого кода вы можете использовать инструмент execute_sql_query для выполнения запросов, например:

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

Разработка

Предварительные требования

• Node.js и npm: Убедитесь, что у вас установлены Node.js (версия 18 или выше) и npm. Node 18 достаточно для запуска сервера. Для участия в разработке нужен Node 20 или новее, потому что тестовый инструментарий (Vitest 4) требует его — CI работает на 20.x и 22.x.

• Сайт WordPress: Вам нужен активный сайт WordPress с включённым REST API.

• Аутентификация WordPress API: Настройте аутентификацию для REST API WordPress. Обычно для этого требуется плагин или метод аутентификации (например, пароли приложений).

• MCP-клиент: Вам нужно приложение, которое может взаимодействовать с MCP-сервером. В настоящее время рекомендуется Claude Desktop.

Установка и настройка

1. Клонируйте репозиторий:

   git clone <repository_url>
   cd wordpress-mcp-server

2. Установите зависимости:

   npm install

3. Создайте файл .env:

   Создайте файл .env в корне каталога вашего проекта и добавьте учётные данные WordPress API.

   Для одного сайта:

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

   Для нескольких сайтов:

   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

   Замените заполнители на ваши реальные значения.

4. Соберите сервер:

   npm run build

5. Настройте Claude Desktop:

   • Откройте настройки Claude Desktop и перейдите на вкладку «Developer».

   • Нажмите «Edit Config», чтобы открыть файл claude_desktop_config.json.

   • Добавьте новую конфигурацию сервера в раздел mcpServers. Вам нужно указать абсолютный путь к файлу build/server.js и переменные окружения WordPress.

   • Сохраните конфигурацию.

Запуск сервера

После настройки Claude Desktop сервер должен запускаться автоматически при каждом запуске Claude Desktop.

Вы также можете запустить сервер напрямую из командной строки для тестирования:

npm start

или в режиме разработки:

npm run dev

Запуск тестов

В репозитории используется Vitest для модульных тестов. Тесты находятся в tests/ и покрывают мультисайтовый SiteManager и подключение реестра MCP-инструментов.

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

Тесты запускаются при pull_request и при пушах в main через .github/workflows/test.yml.

Релизы

Слияние исправления не доходит до пользователей — npm продолжает обслуживать последнюю опубликованную версию, пока не будет запущен релиз. Публикация автоматизирована через .github/workflows/release.yml и запускается по тегу версии:

# 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

Вносите правки в CHANGELOG до выполнения npm version. Внесение изменений в коммит после этого оставит тег указывающим на коммит до изменений, и workflow опубликует именно с него.

Workflow отказывается публиковать, если тег и package.json не совпадают, или если эта версия уже есть на npm; затем он собирает проект, запускает тесты, публикует с provenance и подтверждает, что реестр действительно обслуживает новую версию, прежде чем сообщить об успехе.

Если тег существует, но публикация не удалась (или была до появления этого workflow), запустите его повторно через Actions → Release → Run workflow, оставив селектор ветки на main (именно оттуда читается файл workflow) и передав имя тега в поле ввода. Два предостережения: дерево тега уже должно содержать поле repository, описанное ниже, и аттестация provenance записывает ref, с которого был запущен workflow, а не тег — поэтому для настоящего релиза лучше перевыпустить версию и использовать путь с пушем тега.

Если публикация прошла успешно, но шаг проверки стал красным (реестр, который оставался медленным более двух минут), сначала проверьте npmjs.com, прежде чем что-либо делать: версия опубликована, и повторный запуск теперь по замыслу завершится ошибкой из-за защиты от уже существующей на npm версии. В этом случае ничего исправлять не нужно.

Настройка, один раз: workflow требует npm automation-токен с правами публикации в области @instawp, хранящийся как секрет репозитория NPM_TOKEN (Settings → Secrets and variables → Actions). Именно automation-токен — классический publish-токен не сработает в CI на аккаунте с включённой 2FA.

npm trusted publishing позволил бы полностью отказаться от хранимого токена, но для него нужен npm ≥ 11.5.1, а setup-node в настоящее время поставляет npm 10.x с Node 22, поэтому здесь он неприменим без дополнительного обновления npm внутри задания.

Публикация с provenance требует, чтобы поле repository в package.json соответствовало этому репозиторию — иначе реестр отклонит публикацию. Не удаляйте его.

Безопасность

• Никогда не коммитьте свои ключи API или секреты в систему контроля версий.

• Используйте HTTPS для связи между клиентом и сервером.

• Проверяйте все входные данные, полученные от клиента, для предотвращения атак с инъекциями.

• Реализуйте надлежащую обработку ошибок и ограничение частоты запросов.

Обзор проекта

Архитектура

Сервер использует унифицированную архитектуру инструментов для снижения сложности:

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)

Ключевые возможности

• Поддержка нескольких сайтов: Управление несколькими сайтами WordPress из одного экземпляра MCP-сервера

• Умное разрешение URL: Автоматическое определение типов контента по URL и поиск соответствующего контента

• Универсальное управление контентом: Единый набор инструментов для записей, страниц и произвольных типов записей

• Универсальное управление таксономиями: Единый набор инструментов для категорий, меток и произвольных таксономий

• Безопасность типов: Полная поддержка TypeScript с валидацией схем Zod

• Подробное логирование: Детальное логирование API-запросов/ответов для отладки

• Обработка ошибок: Корректная обработка ошибок с информативными сообщениями

Начало работы

1. Клонируйте репозиторий и установите зависимости с помощью npm install

2. Создайте файл .env с учётными данными WordPress

3. Соберите проект с помощью npm run build

4. Настройте Claude Desktop с сервером

5. Начните использовать естественный язык для управления вашим сайтом WordPress!

Участие в разработке

Не стесняйтесь открывать issues или отправлять pull request для улучшения этого проекта. Ознакомьтесь с CLAUDE.md для получения подробных рекомендаций по разработке.