Airo WP AI Builder is a WordPress plugin that exposes your site to AI assistants via the Model Context Protocol (MCP). It also bundles a curated set of Gutenberg block patterns built on the Twenty Twenty-Five (tt5) theme, giving any connected AI a ready-made vocabulary for assembling pages.
- MCP Server — Registers an MCP-compatible endpoint. Tools cover posts, pages, media, templates, navigation menus, and global styles. Clients authenticate with a WordPress Application Password — see Connecting an AI client.
- Block Patterns — Curated Gutenberg patterns for the Twenty Twenty-Five theme, sourced from DesignSetGo (deferred automatically when DesignSetGo is active).
- AI-agnostic — Connect Claude, GPT, Gemini, or any MCP-compatible client. No specific AI is bundled or required.
- Site generation — build a complete WordPress site from a single prompt
- Conversational setup — add pages, swap images, and update layouts through plain-English chat
- WooCommerce storefront — auto-configure a storefront with AI-generated products from a single prompt
| Plugin name | Airo WP AI Builder |
| Text domain | airo-wp |
| Version | 0.3.6 |
| Requires WordPress | 6.9+ |
| Requires PHP | 7.4+ |
| License | GPLv2 or later |
| Author | GoDaddy |
| Repository | godaddy-wordpress/airo-wp |
Do not install by downloading the repository source. vendor/ and dist/ are
generated at build time and are not committed, so a source checkout or GitHub's
"Download ZIP" produces a plugin that loads nothing and registers no blocks. Use one
of these instead:
From a release (recommended) — every release attaches a built, installable zip:
- Download
airo-wp-<version>.zipfrom Releases. - In wp-admin, go to Plugins → Add New → Upload Plugin and upload it.
- Activate Airo WP AI Builder.
Automatic updates from this repository — install
Git Updater, which reads the GitHub Plugin URI,
Primary Branch and Release Asset headers in airo-wp.php and offers each new
release as a normal WordPress update. It installs the attached build, not the source
zipball. Pre-releases are flagged as such on GitHub, so Git Updater does not offer
them as updates.
From source, for development — clone the repository and build it; see CONTRIBUTORS.md.
https://example.com/wp-json/airo-wp/v1/mcp/streamable
HTTPS is required. WordPress refuses to issue or accept Application Passwords unless the site is served over SSL, so on a plain-HTTP site the credential below cannot even be created.
Application Passwords are WordPress's own mechanism — no plugin-specific secret is involved, and you revoke access in the same place you granted it.
- In wp-admin, go to Users → Profile.
- Scroll to Application Passwords, enter a name (for example
Claude), and select Add New Application Password. - Copy the generated password. WordPress shows it once and never again.
The user you create it for determines what the AI can do — see Permissions below.
Combine the WordPress username and the application password with a colon, then base64-encode the result:
printf '%s' 'admin:abcd EFGH ijkl MNOP qrst UVWX' | base64
# YWRtaW46YWJjZCBFRkdIIGlqa2wgTU5PUCBxcnN0IFVWV1g=Send that under the airowp authorization scheme:
Authorization: airowp YWRtaW46YWJjZCBFRkdIIGlqa2wgTU5PUCBxcnN0IFVWV1g=
Some clients only offer a bearer-token field rather than a full header value. For those,
prefix the same encoded string with airowp_ and send it as a bearer token:
Authorization: Bearer airowp_YWRtaW46YWJjZCBFRkdIIGlqa2wgTU5PUCBxcnN0IFVWV1g=
Both forms are equivalent. The airowp marker is what identifies the credential, so a
plain Bearer token is left untouched for other authentication schemes.
Keep the application password itself out of shared configuration files and version control — base64 is encoding, not encryption, so the encoded string is exactly as sensitive as the password.
claude mcp add --transport http airo-wp \
https://example.com/wp-json/airo-wp/v1/mcp/streamable \
--header "Authorization: airowp YWRtaW46YWJjZCBFRkdIIGlqa2wgTU5PUCBxcnN0IFVWV1g="Authentication answers who the request is from; what it may do is decided separately, by WordPress capabilities:
- reaching the endpoint at all requires the
readcapability - every tool then checks its own capability —
edit_poststo create a post,upload_filesto add media,activate_pluginsto activate a plugin, and so on
So a credential belonging to a Subscriber connects successfully and is refused by every tool that changes anything. Create the application password for a user whose role matches the access you intend to grant, rather than reaching for an administrator by default.
Clients handle this themselves; it only matters if you are testing with curl. The
transport is session-based — initialize first, then send the returned session id with
every subsequent request:
# 1. initialize — the session id comes back in the Mcp-Session-Id RESPONSE HEADER
curl -i -X POST "$ENDPOINT" \
-H 'Content-Type: application/json' \
-H "Authorization: airowp $CREDENTIAL" \
-d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"curl","version":"1.0"}}}'
# 2. every later call carries it
curl -X POST "$ENDPOINT" \
-H 'Content-Type: application/json' \
-H 'Mcp-Session-Id: <value from step 1>' \
-H "Authorization: airowp $CREDENTIAL" \
-d '{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}'Omitting the session id returns
{"code":-32600,"message":"Invalid Request: Missing Mcp-Session-Id header"} — an MCP
protocol error, not an authentication failure.
The MCP specification defines an OAuth 2.1 authorization flow with discovery. This plugin does not implement it: there is no discovery document, no consent screen and no token endpoint. The scheme above is a configured credential, so clients that require OAuth discovery cannot connect yet. Support for it is under consideration.
See CONTRIBUTORS.md for environment setup, architecture, coding standards, and pull request expectations.
GPLv2 or later. See LICENSE.