Skip to main content
Glama

Install a theme from a ZIP

wp_install_theme_zip
Destructive

Install a WordPress theme from a ZIP file via base64 content, a public URL, or an upload session, with an optional switch to it after install and a preview token guarding the change.

Instructions

Install a theme 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 switches to it. Themes from the WordPress.org directory are installed by slug with wp_install_theme. Needs install_themes (and switch_themes for activate; without it activated stays false); refused when DISALLOW_FILE_MODS is set. Returns installed, stylesheet and activated, plus what the activation check reports. The install records no undo point; with activate, the theme switch records one where it can, returned in undo as with wp_activate_theme (null when none was recorded). Where the theme's folder exists already, nothing is changed and the answer names the version installed, so a repeated call installs nothing twice; an installed theme is brought to a newer version with wp_update_theme. 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 theme .zip; the site downloads it (up to 30 MB by default, three redirects). Used when neither session nor content is given.
contentNoBase64-encoded theme .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 switches to the theme after install (needs switch_themes). 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.6/5.0
Behavior5/5

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

Far beyond the annotations: it explains the two-step confirm_token preview gate, that a failed activation check is rolled back in the same call while the install persists, that no undo point is recorded for the install, that an existing folder short-circuits to a no-op naming the installed version, and the exact permission/constant gates. Annotations only say destructive and non-idempotent; the description carries the real 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 core (what it installs, from what sources, in what order) is front-loaded, and everything after earns its place given the tool's complexity. It is still a dense block — the activation-check and undo paragraphs could be tightened — but nothing is filler.

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, yet the description names the returned fields (installed, stylesheet, activated) and the undo entry behavior, and covers the destructive semantics, permission gates and confirmation flow. Nothing needed to invoke it correctly is missing.

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 descriptions already document the source precedence, the 30 MB cap and the 10-minute token validity, so the description mostly restates them. The consolidated precedence statement adds marginal value over the per-property text but no new semantics.

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?

Opens with a specific verb+resource (install a theme from a ZIP archive) and immediately distinguishes itself from wp_install_theme, which handles WordPress.org slugs. An agent can route between the two without opening the 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?

Gives an explicit source-precedence rule (session first, then content, then url), names the sibling for directory slugs, and routes version bumps to wp_update_theme. It also states permission requirements and the DISALLOW_FILE_MODS refusal condition, so when-to-use and when-not are both covered.

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