WordPress MCP Safety Profiles: Read Only to Full Access
WordPress MCP safety profiles in GoBuildWP: what Read Only, Production Safe and Developer Full Access allow, plus preview, confirmation and rate limits.
A safety profile is enforced on the server, which is the property that makes it worth anything. Instructions in a prompt, a system message, or a client's own settings are requests the model may or may not honour; a profile decides what the WordPress side will execute regardless of what the model was told. Choosing one is really choosing what you are willing to have happen on a bad day, not what you expect on a good one.
Read Only
Read Only is the correct starting point for audits, discovery, reporting, and connection tests. It prevents writes at the GoBuildWP policy layer while WordPress capabilities continue to apply.
Use it to inventory visible tools, inspect schemas, read representative objects, and evaluate how the client reports evidence before adding authority.
Production Safe
Production Safe permits supported site work while blocking privileged raw PHP, WP-CLI, filesystem, database, plugin or theme installation, and temporary administrator access surfaces. It is a boundary, not a promise that every permitted write is harmless.
Pair it with dedicated credentials, per-ability controls, critical confirmation, backups, and human review for important content, configuration, commerce, or shared design changes.
Developer Full Access
Developer Full Access exposes privileged development surfaces and is intended for deliberate development or staging use. Code, filesystem, database, and command execution can break or compromise a site even when the request is syntactically valid.
Keep recovery access outside the affected WordPress instance, review generated code, and test a restore path before use.
- Staging or isolated development environment
- Current backup
- Out-of-band recovery access
- Explicitly scoped task
- Human code review
- Post-change runtime test
Preview a write before it happens
For a post, page or media edit, a site settings change or a deletion, an agent can ask what the change would do and get a field-by-field diff back without anything being written. It returns a link you open in wp-admin, where you see the before and after for every field and either apply the change or throw it away. The target record stays unchanged until you apply the proposal; storing the proposal itself is a separate operation.
Applying re-checks that the target has not moved in the meantime. If someone edited the same fields while the proposal was waiting, it refuses and writes nothing rather than overwriting their work - the approval described a state that no longer exists. A change to fields outside the diff is reported as a warning and the write proceeds.
A site can require this. The setting is off by default, because turning it on changes the contract every connected agent is working to, and that is your call rather than a default. Abilities GoBuildWP cannot preview are exempt rather than blocked: refusing a write nobody can preview would remove the ability instead of reviewing it.
- Read the diff, not just the summary
- Check the fields the agent did not mention
- Apply from the screen, not by re-sending the write
- Re-run the preview if it refuses on drift
Decide who confirms a destructive call
By default the agent confirms: a destructive or critical call runs only when the model sends confirm=true, which proves the model meant it, not that a person agreed. From GoBuildWP 1.15.0, Settings > Confirmation mode can be set to "A person approves". The model's flag is then not enough; a person approves the exact call in their MCP client where the client supports that, or on a one-time wp-admin link that shows exactly what will run. Each change records how it was confirmed.
The setting is off by default, so existing connections behave as before. The Abilities screen can also require confirmation, or a minimum safety profile, for any single ability, including abilities registered by other plugins, so a third-party write can be held to the same rule as GoBuildWP's own.
Controls that stack
The active profile works alongside WordPress user capabilities, individual ability status, per-credential write rate limits, critical-action confirmation, preview before write, and the redacted change ledger. GoBuildWP Pro can add a human approval queue and approval notifications.
No single control replaces the others. Build a workflow in which the client proposes, WordPress authorizes, a person reviews high-impact work, and the team verifies the resulting site and any external provider.
Setting, narrowing and checking the profile
Where WordPress MCP safety profiles are set
The site-wide profile is one drop-down: GoBuildWP, Settings, Agent access, Safety profile, followed by Save settings. Its help text states the contract in one line: the profile is enforced on the server for MCP and REST alike, and critical and destructive calls still need explicit confirmation on top of it. A fresh install starts on Production Safe; if you have not opened Settings yet, that is the profile your first connection got.
A profile does not only refuse calls, it removes them from view. An ability the active profile does not allow is withheld from discovery, so the agent never sees it in its tool list rather than seeing it and being refused. That is why switching from Read Only to Production Safe changes the length of the tool list an agent reports, and why an agent asked to do something the profile forbids often says it has no tool for the job instead of quoting a refusal.
Narrower than the site: credentials, Cloud and single abilities
The site's profile is a ceiling, and several things can sit below it but never above it. An access token created on Connect a client has a Safety profile ceiling, which defaults to Same as the site and can be set lower, so a reporting script can run Read Only on a site whose people work under Production Safe. Its What this token may use setting goes further and limits the token to chosen categories and abilities; anything outside that scope is hidden from it in the same way the profile hides abilities.
A site connected to GoBuildWP Cloud gets the access level chosen when it was connected, Read Only or Production Safe, and an app reaching it through Cloud is held to that, even if the site itself later moves to Developer Full Access.
Single abilities have a floor of their own. Some declare a minimum profile because they are sensitive even though they change nothing: wppilot/database-query only reads, yet it runs a raw SQL SELECT, so it appears only under Developer Full Access. On the Abilities screen you can raise any ability's minimum profile, including abilities registered by other plugins, but never lower the floor its author declared.
- Site profile: the most any connection can do
- Token ceiling and token scope: less, for one credential
- Cloud access level: less, for every app reaching the site through Cloud
- Ability minimum profile: raised per ability, never lowered below the author's floor
Choosing a profile for the job in front of you
Pick by the most dangerous call the job legitimately needs, then stop there.
- Read Only: content and SEO audits, site inventories, performance and security reports, checking what an agent would see before granting more. Only discovery and inspection abilities exist in this profile.
- Production Safe: writing and editing posts and pages, media, menus, builder layouts, forms, SEO fields and store data. Raw code execution, server filesystem access, WP-CLI and temporary administrator access are blocked, so wppilot/execute-php, wppilot/run-wp-cli, wppilot/write-file and wppilot/create-admin-access-link are not offered.
- Developer Full Access: a staging session that genuinely needs those surfaces, such as running a WP-CLI command, editing a theme file or querying the database directly. Return to Production Safe when the session ends.
Checking that a profile change took effect
After saving a new profile, start a fresh client session and ask the agent to list the abilities it can see. Compare the list with the profile: under Read Only no write ability should be listed; under Production Safe the code, filesystem and WP-CLI abilities should be missing. If the list did not change, the client is still holding the tool list from before the change.
For a credential with its own ceiling, run the same check through that credential, not through your own session, because each one sees a different list. And record the change somewhere your team will see it. A profile switched to Developer Full Access for an afternoon is easy to forget, and the Dashboard shows the active profile so anyone opening GoBuildWP can see it at a glance.
Writes that arrive through another plugin's MCP server
Elementor and WooCommerce now ship MCP servers of their own, and an agent connected to one of them reaches their abilities without passing GoBuildWP's gate. The safety profile still applies to those calls, because WordPress checks it inside every ability, and the change log records their writes; from GoBuildWP Free 1.18.0 it keeps snapshots for Elementor's and WooCommerce's, so most of them can be undone too. What they skip by default is the confirmation step, a person's approval and Pro's holds.
Settings, Other MCP servers closes that gap on WordPress 7.1. Set Approvals for their writes to On and a write through another plugin's server is checked against the profile as GoBuildWP's own transports check it; a destructive one waits for a person to approve it on a one-time wp-admin link, whichever confirmation mode the site uses, because those servers' clients have no way to send GoBuildWP's confirm flag; and Pro's approval queue and backup gate apply. Reads are never held, a call GoBuildWP already gated is not held twice, and code that runs an ability outside a web request, such as a plugin's own scheduled task, is left alone.
Questions this guide answers
What does Production Safe block?
Raw PHP, WP-CLI, filesystem access, database access, plugin and theme installation, and temporary administrator access. Ordinary content and design work still runs, and destructive or critical operations still require explicit confirmation.
Is it safe to leave Developer Full Access on?
No. It is for deliberate development or staging work. The usual failure is switching to it once to unblock something and never switching back. Do that work on staging: the profile is the last line that holds when something else goes wrong.
Can a person, rather than the model, confirm destructive calls?
Yes, from GoBuildWP 1.15.0. Set Settings > Confirmation mode to "A person approves" and the model's confirm flag is no longer enough: a person approves the exact call in their MCP client or on a one-time wp-admin link. It is off by default.
Can I see a write before it happens?
For post, page and media edits, site settings changes and deletions, yes. Preview returns a field-by-field diff of the proposed change with a wp-admin screen to approve or discard it, and the target record stays unchanged until the proposal is applied.
Review noteRequirements and credential methods follow the shipped GoBuildWP source (WordPress 6.9+, PHP 8.0+). Client menus, account plans and third-party behaviour can change; use the installed version and live schema. Our evidence standard.
Read Only: allow a permitted get-content read; refuse an edit. Production Safe: permit a supported ordinary draft-content edit; refuse execute-php. Developer Full Access: code can be permitted only with its capability and confirmation gates; a disabled or unauthorized call still fails. Before a production write, inspect the separate "A person approves" setting and any Pro hold policy.