On Page Navigation
On Page Navigation
Our WordPress plugin turns a site into an MCP server exposing 382 tools, across core, WooCommerce, Yoast, Rank Math, Contact Form 7, Elementor and Jetpack. It is free and it is on the plugin directory, so installing it costs you nothing at all. What nobody hands you is a decision about which of those 382 an agent should hold, which user it connects as, and what happens the first time it misreads an instruction. That is the part we run.
Three hundred and eighty two tools, and a shorter list
Installing the plugin takes an afternoon, and we built it to be that easy on purpose. Far fewer people will sit down first and work out what an agent should never be allowed to do. The second job is the one that matters once the agent can publish to a site your customers read.
So the setup below is mostly about boundaries. Which post types an agent may read, which it may draft, and what it is never allowed to publish without a person looking first. An application password scoped to its own user rather than an administrator account borrowed from somebody on your team. Revocation that takes one click and breaks nothing else. Every action logged and attributable. And a written scope you sign off before the connector touches a live site, because the alternative is finding the limits in public.
WordPress checks capabilities on every request, which is a real protection and also the thing people accidentally switch off. Connect as an administrator and the agent can install plugins, edit users and change the site URL, none of which anybody intended. We build a user whose role carries only the capabilities the work needs, so the ceiling is set deliberately rather than by accident.
Every server starts able to look and not touch. Write tools go on individually, each one tested before the next is added. Publishing, deleting and user management come last of all, because those are the three that produce a phone call rather than a support ticket. Plenty of setups never enable them at all.
Most managed hosts hand you a staging site for nothing, so prompts run against a copy before anything points at production. The interesting failures happen somewhere nobody is reading. What a model does with an ambiguous instruction is worth learning before it is holding your published content.
Application passwords are per user and individually revocable, which makes them the right mechanism and the one people misuse. One password shared across four clients cannot be revoked without breaking all four. ChatGPT connects over OAuth with PKCE instead, so two trust models sit on one site. We configure both and write down which is which.
One document covering every tool enabled, every profile configured and the service user sitting behind them. When somebody asks whether the agent can delete a page, that becomes a lookup rather than an investigation.
The plugin runs on your own site on your own credentials, and it stays free and installed whether we are involved or not. We manage it rather than own it, so leaving costs you a revocation and a handover document rather than a migration.
Why the short list beats the fast install
Most teams connect an agent the quickest way that works, which usually means an application password generated against whichever login already had administrator. Nothing goes wrong on day one. Every row below is about who carries the consequence later.
Wiring it up in a hurry means generating an application password against whoever already held administrator. The agent inherits that reach permanently, and nobody goes back to narrow it.
The fast path enables all 382 tools at once, delete and publish included. That is fine until an agent reads a vague instruction generously and changes something a customer then reads before you do.
Capabilities and access profiles are both real protections, and both only work if a person reads them. Configured in a hurry, they become a permission set nobody can describe six months later.
Passwords get revoked, plugins update and clients stop authenticating. Coverage includes unlimited repairs on the connections we manage, with no charge per incident and no queue to join.
The tool surface sits on top of core, WooCommerce and whichever SEO plugins you run, so any one of those updating can quietly alter what a tool returns. We test that on staging rather than hear about it from you.
WordPress records revisions for every edit and almost nobody opens them. Without somebody reading them, a tool being used in a way nobody intended stays invisible until it matters.
Where this is worth the money
This earns its place fastest where the site makes money, or where somebody is about to connect an agent and nobody has yet decided what it should be allowed to do.
How the install runs
The first conversation is about what an agent must never be allowed to do. That is harder than installing the plugin, and it is the part that decides whether any of this goes well.
1
Which of the 382 tools the agents genuinely need, which profile holds them, and which user the connection runs as. We argue for a far shorter list than most people start with, and write down what was left out and why.
2
The plugin goes on able to look and not touch, connected under a dedicated user with its own application password and its own profile. Prompts run against a staging site so the failure modes show up well before production is involved.
3
Write tools go on one at a time, each tested before the next, with publish, delete and user management last of all or not at all. After that it is monitoring, revision review, repairs when a connection drops, and a monthly note on what the agents actually did.
Pricing
Monthly Subscription
DETAILS
Monthly Subscription
DETAILS
Testimonials
Everything included
