Prompt patterns for multi-step MCP work
The server enforces boundaries. It cannot enforce sequence, restraint or verification — those come from how you phrase the request.
These are the patterns worth reusing. General prompting principles are in Prompting an MCP client; this page is about multi-step jobs specifically.
The plan-first pattern
List the tools you intend to call and in what order, then wait for me to confirm before calling any of them.
The most useful single sentence in this chapter. It converts an opaque sequence into a plan you can check, and it costs one turn.
Use it for anything you have not done before with this assistant, anything plural, and anything touching prices, templates or theme settings.
The read-check-write pattern
Read the current record and show it to me. Then make the change. Then read it back and show me the fields that differ.
Three explicit steps. The final read is the one people omit, and it is the one that distinguishes "the call succeeded" from "the outcome is right".
The bounded-scope pattern
State what is out of bounds, not only what is in:
Only modify post 412. Do not touch any other post, term, template or setting.
Work on drafts only. Do not change anything published.
Do not delete anything. If something appears to need deleting, tell me instead.
Do not change prices, stock or coupons.
Assistants generalise from a task to what seems adjacent to it. An explicit boundary is the cheapest correction available.
The pilot pattern
For a job over many records:
Do the first three, then stop and show me the results before continuing.
Three completed records tell you whether the approach is right. Three hundred tell you the same thing far more expensively.
Combine it with a count first: ask wp_count_posts or the equivalent so you know the real size before agreeing to a batch.
The dry-run pattern
Use a dry run where the tool supports it, show me the result, and wait.
Where a write tool accepts dry_run, this gives you a before-and-after without changing anything. Support is per tool; the assistant will tell you if it is unavailable.
The validation pattern
For builder content and templates:
Read the authoring context and the shortcode schemas first. Compose the content, validate it, show me any errors, and only write once validation passes.
See Validate builder or template markup before writing.
The recovery pattern
Ask for what you will need if the job goes wrong, before it does:
Before each change, show me the current value of the field you are about to change.
Now the conversation holds the old values. This is your undo, and it costs nothing to arrange in advance. See Recover from a failed write.
The stop-on-error pattern
If any step fails, stop immediately and tell me. Do not retry and do not continue with the remaining items.
Without this, an assistant hitting an error partway through a batch may retry, skip, or carry on — leaving you unsure what state the site is in.
Combining them
A realistic instruction for a real job uses three or four:
I want to retag the twelve posts in the "News" category. First count them and list their IDs. Then do the first three only and stop so I can check. Do not change titles, content or status — only tags. If anything fails, stop and tell me.
Plan, pilot, bounded scope, stop-on-error. Four sentences, and it removes most of the ways the job could go wrong.
Patterns that do not work
"Be careful." Means nothing actionable.
"Don't break anything." Every instruction implies this and none of them enforce it.
"Use your judgement about which posts to update." Judgement about your content is the one thing the assistant cannot have.
"Fix the site." Unbounded scope with write access is the worst combination available.
The controls that are not prompts
Prompting shapes behaviour; it does not constrain it. The things that actually constrain are the write gates, the acting user's capabilities and the token's scopes.
If a prompt boundary matters enough to write down, consider whether it should be a closed gate instead. See MCP security model.
Start from a published prompt
For several common jobs the server already publishes a prompt encoding the right sequence. Those are more reliable than a pattern you assemble yourself. See Prompt recipes.