Manage multisite websites from the main-site connection

Network super administrators can use one main-site MCP connection to manage supported content, media, taxonomy terms, menus, POM Theme settings, content models, templates, forms and faceted search on sites in the same WordPress network. WooCommerce catalog and POM Cache operations are available when their integrations are installed. The main site needs a current POM AI Unlimited license, monthly or annual.

Activate POM AI on each destination individually or across the network. A delegated destination needs no local license, API key, OAuth connection or enabled MCP setting. WordPress 6.9+ is required; POM AI includes the official MCP Adapter.

Set up the connection

1. Activate POM AI on the main site and each destination.
2. Connect the main site's Unlimited license under Settings → POM AI → License.
3. Enable POM AI MCP under Settings → POM AI → AI Tools, then Enable OAuth under Settings → POM AI → MCP server.
4. Use pretty permalinks and HTTPS on the main site. Ensure WordPress scheduled events run for every destination with that site's theme and plugins loaded. Destinations may use plain permalinks.
5. As a super administrator, open Network Admin → Settings → POM AI Network MCP. Select Enable network delegation and the necessary write groups, then save.
6. Authorize the client against the main site's MCP URL. Network reads require mcp:read and network:sites:read; network writes also require mcp:write and network:sites:write. Each destination tool additionally requires its own scopes shown by discovery, such as wp:content:write or pom_theme:write.

Existing grants do not acquire new scopes automatically. Reauthorize for missing scopes. Consent covers eligible current and future sites in this network; the actor must remain a super administrator.

Choose write groups

An existing page-write permission remains page-only. Broader groups start disabled. Some operations need more than one group, such as assigning existing theme scripts to content. Every site write also needs your approval.

Work on a destination

Submission and pom_get_task return immediately. The operation itself runs in the destination's WordPress cron; it does not require an HTTP request between sites. Wait the returned poll_after_seconds and poll the same task on the main-site connection while terminal is false. Its phase distinguishes waiting for dispatch, waiting for the destination's cron and executing. Use a completed task's result for each step below; stop and inspect errors for failed, expired or uncertain.

A delegated destination loads its tool catalog when its worker claims an operation. Network delegation does not enable that destination's independent MCP endpoint or require local OAuth setup. An independently enabled site MCP remains available through its own configuration.

Each destination can have its next operation scheduled independently, so a site waiting for cron does not prevent another site from starting. POM AI still executes only one heavy operation at a time across the installation. Keep the destination's scheduled-event runner enabled and respect the polling delay.

Collect and save each result promptly. Results are available for up to one hour after completion; the oldest finished task receipts can be removed sooner when new work needs capacity. If a receipt is missing, inspect the destination before repeating a write. Network execution audit entries appear in the main site's MCP log and identify the destination blog ID.

1. Call pom_network_get_context, then pom_network_list_sites. Follow next_offset when present.
2. Select the requested blog_id and call pom_network_discover_site. Read its site, tools, schemas, required scopes and write groups.
3. Call pom_network_read_site with the selected blog_id, discovered tool name and its arguments. Include the destination's site_id UUID inside arguments.
4. Preview a discovered write with pom_network_execute_site and arguments.dry_run: true.
5. Submit the exact intended write, including expected_revision where required. For several known operations, route pom_site_prepare_write_job to this destination for one combined approval. Review in the client confirmation dialog or through the returned main-site link, which clearly identifies the destination. You do not need to sign in to the destination.
6. Execute each original operation with the returned approval_id inside arguments. Read job status with pom_site_get_write_job through pom_network_read_site.
7. Inspect the result, then read back the target and verify its editor or frontend. After creating a CPT, taxonomy or query, or activating a theme feature, make a fresh request and rediscover dependent contracts.

blog_id selects the site; site_id verifies its identity. Post, term and media IDs belong to that destination. Use the returned schemas rather than copying another site's catalog. A tool being listed does not mean its scope or write group is enabled.

For iterative work, route pom_site_request_work_session to the destination and explicitly authorize its selected groups on the main site. Sessions last one, four or eight hours from approval and permit up to 500 separately identified operations. Use work_session_id and a new operation_id for each permitted write, then inspect pom_site_get_work_session. Deletion tools and composite plans still need an exact review. Revoke the session from its main-site review link. See Authorize a network work session.

Common tasks

The network routes the reviewed site-tool catalog. It does not execute arbitrary WordPress abilities or route another network/account gateway recursively. User administration, credentials, executable-code creation and permission-rule editing remain outside the authoring catalog. Resources and prompts are available on direct connections; use the routed discovery and authoring tools for network work.

Verify and recover

Routed responses contain blog_id, isError and result. Inspect the inner error and any complete, approval_required or plan status fields. A wrapper-level dry_run: true forces a destination preview.

If a response cannot be confirmed, inspect the destination before retrying: the operation may have completed. If revisions or approvals are stale, read and preview again. No operation automatically rolls back a whole website.

Clear an area's write option to refuse its writes and previews. Clear Enable network delegation to stop routing. Revoke the main-site OAuth grant to stop that client. None of these actions undoes completed changes.

Independent subsite connections still require that subsite's own valid, domain-authorized license and its own authentication, scopes and permissions. They never inherit the network grant. Delegated authoring does not enable account-backed AI services for subsite users.

For unavailable destinations, check activation, site status, selected network, the destination URL and its scheduled-event runner. For entitlement refusals, check the main-site license and domain authorization. Temporary verification failures refuse delegation without interrupting the website.