Review and approve MCP changes
Approve a single change or a complete, explicit job before the assistant applies it. A write job groups known operations on one site under one review. The assistant can then execute its parts separately without asking you to approve every batch. Reading and dry_run: true previews do not require approval.
For iterative network editing, you can instead authorize a temporary work session for selected operations on one destination. Both session authorizations and new network web reviews use the main-site login.
Review inside your client
On direct site and multisite network connections, clients that support standard MCP form elicitation can show the review in the conversation. This uses the standard elicitation/create protocol supported by compatible Codex, Claude Code and other MCP clients; it does not require a client-specific plugin.
- Ask the assistant to read the targets and prepare the exact changes.
- Review the site, job title, expiry and complete operation inputs in the client's confirmation dialog.
- Select Approve these exact changes and submit, or decline or cancel.
- The assistant receives the decision and executes the approved operations with their
approval_id. - Inspect the results and ask the assistant to read the changed objects back.
The dialog is available when the client advertises form elicitation and accepts streamed HTTP responses. Its labels and presentation may vary by client. The server first returns a background task receipt. Poll pom_get_task to receive the prepared review. The authenticated reply records the decision; delegated decisions are also processed through cron. Read the job status after confirming and before executing. A cancelled, unanswered or unsupported form, or a submitted form with its confirmation unchecked, leaves the review pending and provides the web alternative. Only a checked confirmation approves the job. An explicit rejection refuses execution and requires a new review if you later want to proceed. Approval does not apply changes immediately.
Hosting must support the short streamed response for the dialog. The dialog does not keep a PHP request open while you decide. If the host or client interrupts the conversation, use the web review link included in the dialog and inspect the job before continuing.
Approve a complete job
For several independent batches, ask the assistant to use pom_site_prepare_write_job with the destination site_id, a descriptive title and an operations list. Each entry contains a supported tool name and its exact arguments, including any required revisions. Omit approval_id and dry_run inside entries. The outer dry_run: true previews the job without creating a review.
The job supports up to 100 operations, a 1 MiB input payload and a complete review of at most 2 MiB. Existing per-tool execution limits still apply: for example, 180 category renames can use four wp_rename_terms operations of at most 50 terms each, with one approval for all four. Larger work can be divided into several explicit jobs.
Preparing the complete review shares one 60-second work budget across its previews, on both direct site and network connections. If preparation reaches that budget, no approval is created; prepare a smaller job. Each later operation keeps its ordinary 15-second work budget. These limits are checked between steps and batch entries; they do not interrupt a native callback that has already started.
After approval, the assistant calls each original tool with its returned arguments and the shared approval_id. Each listed operation can execute once. Use pom_site_get_write_job with that ID to inspect the approval and the status of each operation: pending, executing, applied or uncertain.
Jobs expire one hour after preparation. Individual reviews expire after 15 minutes. Expiry and credential changes can require another review. A job does not authorize additional targets, changed arguments or future changes that were not included. Changes that depend on unknown IDs or later plan revisions need their own preview once those inputs exist. A saved authoring plan alone does not authorize its future steps.
Use the web alternative
A review link remains available for clients without form elicitation, account-routed connections, and exact requests too large to display completely in a form. Forms are limited to 128 KiB of review text; the web review retains the complete preview and inputs.
To choose WordPress as the only place to decide a new job, ask the assistant to prepare it with review_mode: "web". This works for direct site and delegated network jobs. No client confirmation form is offered for that job, and MCP client replies cannot approve or reject it. You must still sign in and make your decision at approval_url. The default review_mode: "auto" keeps the client form and web alternative described above.
Use web mode when you prefer reviewing in WordPress or the client does not present confirmations reliably. The mode is fixed when the job is created; it cannot reopen a rejected job or change an existing decision. Prepare a new review for the confirmed remaining work instead.
- Open the returned
approval_urlyourself. Sign in to that WordPress site as the user who authorized the connection, or the configured service user for an API-key connection. If signed-out visitors are redirected, sign in through your usual login page and reopen the link. - Check the site, operations and previews. Expand Exact request to inspect the inputs.
- Select Approve these changes or Reject and tell the assistant your decision.
- The assistant checks or resumes with the same
approval_id; no additional per-batch web review is needed for a prepared job.
After submitting, the browser opens the review again with its saved status. Refreshing or submitting an old form does not change an existing decision. The review and job status identify whether a new decision was recorded through WordPress or the MCP client. A rejected review cannot be approved again; ask the assistant to prepare a fresh review. A missing or invalid form decision leaves the existing status unchanged.
The assistant must never approve through browser automation or fabricate a client confirmation. The MCP client is responsible for presenting the decision to its user. Avoid client settings or hooks that automatically answer approval forms when you want to review every job personally.
New delegated multisite reviews open on the main site. Sign in there as the super administrator who authorized the network connection; no browser login on the destination is needed. The review identifies the destination, and changes still execute with that destination's theme and plugins. Existing reviews created before this behavior was available retain their original site link. Route pom_site_prepare_write_job through pom_network_execute_site; route status reads through pom_network_read_site. Put the shared approval_id inside each delegated operation's arguments, alongside its destination site_id. The main-site client can present the destination's review in its form dialog.
Authorize a network work session
For iterative work where later inputs are not yet known, a network super administrator can authorize a temporary work session. It covers one destination and one OAuth connection. Exact reviews remain the default; requesting a session does not authorize it or apply changes.
- Discover the destination through the main-site network connection. Enable the needed write groups under Network Admin → Settings → POM AI Network MCP.
- Route
pom_site_request_work_sessionthroughpom_network_execute_site, with the destinationsite_id, a descriptivetitle,groupsand optionalduration_hoursof1,4or8(default8). Adry_run: truerequest previews the scope without creating a review. - Open
approval_urlon the main site. Review the destination, duration, groups and complete Allowed operations list. Select Authorize this work session or Reject yourself. The session cannot be approved through an MCP client form. - Read
pom_site_get_work_sessionthroughpom_network_read_site, passing the returnedwork_session_idand destinationsite_id. Wait forsession_status: approved. - For each permitted write, put
work_session_idand a new UUIDoperation_idinside the delegated tool'sarguments. Do not also sendapproval_id. Inputs may evolve within the approved scope; read current revisions and inspect each preview and result. - Open the same review URL and select Revoke this work session when finished. Revocation stops later operations; an operation already started may finish.
Available group identifiers are site_content_writes, theme_writes, option_writes, woocommerce_writes and cache_writes. Only enabled groups and tools allowed by the connection's scopes can be requested. The older page-only write setting does not enable work sessions. The returned allowed_tools is authoritative: deletion tools, comment moderation, content-model configuration and composite authoring plans retain exact approval. Newly available tools require a new session.
A pending request must be approved within 15 minutes. The selected session duration starts when you approve it. Each session supports at most 500 operation IDs. Each ID can start once; its receipt records the tool, status and timing. Never replace an ID to replay a write with an unknown result. Inspect the task, session receipts and destination first. An incomplete or uncertain operation pauses the session; prepare a new session or exact review only for confirmed remaining work.
Normal OAuth refresh preserves the session. Reconnecting with a new authorization, changing the network policy or site identity, revoking access, losing permissions, or reaching expiry prevents further use. A session never adds OAuth scopes or WordPress capabilities, and every execution still checks the current network write groups and revisions. It authorizes supported future changes within its scope, not an automatic rollback or permission to exceed your task.
Permissions and recovery
Under Settings → POM AI → MCP server → Write permissions, enable only the groups needed for the task:
| Gate | Area |
|---|---|
| Allow content writes | Content, media, taxonomy terms, comments, metadata and menus |
| Allow option writes | Supported WordPress site settings |
| Allow POM Theme writes | Theme settings, content models, templates and search configuration |
| Allow WooCommerce catalog writes | Products, variations, attributes and coupons |
Every operation still needs its OAuth scopes, WordPress capabilities, current revision and open write groups at execution time. Approval cannot add permissions. Network owners configure delegated groups under Network Admin → Settings → POM AI Network MCP.
Changed targets or previews are refused. A failed or partially applied operation pauses its job, and an operation still marked executing must be inspected before continuing. Read the destination and prepare a new review for confirmed remaining work. Never replay the entire job after a timeout. Completed changes remain applied; a job is not a database transaction or an automatic undo.
Related: Organize taxonomies, Manage multisite websites, MCP capability map.