WordPress MCP 服务器

这是一个用于 WordPress 的模型上下文协议（MCP）服务器，允许你通过兼容 MCP 的客户端（如 Claude 桌面版）使用自然语言与你的 WordPress 站点交互。该服务器将各种 WordPress 数据和功能作为 MCP 工具暴露出来。

使用方法

Claude 桌面版

1. 下载并安装 Claude 桌面版。

2. 打开 Claude 桌面版设置，导航到“开发者”（Developer）选项卡。

3. 复制 claude_desktop_config.json.example 文件的内容。

4. 点击“编辑配置”（Edit Config）以打开 claude_desktop_config.json 文件。

5. 将示例文件的内容粘贴到配置文件中。确保将占位符值替换为你实际的 WordPress 站点值。要生成应用程序密钥，请按照此指南操作——应用程序密码。

6. 保存配置。

7. 重启 Claude 桌面版。

Related MCP server: WordPress MCP Server

功能特性

该服务器提供与核心 WordPress 数据交互的工具，并支持多站点管理——通过单个 MCP 服务器实例管理多个 WordPress 站点。

多站点管理（3 个工具）

通过单个 MCP 服务器管理多个 WordPress 站点：

• list_sites：列出所有已配置的 WordPress 站点

• get_site：获取特定站点配置的详细信息

• test_site：测试与特定 WordPress 站点的连接

所有内容和分类法工具都支持可选的 site_id 参数来定位特定站点。

统一内容管理（9 个工具）

使用一套智能工具处理所有内容类型（文章、页面、自定义文章类型）：

• list_content：列出任意内容类型，支持筛选和分页

• get_content：按 ID 和类型获取特定内容

• create_content：创建任意类型的新内容

• update_content：更新任意类型的现有内容，支持针对性部分编辑

• delete_content：删除任意类型的内容

• discover_content_types：查找你站点上所有可用的内容类型

• find_content_by_url：智能 URL 解析器，可通过任意 WordPress URL 查找并可选地更新内容，支持针对性部分编辑

• get_content_by_slug：跨所有内容类型按别名（slug）搜索

• get_content_summary：返回最小化摘要（id、title、slug、status、excerpt、taxonomies、word count、Yoast SEO 字段），用于审计和查找工作流。通过 id 或 url 查找。

统一分类法管理（8 个工具）

使用一套工具处理所有分类法（分类目录、标签、自定义分类法）：

• discover_taxonomies：查找你站点上所有可用的分类法

• list_terms：列出任意分类法中的术语

• get_term：按 ID 获取特定术语

• create_term：在任意分类法中创建新术语

• update_term：更新现有术语

• delete_term：从任意分类法中删除术语

• assign_terms_to_content：为任意内容类型分配术语

• get_content_terms：获取任意内容的所有术语

专用工具

• 媒体：

  • list_media：列出所有媒体项目（支持分页和搜索）。

  • get_media：按 ID 检索特定媒体项目。

  • create_media：从 URL 或本地文件路径创建新媒体项目。

  • update_media：更新现有媒体项目。

  • delete_media：删除媒体项目。

  • edit_media：update_media 的旧版别名，为向后兼容而保留。

• 用户：

  • list_users：列出所有用户，支持筛选、排序和分页选项。

  • get_user：按 ID 检索特定用户。

  • create_user：创建新用户。

  • update_user：更新现有用户。

  • delete_user：删除用户。

• 评论：

  • list_comments：列出所有评论，支持筛选、排序和分页选项。

  • get_comment：按 ID 检索特定评论。

  • create_comment：创建新评论。

  • update_comment：更新现有评论。

  • delete_comment：删除评论。

• 插件：

  • list_plugins：列出站点上安装的所有插件。

  • get_plugin：检索特定插件的详细信息。

  • activate_plugin：激活插件。

  • deactivate_plugin：停用插件。

  • create_plugin：创建新插件。

