Review and confirm state-changing requests

MCP writes are immediate and real. There is no confirmation dialog, no draft state and no undo — a tool call that succeeds has already changed your site.

The controls exist, but they are configuration you set in advance, not a prompt you answer at the moment of the write.

The four write gates

Under Settings → POM AI → MCP server, in Write permissions:

All four are off by default, and they are independent. Opening the content gate does nothing for the catalogue.

A write attempted through a closed gate is refused with a message saying the write group is disabled in the settings — regardless of scopes, capabilities or how confident the assistant is.

Open only what the task needs

Treat a gate as open for the duration of a task, not as a permanent setting:

1. Decide what the assistant needs to change.
2. Open only that gate.
3. Do the work.
4. Close it again.

Leaving all four open permanently means any connected client with the right scopes can change anything its user can reach, at any time, without further approval.

The other three checks still apply

The gate is one of four:

1. Scopes — the token must carry the write scope and its read partner.
2. Capabilities — the acting WordPress user must hold the capability.
3. The gate — must be open.
4. The input schema — arguments must satisfy it.

Two consequences worth internalising:

• API keys can write through a configured service user. Keep the relevant gates closed and restrict that user’s capabilities when read-only access is required.
• The acting user is a hard ceiling. An assistant authorized as an editor cannot change options or theme settings no matter what is open.

Dry runs

Some write tools accept a dry_run argument. When supported, it reports what the tool would do without doing it.

Use it whenever it exists, especially for anything touching several records. Asking the assistant explicitly is worthwhile:

Use a dry run first and show me the result before applying anything.

Support is per tool, not universal. Check the tool's own documentation in chapters 11 to 21.

Instruct the assistant to work carefully

The server enforces boundaries; it cannot enforce good judgement. That comes from how you brief the assistant:

Before changing anything, read the current state and show me what you found.

List the tools you intend to call and in what order, then wait for me to confirm.

Only modify post 412. Do not touch anything else.

After the write, fetch the record back and show me the fields you changed.

That last one matters: a successful tool call means the call succeeded, not that the outcome is what you wanted.

More patterns in Prompting an MCP client.

Before opening a gate for the first time

• [ ] A backup exists and you have confirmed it restores.
• [ ] You are on staging, if the work is structural.
• [ ] The acting user is the one you intended.
• [ ] Only the necessary gate is open.
• [ ] You know how to undo the specific change.

Watch what happened

Every tool call is recorded in Recent MCP logs with the action, status, authentication type and acting user, arguments redacted and truncated. Entries are pruned according to Log retention days, default 30.

After a session that wrote, read the log rather than trusting the summary. It is the only independent record of what the assistant actually did.

If something goes wrong

1. Close the gate. That stops further writes immediately.
2. Read the log to establish what ran.
3. Check the affected records in WordPress.
4. Restore from backup if needed — there is no undo.
5. Reset OAuth if you suspect the client itself is the problem.

Rate limits help a little

Write operations are limited to at most 20 per minute per client, below the read limit. That bounds how fast a misbehaving session can act, but a minute is long enough to do real damage. It is a speed bump, not a safety net. See Rate limits.