Prepare and resume a website plan

A site plan is a versioned JSON document containing ordered MCP operations. Use it when creating several dependent parts of a website from a remote client. The journal records prepared changes and completed results so another request can continue from the next step.

Connect through POM AI → Settings → MCP. Plans require manage_options, POM Theme scopes for the journal operations and the scopes, capabilities and write gates required by every step. Saving a plan does not grant permissions that the current connection lacks.

Plan format

{
  "version": 1,
  "title": "Site navigation",
  "steps": [
    {"id": "home", "tool": "pom_site_save_content", "arguments": {
      "post_type": "page", "slug": "home", "title": "Home", "status": "publish"
    }},
    {"id": "front", "tool": "wp_set_site_pages", "arguments": {
      "show_on_front": "page", "page_on_front": {"$ref": "home.id"}
    }}
  ]
}

Use unique step IDs and references only to earlier step results. A reference is an object containing only $ref; it replaces the whole value and preserves its type. String interpolation is not supported. Do not put dry_run, expected_revision or site_id inside step arguments: the journal manages those controls. For templates and content-model rows, provide stable identifiers.

Plans accept only the tools listed in their discovered schema: content, settings, menus, site pages, forms, content-model configuration, templates, global and named CSS, assets, site cache clearing, saved queries, facets, terms and metadata. An operation must also be available on the connected site. They cannot execute arbitrary tools, PHP, SQL or requests.

Run one step at a time

1. Send the document to pom_site_preview_plan. This checks its structure, ordering, references and available operation grants. It does not yet validate targets that depend on earlier changes.
2. Call pom_site_create_plan with the same document. Record the returned id and revision.
3. Call pom_site_prepare_plan_step with plan_id and that expected_revision. This resolves dependencies, runs the next operation's real preview and records a checkpoint. Review steps[next_step].preview.
4. Call pom_site_apply_plan_step with the journal's latest revision. It rechecks the target and applies exactly one step. Inspect that step's returned status; a successful request alone does not mean the operation completed.
5. Repeat preparation and application until complete is true. Each request freshly loads the site's registered content types and feature choices.
6. Read pom_site_get_plan after any lost response or disconnection. Completed steps are retained and are not executed again. Reconnect after a transport-mode change.

Preparation, application and recovery also accept dry_run: true. A dry run does not update the journal or apply website changes. Write previews still require the same permissions and consume a write slot. Respect the MCP write limit and continue after its reset.

Conflicts and uncertain outcomes

A changed journal or target requires a new preparation and review. MCP writes are serialized per site; a busy target asks the client to try later. Edits through other WordPress interfaces are checked through target revisions and prepared fingerprints, without locking those interfaces. A request interrupted during execution leaves running or uncertain; these states are never replayed automatically.

For interrupted content saves, inspect the item and use pom_site_adopt_plan_content with its content_id and the current journal revision. Every editable content field must match the prepared result. For interrupted form creation, pom_site_find_forms helps locate the draft; pom_site_adopt_plan_form accepts only the matching untouched draft created by the same user. Both recovery operations support preview.

Other uncertain operations require inspecting and repairing the affected objects, then creating a revised plan that omits changes already applied. Checkpoints and original values support review and manual restoration; they do not provide automatic rollback or a site-wide transaction. Theme hooks or multi-file operations can partially succeed before an error.

A journal belongs to its WordPress user, client and site. Another connection cannot claim it merely by knowing its ID. Current permissions are checked again when it is used. Keep the same client identity when reconnecting.

Retention and verification

A site can retain 20 journals. Each document supports up to 100 steps and 512 KiB of input; a journal including previews and results is limited to 4 MiB. Prefer small plans for large content. Use pom_site_discard_plan at the current revision to remove a journal when its record is no longer needed. Discarding preserves the website changes.

After completion, inspect the frontend: navigation, page assignments, templates, form validation, cookies, contact dock, listing controls and responsive layout. A completed journal records successful operations; it does not replace this browser review.

Related: Typed settings, filterable listings, forms and navigation.