Skip to main content
Glama

Activate a plugin

wp_activate_plugin
Destructive

Activate an installed WordPress plugin by its file identifier, checking site responses before and after and rolling back if activation triggers a fatal error.

Instructions

Activate an installed plugin on this site, named by its file as wp_list_plugins lists it (e.g. akismet/akismet.php); installing is wp_install_plugin; network-wide activation on a multisite network is done under Network Admin › Plugins. Needs activate_plugins. A plugin taken back after a failed check is deactivated without its deactivation routine, as WordPress does after a fatal error. 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.

Input Schema

NameRequiredDescriptionDefault
pluginYesPlugin identifier as wp_list_plugins returns it in file: folder and main file, e.g. "akismet/akismet.php" (a single-file plugin as "hello.php").

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?

Beyond the annotations, the description discloses authorization requirements, test-request behavior, rollback on fatal errors or endpoint failure, warning behavior when the site cannot reach itself, concurrency refusal, and the fact that a failed activation is deactivated without running its deactivation routine. It also clearly states what is not checked, such as cron, AJAX, and other wp-admin screens.

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 definition is front-loaded with purpose, naming convention, and alternatives before moving into behavior. It is dense and long, but the length is largely justified by the destructive activation checks, rollback rules, and edge cases; it could still be more structured than one monolithic paragraph.

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 activation tool with one parameter, no output schema, and rich annotations, the description covers authorization, test behavior, rollback semantics, warning messages, concurrency, and explicitly excluded checks. An agent has enough context to invoke it and understand the main failure modes.

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 for the single plugin parameter, including the same akismet/akismet.php example and wp_list_plugins reference. The description reinforces the required file format and ties it to an installed plugin, but it does not add substantially new parameter semantics beyond the schema.

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 description states a specific verb and resource: activate an installed plugin on this site, named by its file as wp_list_plugins lists it. It explicitly distinguishes installation via wp_install_plugin and network-wide activation via Network Admin, so an agent can separate it from nearby sibling tools.

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 gives the use case directly: activate an installed plugin on this site, using the file identifier that wp_list_plugins returns. It also names alternatives and prerequisites: installing belongs to wp_install_plugin, network-wide activation is handled under Network Admin, and the caller needs activate_plugins.

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