• 插件仓库：

  • search_plugins：在 WordPress.org 插件仓库中搜索插件。

  • get_plugin_info：从插件仓库获取插件的详细信息。

• 数据库查询：

  • execute_sql_query：针对 WordPress 数据库执行只读 SQL 查询（需要自定义端点设置）。

主要优势

媒体上传工作流

从运行 MCP 服务器的同一台机器上传本地截图：

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

从远程 URL 上传媒体：

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

将返回的媒体 ID 用作新内容的特色媒体：

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

智能 URL 解析

find_content_by_url 工具可以：

• 接受任意 WordPress URL 并自动找到对应内容

• 从 URL 模式检测内容类型（例如，/documentation/ → documentation 自定义文章类型）

• 在单次操作中可选地更新内容

• 适用于文章、页面以及任意自定义文章类型

审计与查找摘要

get_content_summary 工具返回单个内容的极简固定结构表示。专为审计和查找工作流设计，在这些场景中完整的 WP REST 响应可能过大——例如在食谱文章上，由于渲染的 Recipe Maker 卡片 HTML，响应可能超过 50KB。

按 ID 查找（可选 content_type 参数，默认为 post）：

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

按 URL 查找（从 URL 自动检测内容类型）：

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

id 和 url 互斥——只能提供其中一个。

响应结构是固定的：

{
  "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."
}

字段说明：

• title 和 excerpt 被剥离为纯文本（移除 HTML 标签，解码基本实体）。

• word_count 优先使用 yoast_head_json.schema.@graph[].wordCount（当 Yoast SEO 激活时）；否则从渲染后的文章内容中计算，并剥离 HTML。

• yoast_meta_title 和 yoast_meta_description 从文章上的 yoast_head_json 读取。当 Yoast SEO 未激活时，它们为 null。

• yoast_focus_keyword 从 meta._yoast_wpseo_focuskw 读取。WordPress 核心仅暴露注册了 show_in_rest 的元键，而 Yoast SEO 默认不注册此键——因此该字段通常为 null，除非有配套插件注册它（有关更广泛的元键 REST 暴露问题，请参阅 PR #17）。

• 该工具在内部绕过了 PR #16 中添加的响应裁剪，以便读取 yoast_head_json。裁剪仍然适用于所有其他工具。

通用内容操作

所有内容操作都使用单一的 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
}

针对性内容编辑

update_content 和 find_content_by_url 的 update_fields 可以修补现有的原始 WordPress 内容，而无需重新发送完整文档。

为了更容易精确匹配，get_content 和 find_content_by_url 都接受 include_raw_content: true。启用后，响应将使用 WordPress 编辑上下文获取，并包含一个顶层的 content_raw 字段，该字段与 content_edit.target_text 所需的内容完全匹配。

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

在文章末尾追加一段简短的发布说明：

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

就地替换唯一的 HTML 片段或标记注释：

{
  "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"
  }
}

说明：

• 渲染后的 WordPress HTML 可能与 content.raw 不同，因为实体可能被转义、标记可能被展开，因此当你需要精确的 target_text 时，请使用 include_raw_content。

• target_text 与存储的原始 WordPress 内容完全匹配。

• 如果相同的 target_text 出现多次，请传入 occurrence 来选择基于 1 的匹配项。

• 对于以 Gutenberg 块存储的文章，在插入应转换为块的 Markdown 或 HTML 时，请设置 content_edit.convert_to_blocks。

通用分类法操作

所有分类法操作都使用单一的 taxonomy 参数：

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

taxonomy 参数接受分类法别名（slug）或其 rest_base（对于自定义分类法，两者可能不同，例如别名 documentation_category 的 rest_base 为 documentation-categories）。工具通过 /wp/v2/taxonomies 解析标识符，并在遇到未知分类法时报告错误，而不是猜测。 assign_terms_to_content 会根据 WordPress 响应验证写入操作，如果术语实际上未保存，则报告错误。

食谱卡片（WP Recipe Maker）

