Inspect content before changing it
The single most useful habit in MCP work. An assistant that has read the current record makes a far better change than one that inferred it from your description.
Why it matters more here than elsewhere
Writes are immediate and there is no undo. The moment to catch a misunderstanding is before the write, and reading is the only way to catch it.
Reading is also cheap: it costs no credits, counts against the higher read limit rather than the write cap, and cannot damage anything.
Ask for it explicitly
Assistants do not reliably read first unless told. Make it part of the instruction:
Before changing anything, read the current state and show me what you found.
Read post 412 and show me its title, status, categories and excerpt before you edit it.
List the tools you intend to call and in what order, then wait for me to confirm.
The third is worth using for anything unfamiliar. An assistant that announces "I will call wp_get_post, then wp_update_post" has committed to a plan you can check.
What to read, by task
| Task | Read first |
|---|---|
| Editing a post or page | wp_get_post or wp_get_page |
| Changing terms on a post | wp_get_post, then wp_get_categories or wp_get_tags |
| Editing builder content | pom_get_authoring_context, then the page itself |
| Changing a theme setting | pom_theme_list_settings_schema, then pom_theme_get_settings_values |
| Editing a template | pom_theme_list_html_templates, then pom_theme_get_html_template |
| Updating a product | wc_get_product |
| Updating a variation | wc_get_product_variations, then wc_get_variation |
| Editing a coupon | wc_get_coupon |
| Changing an option | wp_get_option |
| Reordering a menu | wp_get_menus, then wp_get_menu_items |
The schema tools matter as much as the value tools. Reading pom_theme_list_settings_schema tells the assistant which setting keys exist and what shape they take, which prevents an invented key name being written.
Confirm the identity of the target
Most damage comes from editing the right kind of thing and the wrong instance. Before a write, confirm:
- The ID matches the item you mean. Titles are ambiguous; IDs are not.
- The status is what you expect. Editing something already published has immediate public effect.
- You are on the right site. On multisite, each site is a separate MCP server.
Asking the assistant to echo the title back before editing catches nearly all of these:
Read page 88, tell me its title, then wait.
Read the counts before a batch
For anything plural, get the size first. wp_count_posts, wp_count_terms, wp_count_media and wc_get_store_stats answer "how many will this touch?" without listing everything.
A batch that turns out to cover four hundred records rather than the forty you assumed is much better discovered at this point.
Note what you will need to restore
Before changing a field, have the assistant show you the current value — and keep it. That is your undo:
Show me the current price and stock for product 219, then update the price to 24.90.
Now the log and the conversation both hold the old value. See Recover from a failed write.
Then read back afterwards
Inspection is not only a before step. After the write:
Fetch the record back and show me the fields you changed.
A successful tool call means the call succeeded. Reading back is what tells you the outcome is right — and it occasionally reveals that a filter or another plugin altered the value on save.
When the assistant resists
If an assistant declines to read first because it is "confident", treat that as a reason to slow down rather than proceed. Confidence is not knowledge of your data, and the cost of one extra read is a second.
Related
- Validate builder or template markup before writing — the equivalent habit for structured content.
- Prompt patterns for multi-step MCP work — phrasing that makes this automatic.