List every WordPress site configured on this MCP server, with its id, URL, auth method and whether it is writable. Start here when you do not know which site_id to use. Credentials are never returned.

Get the full configuration for one site (secrets redacted), plus what the WordPress install reports about itself: name, description, timezone, WordPress version, permalink shape, and which optional wpxmcp capabilities are available.

Test connectivity and authentication against a site, and report exactly what works: REST reachability, whether credentials authenticate, which user they map to, that user's roles and capabilities, and whether the optional companion plugin is installed. Run this first when anything is behaving strangely — it names the specific misconfiguration rather than a generic failure.

Read the append-only local audit log of every sensitive action this server has taken — writes, deletes, SQL, WP-CLI, theme publishes — with timestamp, site, tool, target and outcome. Useful for answering "what did the AI actually change?".

List every content type registered on the site — post, page, and any custom post type — with its REST base, whether it is hierarchical, which taxonomies apply, and which fields it supports. Call this before working with an unfamiliar site: a type absent here is registered with show_in_rest => false and cannot be reached over REST at all.

List items of any content type — posts, pages, or a custom post type — with filtering, search, ordering and pagination. Returns compact summaries by default so a listing never floods the context; pass full_content: true only when you genuinely need bodies.

Fetch one item of any content type by ID, including the raw content body exactly as stored — which is what you must read before making targeted edits, since the block editor stores markup with HTML comment delimiters.

Return a minimal summary of one item — id, title, slug, status, excerpt, taxonomies, word count and SEO fields (Yoast, Rank Math, AIOSEO or SEOPress) — without the body. Built for audits and lookups over many items. Accepts either an id (with type) or a full URL.

Look up content by slug across every content type at once, or within specific types. Use when you know the URL tail but not which post type owns it.

Resolve any WordPress front-end URL to the content behind it, detecting the post type from the URL shape (so /documentation/getting-started/ finds the documentation custom post type), then optionally update it in the same call. This is the tool to reach for when a human hands you a link. Detection tries, in order: an explicit ?p= id, the site's own search index, the registered rewrite base, then a slug sweep across every type.

Create a post, page, or any custom post type. Content is created as a DRAFT unless you explicitly pass status: "publish" — this server never publishes to a live site implicitly. Taxonomy terms can be given by name and are created if missing.

Update any content type by ID. Supply content to replace the body wholesale, or edits for targeted find/replace changes that leave the rest of the document untouched — the latter is safer on long pages and is what you should reach for when changing a heading, a price, or one paragraph. An edit that matches nothing fails loudly rather than silently writing nothing.

Delete content of any type. By default it goes to the trash and stays recoverable from wp-admin. Permanent deletion requires force: true AND confirm: true, and cannot be undone — the row is removed from the database along with its meta.

List every taxonomy on the site — categories, tags, and any custom taxonomy — with its REST base, which post types it applies to, and whether it is hierarchical. A taxonomy missing here is registered with show_in_rest => false and is unreachable over REST.

List terms in any taxonomy with search, ordering, hierarchy filtering and pagination. Works for categories, tags and custom taxonomies alike.

Fetch one taxonomy term by ID, including its description, parent, item count and any registered term meta.

Create a term in any taxonomy. If a term with the same name already exists, WordPress rejects it — search with list_terms first when you might be duplicating.

Update a term's name, slug, description, parent or meta in any taxonomy. Changing a slug changes the term archive URL.

Delete a term from any taxonomy. Terms have no trash — deletion is immediate and permanent, so this reports what will be affected and requires confirm: true. Content assigned to the term is not deleted; it simply loses the assignment (posts losing their only category fall back to the default category).

Assign taxonomy terms to any content item. Terms may be given as IDs or as names — names that do not exist are created for you. By default this replaces the item's terms in that taxonomy; pass mode: "add" to keep the existing ones, or "remove" to detach.

Get every taxonomy term assigned to one content item, grouped by taxonomy and resolved to full term objects rather than bare IDs.

