Build pages with the installed block editor

Use these tools when a connected agent creates or edits a Gutenberg page. You need POM AI MCP access, permission to edit the target content type, and an authenticated browser session in the site's editor to verify static save markup. No local WordPress installation is required.

Discover and prepare a page

1. Ask the agent to read pom_get_authoring_context for the target page. Existing Classic Builder pages keep their format unless you request a conversion.
2. Call pom_get_available_blocks with target_id for an existing page or post_type for a new one; the default type is page. The result includes allowed block summaries and the editor context. WordPress's contextual allowed-block setting can hide registered blocks.
3. Call pom_get_block_schema with block and the same target context. It returns registered attributes, nesting rules, supports, dynamic status and serialization limits. It refuses a block outside the target palette.
4. Compose with the installed editor's block creation and serialization functions. Read its browser registry for attributes added by JavaScript. Do not construct static save markup from server attributes alone.
5. Call pom_validate_block_content with content and the same target context. Resolve errors, preview and apply pom_site_save_content at the returned revision, then read the content back.
6. Open the page through Pages → All Pages, edit a field, save and reload in Gutenberg. Confirm that all nested blocks remain valid, then review the frontend on desktop and mobile.

All three discovery/validation tools are read operations and accept the optional connected site_id. Creating or updating content still requires the content write gate and normal WordPress capabilities. The same tools are available through standard POM AI MCP and the WordPress MCP Adapter's native abilities.

POM's editing palette

When POM Theme or a POM child theme is active, the agent receives POM blocks and permitted native text blocks extended by POM. Paragraph, Heading, List and List Item retain their core/* names. Other Core blocks and third-party blocks are excluded. The pom/extend-* registrations are extensions and cannot be inserted as content.

Shortcode discovery exposes registered POM theme callbacks, including historical shortcode names. Disabled modules and unrelated WordPress/plugin shortcodes cannot be saved through MCP content tools. This restriction also applies to shortcodes embedded in block content. Existing title-only updates do not require converting the stored page.

For a listing or other supported POM shortcode module, insert POM Shortcode if that block is in the target palette. Use its text attribute for the source generated by pom_site_build_listing, then serialize with the installed editor. Its source stays editable while the existing shortcode renderer produces the visitor-facing result.

Understand validation results

The validator checks block comments, JSON attributes, native attribute types, allowed blocks, nesting and embedded shortcode availability without rendering or saving. It returns valid, issues, summary, validation_scope, editor_save_verified and serialized_content when valid. Content is bounded to 200000 bytes, 1000 named blocks and 32 nesting levels.

validation_scope: server_registry_and_structure and editor_save_verified: false mean that a browser save check remains necessary. WordPress PHP serialization preserves supplied HTML; it does not generate static block HTML. Attributes added only in the browser can produce warnings and must be verified against that installed registry.

If a block is refused, rediscover with the actual page ID and check its editing permissions. If Gutenberg reports invalid content, fix the source with the installed save function before applying it again. An MCP-only connection can inspect schemas and source but cannot certify browser save fidelity on its own.

See Authoring context, Builder content validation and Template validation.