运行 WP Recipe Maker（WPRM）的站点将食谱卡片存储在单独的 wprm_recipe 自定义文章类型中，通过短代码从周围的博客文章引用。统一内容工具直接处理这些食谱——无需专门的食谱工具系列。

读取食谱——get_content、list_content、find_content_by_url 和 get_content_by_slug 都支持 content_type: "wprm_recipe"。WPRM 将完整的结构化食谱数据作为 REST 响应上的 recipe 字段暴露，包括食材、步骤、时间、设备、营养信息、备注和评分。

写入食谱——通过 create_content 或 update_content 上的 custom_fields.recipe 传递食谱数据。WPRM 挂钩到 WordPress REST 插入操作（rest_insert_wprm_recipe），并从请求体根级别读取 recipe，因此 WPRM 数据模型记录的任何字段都被接受。

recipe 数据必须通过 custom_fields 传递（它会在请求体根级别展开）。meta 参数会将其值嵌套在 meta 键下，这永远不会到达 WPRM 的 REST 挂钩。

更新示例：

{
  "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."
    }
  }
}

分组食材和步骤——食谱可以将项目拆分为命名组，如“酱汁用”/“鸡肉用”。外层 ingredients（或 instructions）数组中的每个条目是一个组，包含自己的 name 和内层数组：

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

常用食谱字段：

菜系（course）、风味（cuisine）和关键词（keyword）存储为 WPRM 分类法（wprm_course、wprm_cuisine、wprm_keyword）。使用统一分类法工具（list_terms、create_term 等）管理它们，并使用 assign_terms_to_content 将它们链接到食谱。

WPRM 会在保存时自动将 recipe.summary 同步回 WordPress 的 post_content 字段。如果你希望文章正文和食谱摘要不同，请在 custom_fields.recipe 之外显式传递 content。

配置

单站点配置

要管理单个 WordPress 站点，请使用以下环境变量：

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

多站点配置

要通过单个 MCP 服务器管理多个 WordPress 站点，请使用带编号的环境变量：

# 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

多站点配置选项：

• WORDPRESS_N_URL：WordPress 站点 URL（必填）

• WORDPRESS_N_USERNAME：WordPress 用户名（必填）

• WORDPRESS_N_PASSWORD：WordPress 应用程序密码（必填）

• WORDPRESS_N_ID：站点标识符（可选，默认为 siteN）

• WORDPRESS_N_DEFAULT：设为 true 可将此站点设为默认站点（可选，第一个站点为默认站点）

• WORDPRESS_N_ALIASES：用于站点检测的逗号分隔别名（可选）

服务器最多支持 10 个站点。使用多站点配置时，所有工具都接受一个可选的 site_id 参数来指定目标站点。

通过 npx 和 .env 文件使用

你可以直接使用 npx 运行此 MCP 服务器，无需全局安装：

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

用户代理

此服务器发出的每个出站请求——所有工具使用的 WordPress REST 客户端、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），因此这里没有任何请求会发送它。

响应裁剪

默认情况下，服务器会在将每个 WordPress REST API 响应返回给 MCP 客户端之前，剥离其中的顶级 yoast_head 和 yoast_head_json 字段。这些字段包含 Yoast SEO 预渲染的 schema 标记，LLM 几乎从不需要它们，但每次请求都要为其消耗 token。

• 裁剪同时适用于单对象响应和对象数组。

• 仅剥离顶级字段；嵌套对象不受影响。

• 可使用 MCP_WP_STRIP_FIELDS 环境变量 （逗号分隔）覆盖此列表。将其设为空字符串可完全禁用裁剪。

Meta 字段限制

create_content、update_content 和 find_content_by_url（使用 update_fields.meta 时）上的 meta 参数会直接转发到 WordPress 的 /wp/v2/{type}/{id} 端点。WordPress 核心会静默丢弃任何未通过 register_post_meta(..., ['show_in_rest' => true]) 注册的 meta 键。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 meta 写入，请安装一个小型 WordPress 配套插件，为每个所需键调用 register_post_meta，并设置 show_in_rest => true 和适当的 auth_callback。一个独立的 mcp-wp-seo-bridge 插件正在规划中，专门用于实现此功能。

