Edit design and optional features with a typed settings contract

Use these tools when an AI client needs to change POM colours, typography, header, footer, cookies or contact dock. POM Theme must be active. Connect through POM AI → Settings → MCP, choose your authentication method and enable Allow POM Theme writes. The connected WordPress user needs manage_options; OAuth grants need mcp:write and pom_theme:write. Reading contracts requires edit_theme_options and the corresponding read scopes.

Read, preview and apply

1. Call pom_theme_get_settings_catalog. It lists the groups registered on this site, their activation state and the operation used to edit them.
2. Call pom_theme_get_setting_contract with a setting from that catalog. The response includes fields, values, enabled and revision. Each field describes its input schema, choices, dependencies and whether it is readable or writable.
3. Call pom_theme_patch_settings with the group, a partial values object and dry_run: true. For an optional group, you can also supply enabled: true or false.
4. Review the returned before, after and activation change. Apply the same arguments with dry_run: false and expected_revision copied from the preview.
5. Read the contract again. Refresh discovery after activating a feature or changing a layout: available fields, reusable blocks, locations and choices can change on the next request.
6. Run pom_theme_generate_assets when the site's configuration is assembled, then inspect the actual frontend at desktop and mobile widths.

{
  "setting": "header_settings",
  "values": {"pom_header_sticky": "yes", "pom_header_padding": 18},
  "dry_run": true
}

Use the returned revision rather than copying a revision from another site. A stale revision is refused before the patch is saved. Unspecified top-level fields and unrelated groups are preserved.

Repeaters and fonts

A repeater is a plain array of rows. Every row needs a stable repeater_identifier. Supply child fields directly, using their discovered schemas; do not send filesystem paths or storage wrappers. The supplied array replaces the row collection, so include every row you want to keep. Matching row identifiers preserve omitted child values and server-owned metadata. Omitted rows are removed. Defaults and newly added rows retain their native groups, which can affect ordering between those groups.

Nested repeaters are supported up to the advertised limits. Font families use the framework's native family and variant definitions. Multiple selections use arrays; toggles use "yes" or "no". Numeric fields use numbers.

HTML and rich text are accepted as content, sanitized and saved as managed assets when applied. Preview does not create those content files. Keep old source assets until you have finished reviewing and recovering changes.

Dedicated operations and limits

Custom post types, taxonomies, fields and templates use the content model tools. Queries and filters use the listing tools. CSS retains its dedicated operations.

Password, credential, JavaScript and non-editable fields are excluded. Fields backed by native options or theme modifications may be read-only here. Always follow the returned field policy; a group appearing in the catalog does not grant unrestricted access to its contents. The older pom_theme_update_setting allowlist remains separate.

Each request is limited to 512 KiB of JSON and 100 top-level values. A patch can involve multiple managed files and theme save hooks; it is not a database transaction. If a write fails after execution starts, inspect the current values before retrying. Site plans retain previews and execution receipts across requests.

If a field or group is missing, refresh the catalog after activating its parent feature. If a write is denied, check the field policy, WordPress capabilities, OAuth scopes and MCP write gate. If the frontend is unchanged, regenerate assets and clear the site's caches.