Run your first write MCP request
Do this only after a read request has succeeded and you have read Enabling writes. The first write is a test of the configuration, not a piece of real work.
Set up the test
Use staging if you have one. If you do not, use a draft post created for this purpose — something you can delete afterwards without consequence.
Then:
- Take a backup and confirm it restores.
- Open only the Allow content writes gate.
- Confirm the acting user in the recent log from your read test.
- Create a throwaway draft post and note its ID.
Leave the option, POM Theme and WooCommerce gates closed. The content gate alone is enough for this test and is the least dangerous of the four.
Ask for one bounded change
Read post 412, show me its current title, then change the title to "MCP test" and read it back to confirm.
That phrasing does three useful things: it forces a read before the write, it names exactly one record, and it asks for verification afterwards.
Avoid anything plural for a first write. "Update all the drafts" is a fine instruction and a terrible first test.
What should happen
- The assistant reads the post and reports the current title.
- It calls a write tool with the new title.
- It reads the post back and reports the new title.
Verify independently
Do not rely on the assistant's report.
In WordPress, open the post and confirm the title changed and that nothing else did — status, date, author, categories, content.
In the log, at Settings → POM AI → MCP server, confirm you see the read, the write and the second read, in that order, with success status and the expected acting user. Select the write entry to see the arguments.
That comparison — what you asked for versus what the log records — is the habit worth forming. It is how you would catch an assistant doing more than you intended.
Then close the gate
Turn Allow content writes back off, delete the test post and note what you learned:
- which tool the assistant chose;
- whether it read before writing without being told;
- whether it stayed within the record you named;
- whether it verified afterwards.
An assistant that ranged wider than instructed on a trivial task will do the same on a real one. That is worth knowing before it matters.
When the write is refused
| Message | Meaning | Fix |
|---|---|---|
| The write group is disabled in POM AI MCP settings | The gate is closed | Open the right gate |
pom_ai_mcp_scope_denied |
The token lacks a required operation scope | Re-authorize with that scope; include read scopes for verification |
pom_ai_mcp_forbidden |
The acting user lacks the WordPress capability | Use a user that has it |
| API key write tools require a configured service user | No service user is configured | Configure a user with the required capabilities, or use OAuth |
pom_ai_mcp_missing_argument |
A required argument was omitted | The assistant should retry with it |
| Rate limited | More than 20 writes in a minute | Slow down |
A refusal is the system working. Nothing was changed.
Scaling up carefully
Once the first write works:
- Widen one gate at a time, and only when a task needs it.
- Keep batches small until you trust the pattern. Ten records, checked, then more.
- Ask for dry runs where the tool supports them.
- Prefer drafts over published content while you are still learning what the assistant does.
- Read the log after every session that wrote.
The operations to be most careful with
Some writes are far harder to undo than a title change:
- deleting posts, terms, media or comments;
- prices, stock and coupon changes;
- theme settings and templates, which affect every page using them;
- content model changes — post types, taxonomies, custom fields;
- option writes, which can affect the whole site.
Do these on staging first, with a backup, and read MCP boundaries before granting the scopes that reach them.