Skip to main content
Glama

Update a plugin

wp_update_plugin
Destructive

Updates an installed WordPress plugin to the version currently offered, keeping it active and restoring the previous version automatically if the site fails its safety checks.

Instructions

Update an installed plugin to the version WordPress offers for it (wp_get_update_status lists the offers); new plugins are installed by wp_install_plugin. Needs update_plugins; refused under DISALLOW_FILE_MODS, for a plugin of a single file and when nothing is offered. A kept update answers with updated, 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
pluginYesExact plugin file of an installed plugin as wp_list_plugins lists it, e.g. akismet/akismet.php.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv4.10.0

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already declare destructiveness and non-idempotency, but the description goes far beyond them: required capability (update_plugins), maintenance-mode 503 behavior for visitors, the exact probes performed, automatic rollback on fatal error/unreachable target/lost MCP answer, what is and is not restored (files yes, DB changes no), no undo point, and concurrency limits. That is precisely the kind of behavioral context annotations cannot express.

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 purpose is correctly front-loaded in the first sentence, but the remainder is a very dense run-on prose block packed with parentheticals and abbreviations that is hard to parse at a glance. The content is largely earned given the tool's complexity, but it would benefit from being broken into shorter statements or bullets.

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?

For a destructive mutation with rollback semantics and no output schema, the description covers everything an agent needs: preconditions, refusal cases, the shape of a kept update's response (updated, version_before, version_after, probe, warning, note), what an error reports, and timeout recovery behavior. Nothing material is left unexplained.

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 schema already explains the single 'plugin' parameter, including the akismet/akismet.php example. The description adds only an indirect pointer (wp_list_plugins as the source of the exact file), so the baseline of 3 is appropriate when the schema does the heavy lifting.

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?

The first sentence states a specific verb and resource ('Update an installed plugin to the version WordPress offers for it') and immediately names the sibling that supplies the offers (wp_get_update_status) and the sibling that handles the other case (wp_install_plugin). An agent can distinguish this from wp_install_plugin, wp_update_theme, wp_update_core without opening any schema.

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?

It states when to use it, where the target version comes from, the explicit alternative for new plugins, the specific refusal conditions (DISALLOW_FILE_MODS, single-file plugin, nothing offered, concurrent update, during activation/deploy), and an exclusion ('AlphaBridge itself is not updated through this tool'). This is close to exhaustive guidance.

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