Skip to main content
Glama

Update a theme

wp_update_theme
Destructive

Update an installed theme to the version WordPress offers, with automatic rollback if the site fails a check. Use it to apply a theme update safely, one site at a time.

Instructions

Update an installed theme to the version WordPress offers for it (wp_get_update_status lists the offers); new themes are installed by wp_install_theme. Needs update_themes; refused under DISALLOW_FILE_MODS and when nothing is offered. A kept update answers with updated, stylesheet, role, version_before, version_after, probe, warning and note. It works like WordPress's update button: an active plugin stays active, a theme stays in use, and the previous version is moved aside first. Where the code runs on this site (an active plugin, the active theme or its parent), visitors see the maintenance page (HTTP 503) until the check ends (before WordPress 6.6 only while files are copied), and 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. A new fatal error, a target that stops answering or an MCP endpoint that loses its own answer puts the previous version back in the same call, and the answer, an error, says what failed where. After a new fatal error or a lost MCP answer, AlphaBridge also asks WordPress's automatic updates to leave that version alone, and the answer says whether and for how long that holds; a new call of this tool tries it again. A fatal error that was there before, or a redirect or wp_die() at the home page or admin-post.php, keeps the update with a warning. Updated without a test, with the warning "not checked": an inactive plugin or theme, a site that cannot reach itself, an update that leaves no time for the test (a large package on a slow host). Not checked: other wp-admin screens, cron, AJAX, code that runs only on some pages or for other users. Only files are put back; what the new version changes in the database stays. No undo point: the previous version comes back only within this call. One update per site (per network on multisite) runs at a time, and none during an activation or a deploy into running code; a second call is refused and changes nothing. A call that timed out can still finish: about a minute later nothing is offered any more if the update was kept, and a new call names its result. AlphaBridge itself is not updated through this tool.

Input Schema

NameRequiredDescriptionDefault
stylesheetYesExact directory name of an installed theme as wp_list_themes reports it, e.g. "twentytwentyfour"; anything else is refused.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv4.10.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations declare destructive=true, readOnly=false, idempotent=false, openWorld=true, but the description adds extensive context beyond them: capability requirements, rollback behavior on fatal errors or lost MCP answers, maintenance page visibility, warning conditions when testing is skipped, database changes not being reverted, and concurrency limits with timeout behavior.

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

Conciseness4/5

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

The description is long, but purpose and alternatives are front-loaded and most sentences add operational detail relevant to a destructive, stateful update. Some clauses are dense and could be organized into clearer sections, but the length is largely justified by the tool's complexity.

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?

No output schema exists, and the description thoroughly covers return fields (updated, stylesheet, role, version_before, version_after, probe, warning, note), error outcomes, rollback limits, testing caveats, and concurrency constraints. An agent has enough information to call this tool correctly and interpret its behavior.

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?

The schema has 100% description coverage and fully explains the single stylesheet parameter, including that it must be the exact directory name as reported by wp_list_themes. The description adds no parameter-specific meaning beyond that, so the baseline score of 3 is appropriate.

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: update an installed theme to the version WordPress offers. It explicitly distinguishes from wp_install_theme for new themes and wp_get_update_status for listing offers, so an agent can identify the correct tool without opening schemas.

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

Usage Guidelines5/5

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

Explicitly names alternatives and conditions: wp_get_update_status lists offers, wp_install_theme installs new themes, and this tool requires update_themes and is refused under DISALLOW_FILE_MODS or when no update is offered. It also says AlphaBridge itself is not updated through this tool.

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

Deploy Server

Other Tools