List items in the media library with search, type filtering, date filtering and pagination.

Fetch one media item by ID, including its source URL, dimensions, generated sizes, alt text and where it is attached.

Upload a file into the media library from any of three sources: file_path (a path on the machine running this MCP server — this is how you upload a local screenshot), url (downloaded here, then uploaded), or base64_data. WordPress runs its normal image pipeline, generating the registered thumbnail sizes. Always set alt_text for images — it is required for accessibility and read by search engines.

Update a media item's title, alt text, caption, description or attachment — without re-uploading the file.

Legacy alias for update_media, kept for backward compatibility. Prefer update_media.

Delete a media item. Attachments bypass the trash by default in WordPress, so deletion removes the file from disk permanently and requires confirm: true. Any content still referencing the file will show a broken image.

Search Unsplash or Pexels for royalty-free photos and get back candidate image URLs with their required attribution. Pass a chosen result's download_url to create_media (along with its attribution) to bring it into the library. Requires UNSPLASH_ACCESS_KEY or PEXELS_API_KEY to be set on this MCP server.

List users with search, role filtering, ordering and pagination. Email addresses and roles are only returned when the authenticated user has list_users capability (Administrator); otherwise WordPress returns just the public author profile.

Fetch one user by ID, or the authenticated user with id: "me". Includes roles and a summary of notable capabilities when permitted.

Create a WordPress user. Requires an Administrator account. Choose the role deliberately — "administrator" grants full control of the site including plugin and theme installation.

Update a user's profile, email, password or roles. Changing roles changes what that person can do — promoting to administrator grants full site control.

Delete a user. WordPress has no trash for users, so this is permanent and requires confirm: true. You must say what happens to their content: reassign it to another user (strongly preferred) or let it be deleted with them.

List the roles registered on the site with their capabilities, so you can pick the right role before creating or updating a user. Uses the companion plugin when available and falls back to the standard WordPress roles otherwise.

List comments with filtering by post, status, author and date. Moderating? Filter status: "hold" for the pending queue or "spam" for what the spam filter caught — both require authentication.

Fetch one comment by ID with its full text, author details and moderation status.

Post a comment on a content item, optionally as a threaded reply. Set status to "approve" to publish it immediately (requires moderation capability); otherwise it enters the normal moderation queue.

Update a comment's text, author details or moderation status. Setting status to "approve" publishes a held comment; "spam" trains the spam filter; "trash" hides it recoverably.

Delete a comment. It goes to the trash by default and is recoverable; force: true removes it permanently and requires confirm: true.

Approve, hold, spam or trash several comments in one call — the practical way to clear a moderation queue. Reports per-comment outcomes rather than failing the whole batch on one error.

List every plugin installed on the site with its activation status and version. Requires an Administrator account — WordPress exposes no plugin data to lower roles.

Get full details about one installed plugin by its plugin file path, e.g. "woocommerce/woocommerce" or "hello-dolly/hello".

Activate an installed plugin. Activation runs the plugin's code immediately — a plugin incompatible with this WordPress or PHP version can fatal the site, so prefer testing on staging first.

Deactivate an active plugin. Its features stop working immediately; settings and data are normally retained.

Install a plugin from the WordPress.org repository by its slug, optionally activating it straight away. Search first with search_plugins to get the right slug. Installation writes files to the server and needs filesystem write access.

Install a plugin from the WordPress.org repository. This is the REST API's own naming for the install operation — install_plugin is the clearer name for the same thing.

Delete an installed plugin from the server. The plugin must be inactive first. Files are removed permanently; many plugins also drop their database tables on uninstall. Requires confirm: true.

Search the public WordPress.org plugin repository. Returns slug, rating, install count, last-updated date and compatibility — enough to judge whether a plugin is maintained before installing it. This queries WordPress.org, not your site.

Get detailed information about one plugin from the WordPress.org repository — full description, changelog, version history, ratings breakdown, and compatibility. Use before installing or updating to see what changed.

