Skip to main content
Glama

Switch the theme

wp_activate_theme
Destructive

Switch the active theme to an installed theme (wp_install_theme installs one), named by its directory as wp_list_themes lists it (e.g. "twentytwentyfour", a child theme, or "collection/theme" for a theme inside a collection). Refuses, with the reason, a theme that is broken (a child without its parent), that the network does not allow on this site, or whose PHP/WordPress requirement this site does not meet. Records an undo point that switches back to the previous theme; the token is returned in "undo" (null when no snapshot could be taken). A theme taken back after a failed check is replaced by the previous one again. Activating is checked like an update: test requests check the home page, this MCP endpoint, wp-admin/admin-post.php and the dashboard before and after, logged in as this connection's account (where a security plugin refuses that login, the dashboard is left out and the answer says so). Where a target then shows a new fatal error, stops answering, or this MCP endpoint loses its own answer, the activation is taken back in the same call; the answer, an error, names the error with file and line, and the files stay as they are, so a corrected version can be activated again. Code has to let WordPress finish every request: code that ends the answer itself (fastcgi_finish_request(), or exit in the shutdown action) is taken back too, since the test cannot tell it from a broken one, and background work belongs in WP-Cron. A fatal error that was there before keeps the activation with a warning; a site that cannot reach itself is activated without a test, with the warning "not checked". Where code on every request filters the active plugins or the theme, so the site does not load what WordPress lists as active, the answer says so and the list stays as it was. One activation, update or deploy into running code runs at a time; a second is refused and changes nothing. Not checked: other wp-admin screens, cron, AJAX, code that runs only on some pages or for other users; what an activation routine writes to the database stays. Forwarded by AlphaBridge Connect to the one site this connection reaches.

Input Schema

NameRequiredDescriptionDefault
themeYesTheme folder (stylesheet) as wp_list_themes lists it in slug, e.g. "twentytwentyfour" or "collection/theme"; a child theme is named by its own folder, not its parent's.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / theme / description
      Previous value: -"Theme directory name (slug)."New value: +"Theme folder (stylesheet) as wp_list_themes lists it in slug, e.g. \"twentytwentyfour\" or \"collection/theme\"; a child theme is named by its own folder, not its parent's."
  2. Added

TDQS

A4.3/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the destructive/non-idempotent annotations, it discloses the undo snapshot and its "undo" token, the pre/post smoke tests across home page, MCP endpoint, admin-post.php and dashboard, automatic rollback with file/line error reporting, the pre-existing-fatal-error and "not checked" edge cases, and a concurrency lock. That is a genuinely uncommon level of disclosure for a mutating tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The critical facts (what it does, what it refuses, that it rolls back) are front-loaded, so it is well ordered. But it is a single dense paragraph of semicolon-chained clauses, and some caveats (background work in WP-Cron, the not-checked list) could be trimmed or split for readability without losing the contract.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description still tells the agent what comes back: the "undo" token, its null case, and that errors name the offending file and line. It also scopes what is explicitly not verified (other admin screens, cron, AJAX), so an agent knows the limits of the guarantee it is given.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single `theme` parameter is already documented with the folder/slug convention and the child-theme caveat. The description repeats that naming rule and adds the useful pointer that wp_list_themes is how you discover valid values, but it contributes little beyond the schema — baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Switch the active theme to an installed theme") and immediately distinguishes itself from the sibling that installs (wp_install_theme) and the one that lists (wp_list_themes). An agent can tell exactly what this does and what it does not do without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The install-vs-activate split plus the slug-naming pointer to wp_list_themes gives clear selection context, and the description enumerates the conditions under which activation is refused (broken child theme, network restriction, unmet PHP/WP requirement). It lacks only an explicit "use wp_update_theme instead when..." routing for the adjacent update/deploy operations, so it lands just below the top.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources