A coordinated stack that makes WordPress natively operable by any AI. Your server. Your data. Your keys. No SaaS layer, no escape hatch, no lock-in.
The vibe-coder who builds with AI as co-pilot. The operator running a business across seven dashboards. The developer who wants to own the infrastructure layer. Three audiences. One stack. Different reasons to stop clicking and start talking.
Every morning you open six dashboards. Your CRM doesn't know what your community platform knows. Your support tool doesn't know what your course platform knows. You're manually correlating data between silos that will never talk to each other — because they live in different databases owned by different companies.
With the Trinity, one conversation covers all of it. Ask about your subscribers, your bookings, your support tickets, your course completions — and get back a unified answer from one database. The dashboard doesn't get better. It becomes optional.
You use AI as a co-pilot for everything. But when it comes to WordPress — the platform that runs half your clients' sites — the AI has to stop at the admin panel door. It can write the code. It can't run the site.
The Abilities API changes this. Your AI connects through schema-validated, permission-gated abilities — annotated with what's safe to call freely and what needs confirmation. Build, deploy, diagnose, iterate. In a conversation, not a browser.
Every tool that puts AI inside a plugin answers the same way: their servers, their context window, their data. You lose access the moment you stop paying. The intelligence layer belongs to them.
The Trinity is a different answer. Open source. Your server. Your WordPress database. Your AI client of choice — Claude, GPT-4o, Gemini, anything that speaks MCP. Provider-agnostic by design. Sovereign by architecture.
Whether you're running one site between content sessions, operating a business across six dashboards, or managing a fleet of client sites — the Trinity changes how you work. Not what WordPress does. How you do it.
Your time is entirely yours — until WordPress needs attention. Then an hour of creating becomes an hour of clicking through menus, updating plugins with one eye closed, wondering why your last email went to spam.
With the Trinity, your site reports to you. Ask what's wrong and get a structured answer in a conversation, not a dashboard. Updates get diagnosed before they're applied. Issues surface before they break things.
The AI maintains your WordPress so you maintain your focus. Every session is a health check. Every observation is logged. The site gets smarter every time you connect.
You open six dashboards every morning. Your CRM doesn't know what your bookings platform knows. Your community doesn't know what your email knows. You're the integration layer — manually building the picture of your business from fragments owned by different vendors.
The Trinity connects the dots. Your CRM, community, bookings, support, forms, commerce — all in one WordPress database, all reachable in one conversation.
"How are my most engaged members tracking toward a booking?" That's one question. One answer. No tab-switching. No manual correlation. The AI queries the unified database and tells you what you need to know.
Client handoff is "here's the login." Diagnosis takes half a day of clicking. A 40-hour project can't become a same-day deliverable when you're navigating 20 admin panels by hand.
The Trinity scales across your entire client fleet. One MCP connection, all your sites, all routable. The Knowledge Layer builds a documented understanding of each site that any AI — or any colleague — can pick up and continue.
Handoff becomes a file, not a training session. Diagnosis becomes a session, not a project. What used to be a week of billable setup becomes an hour of conversation and a structured brief the client keeps.
77 documented WordPress pain points. The Trinity addresses more than 80% of them — in the first session. Not by adding features to WordPress. By replacing the way you operate it.
Not deprecated. Not replaced. Optional. The conversation becomes the operating layer. The dashboard becomes the review layer. Here's what that actually means.
One MCP to Bind Them All — an MCP server that runs on your machine and connects your AI client to any number of WordPress sites simultaneously. SSH for developers. HTTP for everyone. Multi-site, single-site, all sites at once.
Two transport modes, both production-hardened. One configuration file. Choose based on your environment — or run both across different sites.
Connects over your existing SSH tunnel. Spawns WP-CLI directly on the server — zero additional infrastructure, zero open ports. Uses the same key you already use to SSH in. Auto-reconnects with exponential backoff, replays the MCP handshake on reconnect.
--url= flag per subsiteConnects via HTTPS POST with WordPress Application Passwords. No SSH access required — works anywhere you can reach the WordPress REST endpoint. Session management, batch coalescing, cookie jar, automatic session recovery on expiry.
Mcp-Session-Id headersOne running instance. One config file. Six sites, two multisites, single installs — all routable from a single AI connection. Each site stays independent. Cookies don't bleed. Sessions don't mix.
The AI calls any ability with a site parameter.
The router handles the rest — same session, different servers, transparent.
Handled entirely locally inside abilities-mcp — never forwarded to any site. Infrastructure intelligence built into the bridge itself.
notifications/tools/list_changed notification so the AI client refreshes its tool list immediately. Load only what you need for the session.Open source. Free forever. Install once, connect to every WordPress site you run.
The gate. The portal. The layer that translates the entire WordPress Abilities API into the Model Context Protocol. Without it, nothing connects. With it, every registered ability on your site becomes an MCP tool — reachable by any AI client, permission-gated, schema-validated.
Install it. Activate it. That's the threshold. Before it, WordPress and AI are two separate worlds. After it, every ability on your site is reachable by any AI client through a standard connection.
Before this plugin exists, AI can talk to WordPress — through the REST API, through custom integrations someone had to build. After it exists, AI can operate WordPress.
Not read it. Not query it. Operate it — content, users, themes, plugins, health, everything — through a single structured interface that any AI understands natively.
The first thing the adapter returns when an AI connects is a complete picture of the site — every ability available, every category, what's enabled, what the AI user can reach.
The AI doesn't explore blindly. It arrives oriented. It knows what's possible before the conversation begins.
Claude, GPT-4o, Gemini, Cursor, Windsurf — any tool that speaks the Model Context Protocol connects to the adapter through the same endpoint.
You don't configure it per AI. You don't update it when you switch providers. The adapter speaks the standard. Whatever AI you're using speaks the standard. They understand each other.
Every plugin that registers abilities through the WordPress Abilities API appears in the adapter's manifest automatically. Astra, Spectra, SureCart, Presto Player — and anything the ecosystem builds next.
The adapter doesn't need to know about them in advance. They register themselves. They appear. The AI can reach them.
Every ability registered via wp_register_ability() is a candidate. The adapter runs a discovery gate — only abilities marked mcp.public: true appear in the manifest. The rest are internal.
Before any ability fires, two independent checks run in sequence inside the adapter. Both must pass. Neither can be skipped.
The AI agent connects as a WordPress user. Before the adapter does anything else, it checks is_user_logged_in(). If the user isn't authenticated, the request is rejected immediately.
Then it checks current_user_can(). The WordPress role you assign to the AI agent user is the security boundary. Not a separate config. Not a plugin setting. The role you assign in WordPress governs exactly what the AI can reach.
Only abilities explicitly marked mcp.public: true in their registration metadata appear in the manifest at all.
Everything else is invisible — not blocked with a 403, invisible. The AI cannot discover, call, or guess at abilities that aren't in the public manifest. The gate runs at startup when the tool list is built, not at call time.
Every module ships with a default permission state built into the source code. Read is on. Write is on. Delete is off — across every module, from first install. The AI cannot delete anything until you explicitly enable it.
The permission defaults are baked into the source: read: true, write: true, delete: false for every module. This is not a recommendation — it is the actual default shipped in code.
On a fresh install, the AI can read everything and write everything. But it cannot delete anything. Not content. Not users. Not terms. Nothing. You enable delete explicitly, per module, when you're ready.
Permissions work at two levels simultaneously. Module level: a single toggle covers every read, write, or delete ability in that module.
Ability level: individual overrides that differ from the module setting. You can have write enabled for the content module but content/search-replace specifically turned off.
The per-ability override always wins over the module setting.
Permissions are stored in WordPress options. The AI agent has manage_options access. Which means you can ask the AI to change its own permission scope mid-session.
"Turn off write access to users." "Enable delete for the cache module." The AI executes the change immediately.
This is not a bug. It is the design. The human controls the conversation. The human decides when to expand or restrict.
The permission gate fires inside the callback wrapper at the moment an ability is called — not at registration, not at discovery.
A disabled ability still appears in the manifest. It can be listed. It just returns a 403 when called. This means you can see what's turned off, not just what's on — which matters when you're auditing what the AI can and cannot do.
Every ability carries MCP annotations that tell the AI client its safety profile. No guessing. No prompting required.
Safe to call freely. No state change. The AI calls these without asking — get-site-map, discover-types, list-users, site-health/pulse.
All 15 Knowledge Layer read abilities carry this annotation.
Creates or modifies state but is not permanent. Content updates, meta writes, term assignments.
The behavioral directive from the Knowledge Layer controls whether the AI calls these without a human directive in the current session.
Irreversible. Requires explicit human confirmation in the conversation before the AI proceeds.
The adapter's own execute-ability carries this annotation — which is why it doesn't appear in the public manifest.
Safe to retry if uncertain whether a previous call completed.
get-started and discover-abilities both carry this — the AI can call them again after a dropped connection without risk.
Free on GitHub, or get it from our shop and receive automatic updates directly in your WordPress admin.
The enchanted world. 137 abilities across 21 WordPress modules — every surface the platform exposes, now operable from any AI chat interface. Content, blocks, themes, users, filesystem, cron, revisions — all of it, without ever opening the admin panel.
Plus four third-party suite loaders — Astra, Spectra, SureCart, Presto Player. Each bails early if the plugin isn't active. Zero cost, clean manifest.
These aren't admin shortcuts. They're operational capabilities that didn't exist for AI before the Abilities API — and before this plugin filled it.
From the live site helenawillow.com — session 4. The AI arrives, boots, reads, waits. Nothing written until the human says go.
Free tier on GitHub. Full Pro — including write and delete abilities — available from our shop with automatic updates in your WordPress admin.
The Knowledge Layer is not a feature. It is memory infrastructure — kl_* database tables inside your own WordPress, growing richer with every session. Agents, skills, protocols, session logs, observations. The site itself becomes the shared state between every AI that ever connects.
Every session begins with the same sequence — no exceptions. The AI reads these files in order before presenting anything to the human. By the time you see the first word, the AI already knows your site.
Pre-written modes that define how the AI operates in a given session. The human chooses a role — or the AI suggests one based on context. Each role has defined lanes, permission defaults, and a distinct operating style.
The difference: a log records what happened (past tense, compliance). Operational memory records what was learned (present tense, actionable). The Knowledge Layer is the latter.
The AI reads everything. Writes nothing until you say go. This is not a limitation — it is what makes it trustworthy.
Claude runs Monday. GPT runs Wednesday. Gemini runs Friday. The observations are in WordPress — not in any provider's context window. The site remembers what every agent learned, regardless of who wrote the finding.
wp knowledge list-observations --severity=action_neededFree to install. Open source. Your server. Your data. No account required to begin.