Novamira: an MCP server that gives AI agents PHP execution inside WordPress

The gap Novamira fills: agents that can only talk to WordPress, not run inside it

Most AI tooling for WordPress works at arm's length. An agent reads a REST response, proposes a snippet, and a human pastes it into a theme file. The agent never sees whether the snippet fataled, never sees which plugin hooked the filter it was reasoning about, and never sees the actual rows in wp_options. Novamira takes the opposite position. Its stated purpose is to let agents "work directly inside WordPress", running PHP and WP-CLI, inspecting the database, and managing files against the real installation. The README lists the target surface plainly: PHP execution including $wpdb, loaded plugins, themes and WordPress APIs; WP-CLI with foreground and background execution; filesystem inspection and editing; a recoverable sandbox for new PHP files. The audience is therefore narrow and identifiable: developers and agencies maintaining WordPress sites who already use an MCP-capable client and want the agent operating on the live codebase rather than a description of it. The README's own warning block sets the boundary in six words: dev and staging environments, with backups, always.

How the connection works: direct MCP, no proxy, and a sandbox for new PHP files

The architecture is deliberately thin. Novamira installs as a WordPress plugin and acts as the MCP server; the AI client connects to that server. The README states the connection is direct between the client and the WordPress installation, and that Novamira is not a hosted proxy, so requests do not pass through Novamira servers. That matters for two reasons. First, site credentials and query results stay between your client and your host. Second, there is no vendor-side component that can rate-limit, log, or fail independently of your own server. Authentication is handled through OAuth or a WordPress Application Password, so the agent authenticates as a WordPress identity rather than through a Novamira account. On the capability side, the plugin exposes PHP execution, WP-CLI, filesystem operations, and what the README calls a recoverable sandbox for new PHP files. The sandbox detail is the most interesting design choice in the list: writing new PHP into a recoverable area implies the plugin expects agents to create code that may break, and gives a path back. The README also mentions native Block Editor workflows, media uploads, reusable skills, agent context and design guidance, plus an experimental browser workspace called Novamira Visual for watching an agent work. What the README does not describe is the internal request path, how the sandbox isolates files, or what the agent context actually contains. Those are documented elsewhere on the project site, not in the repository README.

Requirements and install path, including the ZIP detail people get wrong

The requirements are explicit: WordPress 6.9 or later, PHP 8.0 or later, a WordPress administrator account, HTTPS for remote connections (local development environments are supported without it), and an MCP-compatible client or a terminal-based coding agent using Novamira CLI. WordPress 6.9 is a recent floor, so sites pinned to older branches are out before anything else is considered. Installation runs through the WordPress admin rather than a package manager: download the release ZIP, go to Plugins, Add New, Upload Plugin, upload the ZIP, activate Novamira. Then open Novamira, Configuration, enable AI Abilities, and follow the instructions for your client and authentication method. The README carries an unusual and important warning here: use the release ZIP rather than GitHub's automatically generated source archive, because the source archive does not include the bundled Composer dependencies the MCP server needs. Anyone who clones the repository or downloads the source tarball and then wonders why the server will not start has hit exactly this. The current release line is 1.12.x, with v1.12.3 published on 2026-09-09, a week after v1.12.2, which itself followed v1.12.1 the previous day. That cadence suggests active patching, and also suggests you should pin a version rather than track the branch.

The failure mode is the feature: PHP execution as the attack surface

Novamira's core capability and its core risk are the same thing. An agent that can run PHP with $wpdb and the loaded plugin stack can also drop a table, write a file outside the intended directory, or leave a syntax error that whitescreens the site. The README does not claim otherwise; the warning block is placed above the feature list, not buried at the bottom. The recoverable sandbox covers new PHP files, which is a partial mitigation, but the README does not state that it constrains edits to existing theme or plugin files, and it does not describe a rollback for database operations. WP-CLI background execution adds a second dimension: a command can keep running after the agent's turn ends. The practical consequence is that the wrong environment is any environment you cannot restore quickly. On shared hosting with no staging copy and no recent backup, an agent with these permissions is a liability rather than a tool. The wrong tool judgement is not about the software's quality; it is about the deployment context. The README's phrase "For dev and staging environments. With backups. Always." is the project telling you where the line is.

Where Novamira sits against the REST API and WP-CLI route

The obvious alternative for automating WordPress is the built-in REST API plus WP-CLI over SSH, driven by a script or an agent that shells out. The difference in approach is structural. REST API and WP-CLI expose a fixed, enumerated set of operations: you can create a post, list users, run a registered command. Novamira instead gives the agent a general execution primitive (PHP) and a general command primitive (WP-CLI), which means the agent is not limited to endpoints someone registered in advance. That is the whole reason to choose it. It is also the whole reason to be careful. A REST-only integration cannot run an arbitrary query against a custom table; a Novamira agent can. Conversely, a REST-only integration is auditable in a way that arbitrary PHP is not, because every action maps to a named route with a capability check. If your workflow is genuinely covered by core REST routes and the commands you already have, the narrower tool is easier to reason about and easier to log. Novamira earns its place when the task requires inspecting or changing something that has no endpoint, which in WordPress is a large category: plugin internals, theme template logic, options written by third-party code.

Licence, maintenance and what the AGPL-3.0 choice implies

Novamira is licensed AGPL-3.0-or-later, and the repository's licence field matches. AGPL is the strongest of the common copyleft licences on the network dimension: if you modify the plugin and let users interact with it over a network, the licence's terms attach to that modified version in a way plain GPL does not require. For most users this is a non-issue, because they install the release ZIP unmodified and never distribute anything. It becomes relevant for agencies that fork the plugin, rebrand it, or embed it in a hosted offering. The README does not discuss commercial licensing or an exception, so there is nothing in the supplied material to suggest a dual-licence path exists. On maintenance, the visible signal is the release cadence: three patch releases in the first nine days of September 2026, and a last push to main on 2026-09-10. The README links a changelog, a security and best practices page, and a connection troubleshooting page, which is the documentation set you would expect for something that touches authentication and PHP execution. Contributions require an approved issue before a pull request, per CONTRIBUTING.md, which is a gate worth knowing before you plan to send patches. None of this tells you how long the project will be maintained; the material simply does not contain that information.

What to verify on your own install before trusting it

Because the README describes capability rather than behaviour under load or under attack, a first evaluation should be concrete. Confirm the release ZIP you downloaded contains the bundled Composer dependencies, since the README says the GitHub source archive does not. Check that your WordPress is at 6.9 or later and PHP at 8.0 or later before you start, because the plugin will not run below those floors. Decide which authentication path you are using, OAuth or an Application Password, and understand that either way the agent holds an administrator-level identity. Read the security and best practices page the README links, and the connection troubleshooting page, before connecting a client. Then test on a staging copy with a restore point you have actually verified, not one you assume exists. The recoverable sandbox is described for new PHP files only; whether it covers your editing workflow is something the README leaves open, so exercise a file edit and a database write deliberately and watch what happens. Novamira is a direct, general-purpose execution channel into WordPress. Treat the first session as a test of your own recovery process as much as of the plugin.

Editorial conclusion

Novamira fits engineers running disposable or well-backed-up WordPress dev and staging sites who want an agent to touch real plugins, themes and database rows rather than a mock. It does not fit production installs, shared hosting without PHP 8.0 and WordPress 6.9, or anyone who cannot accept an agent holding administrator-level execution. Before adopting it, install from the release ZIP rather than GitHub's source archive, confirm the Composer dependencies are bundled, and read the security page and changelog for the version you are pinning.

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. use-novamira/novamira on GitHub