Recipe: create a clear confirmation checkpoint

Use this short prompt immediately before a consequential MCP write when the client has already gathered the required facts.

Do not write yet. Summarize the exact connected site, tool name, target IDs,
current state, proposed payload, fields that will change, fields that will
remain untouched, dry-run result, permissions and write gate used, expected
public effect, and recovery path. Highlight permanent deletes, replacements,
non-atomic batches, price/stock/coupon changes, and site-wide settings. Ask for
one explicit confirmation that names this operation. After confirmation, call
the tool once and read the changed state back before considering a retry.

What confirmation should not hide

A confirmation such as “Proceed?” is too vague when several products, posts, terms, or menu items are in scope. Show identifiers and normalized values. For replacement-style calls, list what will be removed as well as what will be added. For batch operations, state whether partial success is possible.

A dry_run is still a write-shaped tool call and can fail on scopes, capability, gate, schema, or allowlist. Passing it proves that the proposed operation is accepted; it does not authorize the real call.

If the client loses the response after submission, read current state before retrying. This avoids duplicate posts, coupons, menu items, media, or comments.

Related guides: inspect before changing, read versus write, and failed-write recovery.