Why I'm Building WP Navigator

I kept watching AI agents break WordPress sites. Not because the AI was bad — because WordPress had no structured way to tell AI what was available, what was safe to change, or what the consequences would be.

A developer would connect Claude Code to a client's WordPress site, ask it to update the homepage headline, and the AI would dump massive amounts of raw REST API data into context just to figure out what page to edit. Then it'd make the change with no preview, no diff, no rollback. Hope for the best.

The official WordPress MCP Adapter is shipping with WordPress 7.0 in April 2026. It's a solid bridge — but it's a bridge without guardrails. No preview step. No approval workflow. No token efficiency. No understanding of page builders like Elementor or WPBakery.

The Bridge Needs Guardrails

WP Navigator fills that gap. It gives AI agents 93 specialised MCP tools — organised in dynamic toolsets so only the relevant ones load into context. It adds an 8×4 guardrail policy matrix so you control exactly what AI can read, suggest, or write. And it introduces Plan-Diff-Apply: every change is previewed as a diff before anything touches your live site.

Then there are cookbooks — compact, structured references that teach AI how to use WordPress plugins in a fraction of the context instead of dumping raw documentation. Gutenberg, Elementor, WPBakery cookbooks are built. WooCommerce, Yoast SEO, and more are on the way.

The Vision

I want every WordPress site owner to have an AI expert in their pocket. One that asks before it acts, shows you what it'll change, and rolls back instantly if something goes wrong. Whether you're a developer managing 50 client sites or a small business owner updating your own homepage — the same preview-first safety model applies.

WP Navigator works with any MCP-compatible AI client. Claude Code, Gemini CLI, Codex CLI, Cursor — bring your own AI, bring your own API key. The MCP ecosystem is growing fast, and WP Navigator grows with it.