AI-Canvas

Give an AI agent a controlled sandbox to vibe-code landing pages on a block-theme site.

Each canvas is a normal WordPress page (or post) whose body is a trio of files the plugin owns — index.html, style.css, script.js — stored under wp-content/uploads/ai-canvas/{post_id}/. On the front end the page renders on one of two templates: theme (theme header template part → your files → theme footer template part) or blank (your files alone — the canvas supplies its own header and footer). An external agent (Claude Code, Claude Desktop, any MCP client) writes those files, and only those files, through an MCP endpoint the plugin exposes — plus upload/search access to the Media Library.

No blocks, no editor round-trips. The files are the canonical source; writes are live immediately, and every write retains the file's previous version so the last change can be rolled back with a single call.

⚠️ Read this first

AI-Canvas deliberately trusts AI output. Whatever the agent writes into index.html / script.js is served to visitors unsanitized and runs same-origin — it can read the DOM, make credentialed REST requests, and act with the session of any logged-in viewer. This is cross-site scripting by design.

Use it only on development sites or sites where you would happily hand the agent an admin account. Do not run it on a site with real users or real customer data.

The companion Claude Code plugin

This WordPress plugin is the capability surface: the MCP endpoint, the file jail, the rendering. What the agent should do with those capabilities lives in the companion ai-canvas Claude Code plugin, and you want both halves:

• Its setup skill walks a non-technical site owner through the entire connection — plugin installs, a dedicated Editor user, the Application Password — one wp-admin step at a time, then automatically verifies the site (endpoint, auth-header passthrough, capabilities including unfiltered_html) and registers the MCP server in Claude Code.
• Its vibe skill is the guardrail set this plugin can't enforce from the server side: CSS scoping so canvas styles never bleed into the theme's header/footer, performance rules (right-sized image variants, explicit dimensions, fold-aware lazy-loading, IntersectionObserver instead of layout-reading scroll handlers), read-before-write and rollback discipline, verification of the live page in a real browser via Claude in Chrome, and plain-language reporting for non-technical users.

Without the skills, any MCP client can still connect and write files — but a generic agent tends to produce exactly the pages you don't want: theme-bleeding selectors, full-size hero images, scroll-handler jank, and no verification beyond "the write returned 200".

/plugin marketplace add a8cteam51/claude-code-plugins
/plugin install ai-canvas@a8cteam51-claude-code-plugins

Requirements

• WordPress 6.9+ (the Abilities API ships in core; the plugin deactivates its MCP surface without it)
• A block theme (uses register_block_template() and the theme's header/footer template parts)
• WordPress MCP Adapter ≥ 0.6.1 (0.6.0 has a fatal packaging bug; older versions break Claude Code tool listing). Without it, abilities still register but there is no MCP endpoint.

Setup

Recommended: install the companion Claude Code plugin and say set up AI-Canvas on https://your-site.tld — the setup skill runs the whole flow below interactively, including the verification checks.

Manual:

1. Activate mcp-adapter and ai-canvas.
2. Create an Application Password for a user who can publish pages and upload files (an Editor — see capabilities):

   wp user application-password create <user> "ai-canvas" --porcelain

3. Connect Claude Code directly over HTTP:

   claude mcp add ai-canvas https://your-site.tld/wp-json/ai-canvas/mcp \
     -s user -t http -H "Authorization: Basic $(echo -n 'user:app-password' | base64)"

   Application Passwords require HTTPS (or WP_ENVIRONMENT_TYPE=local, e.g. WordPress Studio). If your host strips the Authorization header, or you need OAuth-style auth, use the official proxy instead: @automattic/mcp-wordpress-remote.

4. Tell the agent to go wild:

   Create a canvas called "Spring Launch" and build me a landing page for…

MCP tools

Every tool requires edit_others_posts — the capability that separates an Editor from an Author across core roles — and the MCP endpoint enforces it too, so Subscribers, Contributors and Authors cannot reach the server at all, not even to list tool names. That bar deliberately sits above upload_files, so the Media Library tools are never exposed to an Author-level credential.

Writing canvas content is additionally writing unsanitized same-origin HTML, so it demands the capability WordPress already reserves for exactly that: unfiltered_html. In practice that means Editor or Administrator on a single site, super admins only on multisite, and no one when DISALLOW_UNFILTERED_HTML is defined. Because edit_others_posts survives on multisite where unfiltered_html narrows to super admins, Editors there keep the read-only tools while writes correctly do not.

The tool contract has no path parameters at all — files are addressed by post ID plus a fixed enum, so the agent cannot write anywhere else on the filesystem. Permanently deleting a canvas post removes its file set (retained previous versions included); uninstalling the plugin removes all of them.

Note that the Application Password itself is not scoped to these tools. WordPress cannot scope one: the credential you create during setup authenticates the whole REST API, so anything holding it is an Editor on that site, not a caller limited to seven tools. Treat it accordingly.

One script per page

index.html may not carry inline JavaScript. write-file rejects an html write containing a `