A published post is already in Google, in the newsletter archive, and in someone's open tab. The edit you actually want is often small: the title is vague, the excerpt is the first sentence of the intro, and the body is fine. The risky way to hand that to an AI client is "update this post." The safe way is to make the client propose the edit, show you the diff, and write nothing until you apply it.
This walkthrough does that one job with WPPilot Free, a self-hosted WordPress plugin that turns your site into an MCP server. Your client (Claude, Cursor, VS Code, or another MCP client) brings its own model. There is no hosted relay in the middle.
Disclosure: I work on WPPilot. The behaviour below is taken from the public safety profiles guide, the change ledger guide, and the platform ability reference.
What you are changing, and what you are not
The job:
- One already published post.
- New title.
- New excerpt.
- Body, slug, status, author, and featured image stay as they are.
update-post is a Free WordPress core ability with partial-update semantics. It accepts short field names (title, excerpt, and others) and only the fields you send are meant to change. That is why the prompt below names the two fields and forbids the rest. Do not let the agent "clean up the intro while it is there."
This is an edit of a live post, not a new draft. Content creation in WPPilot defaults to draft, including when a status is missing or malformed, but that default does not help you here. You are not creating anything. Preview is the control that keeps the published page unchanged until you say so.
The three calls
| Call | Kind | What it does on this job |
|---|---|---|
preview-ability |
Read | Computes what update-post would change. Returns a structured diff and a URL you open in wp-admin. Nothing is written.
|
apply-preview |
Destructive, needs confirmation | Applies that exact diff, after checking the target has not changed since the preview. Refuses if it has. |
list-changes / get-change
|
Read | The redacted change ledger, newest first. There is no ledger screen in wp-admin. |
Preview covers post, page, and media edits, site settings changes, and deletions. You can make preview mandatory for the site. That setting is off by default, because turning it on changes the contract every connected agent is working to. Abilities WPPilot cannot preview are exempt rather than blocked: a write nobody can preview is not refused just because preview exists.
Setup
You need WordPress 6.9+, PHP 8.0+, and HTTPS if the client connects from another machine.
- Install
wppilot.zipfrom the latest GitHub release. It is not on WordPress.org. Upload it under Plugins → Add New → Upload Plugin. - Leave the safety profile on Production Safe, the install default. It allows ordinary content edits and blocks raw PHP, WP-CLI, filesystem and database access, and plugin or theme install and delete. A title change does not need any of those.
- Connect the client with an account that can already edit this post in wp-admin. MCP calls inherit that user's capabilities. A dedicated editor account is better than your own administrator login, because the ledger attributes the write to that credential.
With Claude Code over OAuth:
claude mcp add --transport http wppilot https://your-site.com/wp-json/mcp/wppilot-oauth
# then /mcp and finish the browser sign-in
Other clients use the same site endpoint. Generated configs for the clients WPPilot documents live under wordpress-mcp.
Step 1: Read the post, change nothing
Change nothing on the site.
Find the published post whose slug is "care-plans-explained".
Show me its id, title, slug, status, and excerpt, and the first 200 characters of the content so I know we have the right post.
Do not call update-post. Do not call preview-ability yet.
Check the id against the URL in wp-admin before you continue. Preview is only as good as the target you point it at.
Step 2: Preview the title and excerpt only
Do not write anything yet.
Call preview-ability for update-post on post id POST_ID with only these fields:
- title: "WordPress care plans, explained without the jargon"
- excerpt: "What a care plan covers, what it does not, and how to tell a retainer from a one-off fix."
Do not send content, slug, status, author, or featured image.
Paste the field-by-field diff here, and give me the wp-admin review URL.
Stop after the preview.
preview-ability is a read. The public reference says it returns a structured diff plus a URL a person can open in wp-admin to review, apply, or discard the proposal. Nothing is written by that call.
Open the URL yourself. Read the diff, not just the agent's summary. Check the fields it did not mention. The safety guide is explicit: apply from that screen, or with apply-preview, rather than asking the agent to send update-post again and hoping it matches what you approved.
Step 3: Apply only if the diff is the edit you wanted
If the diff shows exactly two fields, title and excerpt, and the body is absent from it, apply it.
apply-preview is marked destructive, so it needs an explicit confirmation. It re-checks that the target has not moved since the preview. If someone edited the same fields while the proposal was waiting, it refuses and writes nothing, because 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. That is why you still want the diff to be narrow: an unrelated edit to the body is not what this refusal is for.
If it refuses on drift, do not force the write. Re-run the preview and read the new diff.
If the diff includes content, a new slug, or status: publish when you did not ask for those, discard it. Partial updates only help if the agent actually sends a partial payload.
Step 4: Read the ledger entry for this session
There is no change-ledger screen in wp-admin. Ask the agent:
Call list-changes with limit 5.
For the newest entry that is this update-post, call get-change.
Tell me: which credential acted, which ability ran, whether rollback is available, and whether any secret-looking value was stored.
Do not roll anything back.
list-changes takes a limit and returns the newest records first. Each record includes the ability, the actor, risk, timing, rollback availability, and rollback state. The ledger keeps at most 500 records and is also capped by size. Values under keys that name a secret (passwords, tokens, API keys, cookies) are redacted before storage. Other inputs are kept, truncated, so the ledger can still hold site content such as the new title. Treat it as holding site content, not as an empty audit log.
Attribution is the check people skip. The record names both the WordPress user and the agent credential: an OAuth client id, stored hashed, or an application-password UUID, plus the client name and version the agent introduced itself with. If you expected a dedicated editor and the entry is your own administrator account, the credential was created on the wrong user. Fix that before the next session. Writes that arrive from wp-admin, WP-CLI, or another plugin, outside an authenticated MCP request, are recorded as direct rather than blamed on the last agent.
If the new title is wrong
Where rollback applies, rollback-change restores the previous WordPress state for that record and marks the original entry as rolled back, with the time it happened. It does not add a separate ledger entry for the rollback. It succeeds only when the observed result matches the stored before-image fingerprint, and it never marks success when verification differs. It needs explicit confirmation.
Rollback is not universal and it is not a backup. It does not restore a database, undo a change made outside WPPilot, or pull back an email, a webhook, or a cached copy that already left WordPress. A title change on a post is the sort of record the features documentation shows as rollback-available, but the ledger entry itself is what reports rollback availability for the write you just made. Read that field. Do not assume every ability works the same way. SEO metadata edits and some commerce edits are recorded with no rollback. Those are different jobs, and they are not this one.
After a rollback, open the post logged out. Do not trust the tool response alone.
What this workflow does not do
- It does not make preview mandatory. You turned nothing on. The agent could still call
update-postdirectly unless you require preview in settings, or you refuse to continue when it skips the preview. - It does not review writes WPPilot cannot preview. Those stay exempt, not blocked.
- It does not replace a backup before a large batch. One title and one excerpt do not need a heroic restore plan. Fifty posts do.
- The human approval queue, which holds every write until a person signs it off, is WPPilot Pro. This article does not use it. Preview on Free is the control for a person who is in the session.
The pattern is the same the next time the edit is a page title or a media field that preview supports: read the object, preview one ability with only the fields you mean, apply that diff, then read the ledger entry that names the credential. The live page should change once, in the shape you already saw.
Top comments (0)