List every theme installed on the site, showing which is active, which are block (full-site-editing) themes, and their versions and parents.

Get details about one installed theme, including what it declares support for and whether it is a block theme (which changes how you build pages and templates).

Switch the site's active theme. This changes the entire front-end appearance immediately, and widget/menu assignments do not always carry across. Requires confirm: true. If you are iterating on a theme you are building, use the draft workflow and publish_draft_theme instead.

Install a theme from the WordPress.org repository by slug. Does not activate it — use activate_theme, or the draft workflow, afterwards.

Clone an installed theme into an isolated draft copy that you can edit freely without touching the live site. Every theme edit should go through a draft: write files, preview them on a private tokenised URL, then publish_draft_theme when you are happy (which backs up the previous theme first). Omit from_theme to clone the currently active theme.

Scaffold a complete classic PHP theme styled with Tailwind, as a draft. Classic templates with utility classes are far more reliable to generate and to review than nested block markup — the output is readable, diffable and predictable. The scaffold includes style.css, functions.php, header/footer, index, single, page, archive, 404, search, comments, a theme.css holding the design tokens (colors, fonts, radii) that every template reuses, and a Tailwind CDN setup wired to those tokens.

List the files in a theme (or theme draft) with sizes, so you can see the template structure before reading or editing anything.

Read the contents of one theme file. Always read before editing — write_theme_file replaces the whole file, and edit_theme_file needs exact text to match.

Create or overwrite a theme file, replacing its entire contents. Refuses to write to a live active theme by default — work in a draft (create_draft_theme) so the site stays untouched until you publish. PHP is syntax-checked before it is saved, so a parse error is reported rather than fataling the site.

Make targeted find/replace edits inside a theme file, leaving the rest untouched. Safer than write_theme_file for changing one function or block of markup. An edit that matches nothing fails loudly rather than silently writing nothing.

Delete a file from a theme draft. Refuses to touch a live active theme unless explicitly allowed. Deleting a required template (index.php, style.css) breaks the theme.

Get a tokenised private URL that renders the site using a draft theme, without affecting what anyone else sees. Share it or open it to check your work before publishing. The token expires, so fetch a fresh URL if it stops working.

Promote a draft theme to the live site. The currently active theme is backed up first, so the change is reversible. This is the one step that changes what visitors see — everything before it is sandboxed. Requires confirm: true.

Discard a draft theme and its files. The live site is unaffected — this only removes the sandbox copy.

List the theme drafts that exist on the site, with what each was cloned from and when it was last touched.

List the site's navigation menus and which theme locations they are assigned to. Note that block (full-site-editing) themes may instead use navigation blocks — list_content with type "wp_navigation" covers those.

Get one navigation menu together with all of its items, rendered as an indented tree so the hierarchy is obvious.

Create an empty navigation menu, optionally assigning it to one or more theme locations. Add entries afterwards with add_menu_item.

Rename a menu or change which theme locations it fills.

Delete a navigation menu and all of its items. Any theme location it filled falls back to the theme's default output. Requires confirm: true.

Add an entry to a navigation menu. It can point at a post, page or custom post type (object_id + object), a taxonomy term, or an arbitrary URL. Use parent to nest it under another item and menu_order to position it.

Change a menu item's label, target, nesting or position.

Remove one item from a navigation menu. Its children are re-parented to the top level rather than deleted.

Set the order and nesting of several menu items at once, which is far less error-prone than updating them one by one.

List the theme's widget areas (sidebars) and the widgets currently placed in each. Block themes typically have no classic sidebars — that is expected, not an error.

List widgets, optionally within one sidebar, including their settings and rendered output.

Add a widget to a sidebar. id_base names the widget type (block, text, nav_menu, search, categories, recent-posts…). For the modern "block" widget, put block markup in instance.content — that is how the block-based widget editor stores everything.

Change a widget's settings or move it to a different sidebar or position.

Remove a widget. By default it is moved to the inactive widgets area so its settings survive; force: true deletes it outright.

