Skip to main content
Glama

Install a plugin from a ZIP

wp_install_plugin_zip
Destructive

Install a WordPress plugin from a ZIP archive using base64 content or a public URL, with optional activation and a preview-confirm step to prevent unintended changes.

Instructions

Install a plugin from a ZIP archive: base64 "content" or a public http(s) "url" the site downloads, each up to 30 MB by default; where AlphaBridge MCP Pro is active, also a committed upload "session" of its chunked uploads, for larger archives. A session given is used first, then content, then url. Optionally activates it. Plugins from the WordPress.org directory are installed by slug with wp_install_plugin. Needs install_plugins (and activate_plugins for activate; without it activated stays false); refused when DISALLOW_FILE_MODS is set. Returns installed, plugin (its file) and activated, plus what the activation check reports; no undo point is recorded. Where the plugin's folder exists already, nothing is changed and the answer names the version installed, so a repeated call installs nothing twice; an installed plugin is brought to a newer version with wp_update_plugin. With activate, the activation is checked as with wp_activate_plugin and wp_activate_theme: where the site does worse with it active, it is taken back in the same call, and the answer, an error, names the error with file and line; what was installed stays installed. Runs in two steps: a call without confirm_token changes nothing and returns a preview with a confirm_token, and the same call with that token runs it. This guards against a call nobody meant; it does not make the change reversible.

Input Schema

NameRequiredDescriptionDefault
urlNoPublic http or https address of a plugin .zip; the site downloads it (up to 30 MB by default, three redirects). Used when neither session nor content is given.
contentNoBase64-encoded plugin .zip, up to 30 MB by default (filter ab_mcp_install_max_bytes).
sessionNoId of a committed chunked-upload session of AlphaBridge MCP Pro holding the .zip, for archives over the content and url limit; used first when given. Refused where Pro is not active.
activateNotrue activates the plugin after install (needs activate_plugins). Default false.
confirm_tokenNoConfirmation from the preview: a call without it changes nothing and answers with a preview and a confirm_token, and the same arguments with that token run the tool. A token is valid for 10 minutes and only while what it covers is unchanged.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv4.10.0

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations: it discloses 'no undo point is recorded', the two-step preview/confirm_token guard and its 10-minute validity, no-op behavior when the plugin folder already exists, and an activation rollback if the site gets worse, with the error naming file and line while the install persists. These are exactly the mutation-side risks the destructive/openWorld hints flag but do not explain.

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?

Front-loaded with the core action and packed with information-dense clauses; every sentence carries real content. It is a single long block with several run-on constructions (source precedence, version handling, activation check, confirm flow all in one paragraph), which costs some readability.

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, 5-parameter, no-output-schema mutation tool, the description covers return values ('installed, plugin, activated' plus activation check output), failure modes, idempotency behavior, and the confirm workflow, so an agent can invoke it correctly without further guessing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline would be 3, but the description adds semantics the schema lacks: the precedence order among session/content/url, the default 30 MB limit shared across sources, and session's dependence on AlphaBridge MCP Pro being active.

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 (install a plugin from a ZIP archive) and immediately distinguishes itself from wp_install_plugin (directory plugins by slug) and wp_update_plugin (upgrading an already-installed plugin), while also implicitly separating it from wp_install_theme_zip by naming the resource 'plugin'.

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?

Gives explicit source-selection rules ('A session given is used first, then content, then url'), routes directory installs to wp_install_plugin and upgrades to wp_update_plugin, and states prerequisites (install_plugins, activate_plugins) plus the DISALLOW_FILE_MODS refusal condition. Nothing about when to use it is left to inference.

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