Account MCP vs Site MCP on InstaWP: What Each One Does and When to Use It

InstaWP now gives you two ways to hand WordPress over to an AI assistant, and they sound almost identical: the account MCP and the site MCP (InstaMCP). People connect one, ask it to do something it was never built for, and conclude the feature is broken. It is not. They are two different doors into two different layers of your stack.

Here is the whole thing in one line: the account MCP runs your sites from the outside, across your whole account. The site MCP works inside one site. One provisions, backs up, updates and bills. The other writes posts, edits blocks and uploads media. This guide breaks down exactly what each one controls, what they share, when to use which, and why most agencies end up running both.

The mental model: the building manager and the interior designer

Think of your InstaWP account as an apartment building and each WordPress site as a unit inside it.

The account MCP is the building manager. They hold keys to the whole property. They can put up a new unit, back one up before renovation, restore it if a job goes wrong, upgrade the plumbing (your PHP and WordPress versions), change the locks (WordPress users), and tell you what the rent is. What they will not do is choose your sofa: they never write or rearrange your content.

The site MCP is the interior designer inside one unit. They know every room, every fitting, every wall. They can rewrite the content, rearrange the blocks, install a new appliance (a plugin), swap the whole look (a theme), and read the smoke alarm log when something smells wrong. What they cannot do is build you a second apartment. They only have keys to the one they are standing in.

What the account MCP actually does

The account MCP is a single connection between your AI client and your InstaWP account. It is scoped to your current team, so everything that team can see, your AI can work with, from one endpoint. You switch it on in Profile, then MCP, in your InstaWP account, where it sits disabled by default. Its tools come in nine groups, each with its own switch.

The capabilities it ships with

Six groups start on. Site actions, Access & logs and Teams start off, and only the account owner can turn them on. Some accounts also see three Sensitive groups, which InstaWP offers only to accounts it enables and which start off too: credentials and secrets (site logins, SSH and SFTP details, MCP tokens), shell and WP-CLI (arbitrary command execution), and act inside sites (direct read and write access into the WordPress installs themselves). That last one matters for this comparison, and we come back to it below.

How you connect it

Connection is OAuth. You copy one connection URL into your AI client, approve the request on an InstaWP consent screen, and you are done. There is no API key to generate, paste, or rotate, and nothing secret ends up sitting in a config file. Claude users can skip the URL, because InstaWP is listed in Claude’s connectors directory. Because the grant is per client, you can connect Claude, Cursor and ChatGPT to the same account and revoke any one of them independently. The full walkthrough lives in the docs guide to connecting AI assistants to your account.

Watch the video tutorial.

What the site MCP (InstaMCP) actually does

The site MCP is InstaMCP, the per-site server that lives with the WordPress install itself. You enable it from Sites → your site → Site Details → MCP in the sidebar, and the docs cover the setup in detail in connect AI assistants to your WordPress site using MCP. Flip the switch and InstaWP generates a connection URL for that one site, with a 64-character authentication token embedded in it. Treat that URL like a password.

Where the account MCP works on sites from the outside, InstaMCP exposes 43 tools that map onto the guts of WordPress:

Two of those categories are easy to skim past and are quietly the most useful. Skills are Markdown playbooks stored on the site that teach the AI how your team does a job, so “build a landing page” produces your house layout rather than a generic one. Memory stores durable facts about that specific site, so the assistant remembers the client uses Bricks, or that the staging URL is not the live one.

Side by side: every difference that matters

The row worth staring at is number of connections. If you run five sites, wiring up five site MCPs is fine. If you run forty client sites, adding forty MCP servers to Claude or Cursor is unworkable, and most AI clients start to strain long before you get there. That is the structural reason the account MCP exists, and the reason agencies should start there.

What they have in common

The differences get the attention, but the shared design is what makes them safe to run together.

• Same protocol, same clients. Both speak MCP, so both work with Claude, Cursor, VS Code, Copilot, ChatGPT, Windsurf, Cline, Zed, Codex, Gemini and the rest. You are not learning two tools, just pointing at two endpoints.
• Both are off until you turn them on. Nothing is exposed to any AI by default, at either layer.
• Both use a two-gate model. Enabling the MCP is gate one. Enabling its dangerous tools is a separate gate two, which enabling the MCP never opens for you. That is deliberate defence in depth: even if something arms a site’s MCP, the site’s own power tools stay shut.
• Both are hosted for you. There is no MCP server to deploy, no Node process to babysit, no tunnel to keep alive. This is the main practical difference from rolling your own WordPress MCP server.
• Both are revocable. Turn the toggle off, or revoke the specific client or token, and access stops immediately.

Use cases: when you want the account MCP

Reach for the account MCP whenever the question is about sites as objects rather than what is inside them.

1. Provisioning without leaving your editor

A client calls mid-sprint and wants to see an idea. “Create a sandbox called acme-demo on PHP 8.3.” The site exists before the call ends. No dashboard, no tab-switch, no losing your place in the task you were already doing.

2. Backup discipline you will actually keep

Everyone agrees you should back up before a risky plugin update. Almost nobody does it every time, because it is four clicks in a dashboard you do not have open. When “back it up, then update it” is one sentence to the assistant you are already talking to, the habit sticks. This is the single highest-value use case for most teams, and it is the cheapest insurance in WordPress.