List the block theme's templates (front-page, single, archive…) or template parts (header, footer). Block themes only — a classic theme returns nothing here, and you should use the theme file tools instead.

Get one block template or template part, including its block markup, so you can inspect or edit the layout of an entire page type.

Update a block template or template part's markup. This changes the layout of every page that uses it, so it takes effect site-wide immediately. WordPress stores the customisation in the database, leaving the theme's own file untouched — you can always revert in the Site Editor.

Read a block theme's global styles — the palette, typography, spacing and per-block styling that theme.json defines and the Site Editor overrides. This is where a block theme's design tokens live.

Update a block theme's global styles — palette, typography, spacing, per-block styling. Changes apply site-wide immediately. Read them first: this merges at the top level, so a partial settings object replaces that whole branch.

List the block types registered on the site, with their attributes. Check here before generating block markup for an unfamiliar plugin's blocks — it tells you the exact block name and which attributes are valid.

List the site's reusable blocks / synced patterns — the fragments editors reuse across pages. Editing one changes every place it appears.

Read the active theme's Customizer settings (theme mods) — logo, colors, layout options and anything else the theme registers there. Classic themes keep much of their configuration here rather than in options.

Write one Customizer setting (theme mod) for the active theme. What is valid depends entirely on the theme — read get_theme_mods first to see the keys it uses.

Read the site's core settings — title, tagline, timezone, date formats, posts-per-page, front page configuration, default category, comment and registration policy. Requires an Administrator account.

Update the site's core settings. These are global and take effect immediately for every visitor — changing show_on_front or page_on_front changes what the homepage is, and changing start_of_week or timezone shifts every displayed date. Requires an Administrator account.

A full diagnostic picture of the site in one call: WordPress and PHP versions, active theme, active plugins, database size, health checks, available updates, and server configuration. Start here when auditing a site or diagnosing a problem. Falls back to core REST data when the companion plugin is absent, and says which parts it could not see.

Fetch the fully rendered HTML that a visitor receives for any URL on the site, so you can verify that a change actually appears on the front end rather than trusting the API's word for it. Returns the server-rendered HTML — content injected later by JavaScript will not appear. Optionally extracts just the SEO-relevant head tags or the visible text.

Search every searchable content type at once using WordPress's own search index, returning what type each hit belongs to. Broader than list_content's per-type search.

List the stored revisions of a piece of content, so you can see what changed and when — and recover a previous version if an edit went wrong.

Restore a piece of content to an earlier revision. The current version is itself saved as a revision first, so this is reversible.

Read the custom fields (post meta) on a content item, including keys that are not registered with show_in_rest and therefore invisible to get_content. Needs the companion plugin to see unregistered keys.

Write custom fields (post meta) on a content item, including keys not registered with show_in_rest — which core REST refuses to write. Needs the companion plugin. Values are stored as standard post meta, so they survive if this tooling is removed.

Call any WordPress REST endpoint directly — the escape hatch for anything the dedicated tools do not cover, including routes registered by plugins such as WooCommerce, Yoast or ACF. Use discover_rest_routes first to find valid routes rather than guessing: an invented route returns rest_no_route and tells you nothing.

List the REST namespaces and routes the site actually registers, including those added by plugins. Use this before rest_api so you call routes that exist — WordPress route shapes vary between plugin versions and guessing wastes calls.

List every WP-CLI command run_wp_cli will accept. The allowlist is default-deny: anything not listed here is refused, no matter how it is phrased. Each entry says whether it writes.

Run a WP-CLI command against the site. Commands are emulated in PHP by the companion plugin — no WP-CLI binary or SSH access is needed on the host. Only allowlisted commands run (see list_cli_commands); everything else is refused. Writing commands need an Administrator account, and search-replace always previews as a dry run before it will touch anything.

