pom_theme_configure_content_model: configure structured content

Creates post types, taxonomies, custom fields and templates — and wires them together — in one call. The largest single write POM AI exposes.

Arguments

None is individually required, but at least one must be present or the call returns pom_ai_mcp_empty_content_model_update.

If both custom_fields and metas are sent, custom_fields is used and metas is ignored.

Permissions

Allow POM Theme writes open, plus manage_options.

Why it exists

Building a content model piecemeal means creating templates, then a post type, then assigning each template to it, then taxonomies, then fields — five or six calls that must be sequenced correctly, with a half-configured post type visible in the admin in between.

This tool does it in the right order in one request. Templates are created first so post types can reference them by key, and the assignments are made as the post types are created.

It is not atomic

The complete model is validated before writes begin, including template asset selections and custom-field keys. Validation failures stop the write. Storage failures or concurrent changes during execution can still leave earlier stages written: there is no transaction or automatic rollback.

So a failed call does not mean nothing happened. Read what the site actually looks like before retrying:

The call failed. List the templates and the post types and tell me what already exists.

Retrying naively creates duplicate templates.

Always dry-run first

The dry run propagates through every stage and returns the complete plan under changes, grouped by what it would create: templates, post types, archive and feed assignments, taxonomies, custom fields.

Given the size of this write and its lack of rollback, the dry run is not a nicety:

Dry-run the content model and show me every change it would make, grouped by type.

Read the whole plan. A content model is a structural decision about the site, and it is far cheaper to correct on paper.

Templates are validated as strictly as elsewhere

Template rows go through the same validation as pom_theme_upsert_html_template: PHP tags refused, unknown merge tags refused, unbalanced {{if}} blocks refused, empty markup refused.

HTML is filtered with the installation's KSES rules even for administrators. Template js_scripts accepts only existing identifiers from pom_theme_get_script_catalog with target: template; css_stylesheets accepts existing stylesheet identifiers and native tokens. Omitting either field preserves its current selection, while an empty array clears it. Agents cannot create script source or alter content-model permission rules. Custom fields cannot use protected internal, credential or script metadata keys.

Rewrite rules are flushed for you

When post types, taxonomies or CPT archive assignments change, permalink rules are rebuilt automatically on the next WordPress request, after the new definitions have registered. The write response reports rewrite_rules_pending: true and rewrite_rules_flushed: false. Make another request before checking the new URLs.

That matters because a new post type without flushed rules produces 404s on its archive. Doing it automatically removes the classic failure — but it also means the call is heavier than its size suggests, and it does nothing on a site with permalinks disabled.

Post types are permanent in practice

There is no MCP tool that deletes a post type or a taxonomy. What this creates, this cannot remove.

More importantly, content created under a post type becomes inaccessible if the post type is later removed by hand. Slugs are especially hard to change afterwards — they appear in URLs and in stored assignments.

Decide the slugs deliberately, and prefer creating one post type and reviewing it to creating five in a batch.

Custom fields are definitions, not values

Declaring a custom field makes it available on the post types you name. It does not populate anything.

Templates reference those fields through merge tags and {{if meta="…"}} conditionals — so the field name in the definition and the name in the template must match exactly, and this tool does not check that they do.

After running

1. Read the response and account for every change.
2. Check the post type appears in the WordPress admin.
3. Create one test post, publish it, and load both its single page and the archive.
4. Confirm the archive is not a 404 — that is the rewrite rules.
5. Read the assignments and confirm the templates are attached.
6. Purge the cache.

Step 3 is the real test. A content model that validates can still render nothing useful.

Common problems

Related

• Create a POM content model
• Configure the content model
• Content model guide
• pom_theme_assign_template — the one-at-a-time alternative