3. Fleet-wide answers in one question

“Which of my sites are still on PHP 8.1?” “Which sites have plugin updates waiting?” Answering that manually across a 40-site portfolio is an afternoon with a spreadsheet. Here it is one prompt, because the account MCP already sees the whole team.

4. Maintenance retainers that run themselves

Monthly maintenance is the most profitable and most tedious agency work. Back up, update plugins and WordPress, read the error log, report. With Site actions and Access & logs on, the account MCP runs that whole checklist as a conversation, which means a junior can run the round and the output is consistent every month.

5. Cost and plan hygiene

“What plan is each client site on, and what is my current bill?” On pay-per-use hosting, knowing which forgotten demo site is still costing you money is real margin. Ask the question monthly instead of discovering it on an invoice.

6. Disaster response

A deploy goes wrong on a Friday evening. The account MCP is the layer that lists backups and restores one, either over the site or as a new site, which is exactly the layer you want when the site itself is too broken to talk to.

7. Client handover and support

“Create an editor account for the client on acme-shop and make the site permanent.” WordPress emails them a link to set a password, so no password passes through the AI. When a customer writes in, “find the sites created for this email” answers which site they mean before you open the dashboard.

Use cases: when you want the site MCP

Reach for InstaMCP whenever the work happens inside WordPress.

1. Building pages and content by prompt

Draft a post, build a services page out of native Gutenberg blocks, upload and attach the featured image, assign the right categories. The block discovery and validation tools matter here: the AI checks its markup against the blocks the site actually has before it saves, instead of producing a page full of block-recovery errors.

2. Bulk content operations after a migration

Find and replace an old brand name across 400 posts. Re-slug a content type. Reassign taxonomies after an import went sideways. This is the classic job that is too small to justify a script and too big to do by hand, and it is where the 9 content plus 9 taxonomy tools earn their place.

3. Debugging a broken site

“This page 500s, find out why.” The AI reads the error log, maps the active plugins and theme, and traces the fatal to its source. What used to be an SFTP session and a lot of squinting becomes a conversation with something that can read the logs and the plugin source in the same breath.

4. Plugin and theme QA before it hits production

Install a candidate plugin on a sandbox, activate it, check what broke, read the logs, roll it back. Doing this on a disposable InstaWP site rather than a client’s live install is the entire point of the sandbox-first workflow.

5. WooCommerce and custom field work

The meta tools reach ACF fields and WooCommerce product data, so bulk-editing product attributes or populating custom fields across a catalogue stops being a CSV round-trip.

6. Encoding how your agency builds

Skills are the sleeper feature. Write your page-build conventions once as a Skill on a template site, and every AI session on that site follows them. It is the difference between an assistant that guesses your house style and one that knows it, which is what makes AI output shippable to a client rather than a starting point you rewrite.

Use cases: when you want both

The interesting workflows cross the boundary. Connect both and a single conversation covers the full lifecycle.

The bridge between them

The two layers are not strangers. The account MCP can arm a site’s MCP for you, so you can ask it to enable MCP on a site rather than going to that site’s settings yourself. On accounts that have the act inside sites capability, switching it on lets the account MCP reach through into your sites directly, which is how you avoid adding a separate connection per site across a large portfolio.

Two things stay true when it does. Arming a site’s MCP never enables that site’s power tools, which remain behind their own gate in the site’s own settings. And the reach-through capability is off until you turn it on. The layers stack, but each keeps its own lock.

Which one should you turn on first?

Security: two different permission models

This is where the two genuinely diverge, and it is worth understanding before you hand either one to an assistant.

The practical takeaway: at the account layer you restrict by capability, at the site layer you restrict by WordPress role. If you want a writer’s AI to touch content but never plugins, that is a site MCP token on an Editor account, not an account MCP setting. If you want a contractor to see your fleet but change nothing, that is account MCP read-only mode.

A note on the site connection URL: it carries a 64-character token inside it, so it is a credential. Do not paste it into a shared doc, a ticket, or a Slack channel. If it leaks, revoke the token from the site’s InstaMCP settings and generate a new one. The account MCP sidesteps this class of mistake entirely, since OAuth means there is no secret string to paste anywhere.

Five mistakes people make

1. Asking the account MCP to write a blog post. It has no idea what a post is. Content lives at the site layer.
2. Asking the site MCP to create a site. It is already inside one and cannot see your account. Provisioning is the account layer.
3. Expecting power tools to work right after enabling MCP. They will not. execute_php returns a clear “disabled” error until an admin enables it in the site’s own InstaMCP settings. That is the design, not a bug.
4. Wiring up one site MCP per client site. Fine at five sites, painful at forty. Lead with the account MCP and add per-site connections only where you do deep, repeated work.
5. Handing an AI an admin-scoped site token by reflex. Match the scope to the job. Most content work needs mcp:write, not mcp:admin.

Two layers, one workflow

The account MCP and the site MCP are not competing options with a right answer. They are the hosting layer and the WordPress layer of the same idea: that you should be able to describe what you want and have it happen, without a dashboard in between.

If you only remember one thing, remember the boundary. Outside the site, use the account MCP. Inside the site, use InstaMCP. Turn on the account MCP first if you manage a portfolio, the site MCP first if you are building something. Then turn on the other one, because the workflows you actually want cross the line between them.

FAQs