This is a Model Context Protocol (MCP) server for WordPress, allowing you to interact with your WordPress site using natural language via an MCP-compatible client like Claude for Desktop. This server exposes various WordPress data and functionality as MCP tools.
claude_desktop_config.json.example file.claude_desktop_config.json file.This server provides tools to interact with core WordPress data and supports multi-site management - manage multiple WordPress sites from a single MCP server instance.
Manage multiple WordPress sites from a single MCP server:
list_sites: List all configured WordPress sitesget_site: Get details about a specific site configurationtest_site: Test connection to a specific WordPress siteAll content and taxonomy tools support an optional site_id parameter to target specific sites.
Handles ALL content types (posts, pages, custom post types) with a single set of intelligent tools:
list_content: List any content type with filtering and paginationget_content: Get specific content by ID and typecreate_content: Create new content of any typeupdate_content: Update existing content of any type, including targeted partial editsdelete_content: Delete content of any typediscover_content_types: Find all available content types on your sitefind_content_by_url: Smart URL resolver that can find and optionally update content from any WordPress URL, including targeted partial editsget_content_by_slug: Search by slug across all content typesget_content_summary: Return a minimal summary (id, title, slug, status, excerpt, taxonomies, word count, Yoast SEO fields) for audit and lookup workflows. Look up by id or url.Handles ALL taxonomies (categories, tags, custom taxonomies) with a single set of tools:
discover_taxonomies: Find all available taxonomies on your sitelist_terms: List terms in any taxonomyget_term: Get specific term by IDcreate_term: Create new term in any taxonomyupdate_term: Update existing termdelete_term: Delete term from any taxonomyassign_terms_to_content: Assign terms to any content typeget_content_terms: Get all terms for any contentlist_media: List all media items (supports pagination and searching).get_media: Retrieve a specific media item by ID.create_media: Create a new media item from a URL or local file path.update_media: Update an existing media item.delete_media: Delete a media item.edit_media: Legacy alias for update_media kept for backward compatibility.list_users: List all users with filtering, sorting, and pagination options.get_user: Retrieve a specific user by ID.create_user: Create a new user.update_user: Update an existing user.delete_user: Delete a user.list_comments: List all comments with filtering, sorting, and pagination options.get_comment: Retrieve a specific comment by ID.create_comment: Create a new comment.update_comment: Update an existing comment.delete_comment: Delete a comment.list_plugins: List all plugins installed on the site.get_plugin: Retrieve details about a specific plugin.activate_plugin: Activate a plugin.deactivate_plugin: Deactivate a plugin.create_plugin: Create a new plugin.search_plugins: Search for plugins in the WordPress.org repository.get_plugin_info: Get detailed information about a plugin from the repository.execute_sql_query: Execute read-only SQL queries against the WordPress database (requires custom endpoint setup).Upload a local screenshot from the same machine running the MCP server:
{
"file_path": "./screenshots/homepage.png",
"title": "Homepage Screenshot",
"alt_text": "Homepage screenshot showing the hero section"
}
Upload media from a remote URL:
{
"source_url": "https://example.com/assets/hero-image.png",
"title": "Hero Image",
"caption": "Imported from the design system"
}
Use the returned media ID as featured media on new content:
{
"content_type": "post",
"title": "Release Notes",
"content": "
Launch summary...
",
"featured_media": 123
}
The find_content_by_url tool can:
/documentation/ → documentation custom post type)The get_content_summary tool returns a minimal, fixed-shape representation of a single piece of content. Designed for audit and lookup workflows where the full WP REST response — which can exceed 50KB on recipe posts because of the rendered Recipe Maker card HTML — is overkill.
Look up by ID (with optional content_type, defaulting to post):
{
"id": 4274,
"content_type": "post"
}
Look up by URL (content type is detected from the URL):
{
"url": "https://example.com/blog/easy-smoked-asparagus/"
}
id and url are mutually exclusive — provide exactly one.
The response shape is fixed:
{
"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."
}
Field notes:
title and excerpt are stripped to plain text (HTML tags removed, basic entities decoded).word_count prefers yoast_head_json.schema.@graph[].wordCount when Yoast SEO is active; otherwise it is computed from the rendered post content with HTML stripped.yoast_meta_title and yoast_meta_description are read from yoast_head_json on the post. They are null when Yoast SEO is not active.yoast_focus_keyword is read from meta._yoast_wpseo_focuskw. WordPress core only exposes meta keys that are registered with show_in_rest, and Yoast SEO does not register this key by default — so this field will typically be null unless a companion plugin registers it (see PR #17 for context on the broader meta-key REST exposure issue).yoast_head_json. The trim still applies to all other tools.All content operations use a single content_type parameter:
{
"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 and find_content_by_url.update_fields can patch the existing raw WordPress content without resending the full document.
To make exact matching easier, get_content and find_content_by_url both accept include_raw_content: true. When enabled, the response is fetched with WordPress edit context and includes a top-level content_raw field that matches what content_edit.target_text needs.
{
"content_type": "page",
"id": 7,
"include_raw_content": true
}
Append a short release note to the end of a post:
{
"content_type": "post",
"id": 42,
"content_edit": {
"operation": "append",
"value": "\n
Update: Early access is now open.
",
"content_format": "html"
}
}
Replace a unique HTML fragment or marker comment in place:
{
"content_type": "page",
"id": 7,
"content_edit": {
"operation": "replace",
"target_text": "\n
Old price
\n",
"value": "\n
New price
\n",
"content_format": "html"
}
}
Notes:
content.raw because entities may be escaped and markup may be expanded, so use include_raw_content when you need an exact target_text.target_text matches the stored raw WordPress content exactly.target_text appears multiple times, pass occurrence to choose the 1-based match.content_edit.convert_to_blocks when inserting Markdown or HTML that should become blocks.All taxonomy operations use a single taxonomy parameter:
{
"taxonomy": "category", // for categories
"taxonomy": "post_tag", // for tags
"taxonomy": "product_category", // for WooCommerce
"taxonomy": "skill" // for custom taxonomies
}
The taxonomy parameter accepts either the taxonomy slug or its rest_base
(they can differ for custom taxonomies, e.g. slug documentation_category
with rest_base documentation-categories). Tools resolve the identifier via
/wp/v2/taxonomies and error on unknown taxonomies instead of guessing.
assign_terms_to_content verifies the write against the WordPress response
and reports an error if the terms were not actually saved.
Sites running WP Recipe Maker (WPRM) store recipe cards in a separate wprm_recipe custom post type referenced by shortcode from the surrounding blog post. The unified content tools handle these recipes directly — no recipe-specific tool family is needed.
Reading recipes — get_content, list_content, find_content_by_url, and get_content_by_slug all work with content_type: "wprm_recipe". WPRM exposes the full structured recipe payload as a recipe field on the REST response, including ingredients, instructions, times, equipment, nutrition, notes, and rating.
Writing recipes — pass the recipe payload via custom_fields.recipe on create_content or update_content. WPRM hooks into the WordPress REST insert action (rest_insert_wprm_recipe) and reads recipe from the request body root, so any field documented by WPRM's data model is accepted.
The
recipepayload must be passed viacustom_fields(which spreads at the request body root). Themetaparameter nests its values under ametakey, which never reaches WPRM's REST hook.
Example update:
{
"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."
}
}
}
Grouped ingredients and instructions — recipes can split items into named groups like "For the sauce" / "For the chicken". Each entry in the outer ingredients (or instructions) array is one group with its own name and inner array:
{
"ingredients": [
{ "name": "For the sauce", "ingredients": [ /* items */ ] },
{ "name": "For the chicken", "ingredients": [ /* items */ ] }
]
}
Commonly used recipe fields:
| Field | Type | Notes |
|---|---|---|
name |
string | Recipe card title |
summary |
string | Short blurb (HTML allowed) |
servings |
string | e.g. "4" |
servings_unit |
string | e.g. "people", "servings" |
prep_time |
string | minutes, e.g. "15" |
cook_time |
string | minutes |
total_time |
string | minutes |
ingredients |
array of groups | nested structure shown above |
instructions |
arra |
$ claude mcp add mcp-wp \
-- python -m otcore.mcp_server <graph>