哪些键目前确实可用

插件作者已为 REST 注册的插件键——例如 Genesis 布局 meta（_genesis_layout）、WP Recipe Maker 字段（wprm-*）或 ConvertKit 的 _wp_convertkit_post_meta。要检查哪些键能在你的站点上成功往返，请通过 update_content 写入一个测试值并检查响应中的 meta 块——如果键出现，则说明它已持久化。

同样的限制也适用于 unified-taxonomies 工具（create_term、update_term）上的 term meta。

启用 SQL 查询工具（可选）

execute_sql_query 工具允许你针对 WordPress 数据库运行只读 SQL 查询。这是一个可选功能，需要在你的 WordPress 站点上添加一个自定义 REST API 端点。

安全说明：

• 出于安全考虑，此工具仅接受只读查询（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 站点： 你需要一个启用了 REST API 的活跃 WordPress 站点。

• WordPress API 认证： 为 WordPress REST API 设置认证。这通常需要认证插件或方法（如应用程序密码）。

• 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

测试通过 .github/workflows/test.yml 在 pull_request 和推送到 main 时运行。

发布

合并修复并不会触达任何人——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。之后再修改提交会使标签指向修改前的提交，工作流将从该提交发布。

如果标签与 package.json 不一致，或该版本已存在于 npm 上，工作流将拒绝发布；随后它会构建、运行测试、使用来源证明发布，并在报告成功前确认注册表确实提供该新版本。

如果标签已存在但发布失败（或发布早于此工作流），请从 Actions → Release → Run workflow 重新运行，将分支选择器保持在 main 上（工作流文件从该分支读取），并在输入中传入标签名。有两个注意事项：标签的树必须已包含下文描述的 repository 字段，并且来源证明记录的是工作流派发自的 ref，而非标签——因此对于真正的发布，建议重新切一个版本并使用标签推送路径。

如果发布成功但验证步骤变红（注册表持续缓慢超过两分钟），请先检查 npmjs.com 再采取任何操作：该版本已发布，重新运行将按设计因 already-on-npm 防护而失败。这种情况下无需修复任何问题。

一次性设置： 工作流需要一个对 @instawp 范围具有发布权限的 npm automation token，存储为仓库密钥 NPM_TOKEN（Settings → Secrets and variables → Actions）。具体来说需要 automation token——在启用 2FA 的账户上，经典发布 token 会在 CI 中失败。

npm 的可信发布可以完全消除存储的 token，但它需要 npm ≥ 11.5.1，而 setup-node 目前随 Node 22 提供 npm 10.x，因此如果不同时在作业中升级 npm，则无法在此使用。

使用来源证明发布要求 package.json 中的 repository 字段与此仓库匹配——否则注册表会拒绝发布。请勿移除它。

安全

• 切勿将 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)

主要功能

• 多站点支持：从单个 MCP 服务器实例管理多个 WordPress 站点

• 智能 URL 解析：自动从 URL 检测内容类型并查找相应内容

• 通用内容管理：一组工具即可处理文章、页面和自定义文章类型

• 通用分类法管理：一组工具即可处理分类、标签和自定义分类法

• 类型安全：完整的 TypeScript 支持及 Zod schema 验证

• 全面的日志记录：详细的 API 请求/响应日志，便于调试

• 错误处理：优雅的错误处理，并提供信息丰富的错误消息

快速开始

1. 克隆仓库，然后使用 npm install 安装依赖

2. 创建一个包含 WordPress 凭据的 .env 文件

3. 使用 npm run build 构建项目

4. 在 Claude Desktop 中配置服务器

5. 开始使用自然语言管理你的 WordPress 站点！

贡献

欢迎提出问题或提交拉取请求来改进此项目。查看 CLAUDE.md 获取详细的开发指南。