Run a SQL query against the WordPress database through the companion plugin. SELECT/SHOW/DESCRIBE/EXPLAIN run immediately with an enforced row limit. Anything that mutates data is blocked unless you pass allow_mutation: true, and even then it first returns a preview and a confirm_token that you must echo back — stacked statements are always refused. Reach for this only when the REST API and WP-CLI cannot get at the data: raw SQL bypasses WordPress hooks, so caches are not invalidated and plugin logic does not run.

List the abilities registered on the site through the WordPress Abilities API — capabilities that plugins such as WPForms, AIOSEO or SeedProd expose for programmatic use. Running a plugin's own ability is always safer than writing to its tables directly, because the plugin's validation, hooks and cache invalidation still run.

Get the full definition of one ability, including its input and output schemas and whether it is destructive, so you can call it correctly the first time. Ability names are namespaced, e.g. "my-plugin/get-site-info".

Execute an ability registered through the WordPress Abilities API. This is the preferred way to write data a plugin owns — the plugin's own validation, hooks and cache invalidation all run, which raw SQL would bypass. Check get_ability_info for the input schema first. The Abilities API maps intent onto HTTP methods: read-only abilities use GET, ordinary ones POST, and destructive ones DELETE; this is chosen automatically unless you override it.

Add PHP, CSS or JavaScript to the site as a managed snippet rather than by editing theme files — so it survives theme updates and can be switched off without touching code. New snippets are always created DISABLED: you activate them in wp-admin after reading the code. PHP snippets are syntax-checked before they are saved, so a parse error is reported rather than fataling the site.

Register custom fields that appear as native meta boxes in wp-admin (or as a settings page for site-wide options), and are automatically exposed to the REST API so they can be read and written afterwards. Use this when building a theme so the site stays editable by humans without touching code. Values are stored as ordinary post meta or options, so the data survives even if this tooling is removed. Thirteen field types are supported: text, textarea, wysiwyg, number, email, url, date, select, checkbox, radio, color, image, gallery, repeater.

List the editable field groups registered on the site, with their fields and where each appears. Check here before registering a group so you extend an existing one rather than duplicating it.

Remove a registered field group. The stored values are left in place, so the data is not lost and the group can be re-registered to expose it again.

Read values from the WordPress options table by name — where plugins and themes keep their configuration. Autoloaded options are also where a bloated database often hides.

Write a value to the WordPress options table. Options drive plugin and theme behaviour, and a wrong value can break the site — read the current value first with get_options, and prefer a plugin's own settings screen or ability where one exists.

Apply the same change to many items at once — set a status, reassign an author, add a category, or run a find/replace across bodies. Always previews first: the initial call reports exactly which items would change and how, and returns a confirm_token you must echo back to apply it. Nothing is written without that token.

Sweep a content type and report the problems worth fixing: missing SEO titles and descriptions, missing or duplicate H1s, thin content, missing featured images, missing excerpts, uncategorised posts, and images without alt text. Read-only — it names the issues and the IDs so you can fix them with bulk_update_content or update_content.

Audit the media library for images missing alt text and for attachments not referenced by any content. Alt text is the highest-value accessibility fix on most sites, and unused media is where disk usage quietly accumulates.

Load the playbook for the task at hand — a focused guide covering how to do this particular kind of WordPress work correctly, including the traps that are not obvious from the API. Call this FIRST when starting any substantive task: describe what you are about to do and the matching skill is returned. Page builders in particular (Elementor, Divi, Beaver Builder, Bricks, Breakdance) store content in builder-specific structures, and editing their posts as ordinary HTML corrupts the layout — the playbook explains what to do instead.

List every available playbook — the bundled ones and any you have saved. Saved skills shadow bundled ones with the same name.

Save a playbook so future sessions follow the same conventions — your site's structure, a client's tone of voice, a deployment routine, the fields a particular theme expects. Written to ~/.wpxmcp/skills and loaded by load_skill from then on. Saving a skill with a bundled skill's name overrides it.

Delete one of your saved playbooks. Bundled playbooks cannot be deleted, but a saved skill of the same name will override one.