MCP read, dry run, write, and destructive behavior

POM AI classifies each tool internally so rate limiting and authorization can distinguish reads from mutations.

Read

Read tools retrieve or validate current state and do not intentionally change WordPress. They still require scopes and capabilities because unpublished content, media, settings, comments, and catalog data are not public simply because the method is read-only.

Dry run

Most write tools accept dry_run: true. The call validates authorization and arguments and returns the proposed action without applying it. Dry run is the preferred confirmation boundary, but it does not create a rollback snapshot or reserve an identifier. It requires the same scopes, capabilities and write gates as execution and counts toward the write quota. Send a JSON boolean. A WooCommerce variation batch with dry_run: true keeps every row in preview mode, even if a row supplies dry_run: false.

Write

Write tools create or update state. Read the target first, keep the payload bounded, confirm, call once, and read back. Some values replace a complete set—product categories, attributes, or post terms unless append is true—so the proposed removal must be visible before confirmation.

Destructive and non-atomic operations

Deletion behavior varies: some WordPress objects can use trash, attachments may be permanently deleted, menu item deletion is permanent in this integration, variation and coupon deletion are exposed, and product deletion is absent.

Batch and coordinated content-model tools are not transactions. They can return partial per-item results or stop after earlier changes. Recovery begins with a fresh read, not a blind retry.

Related guides: write confirmation, failed-write recovery, and authorization.