pom_theme_list_html_templates: list HTML templates
Returns every custom template on the site, of all three types, with their markup.
Arguments
None.
Permissions
mcp:read and pom_theme:read, plus edit_theme_options.
What it returns
Three lists — archive, single and feed — plus merge_tag_sources.
Each template carries:
| Field | Meaning |
|---|---|
repeater_identifier |
The ID every other tool needs |
template_name |
The human label |
template_html |
The markup, resolved from its file |
css_stylesheets |
CSS snippets attached to this template |
js_scripts |
Scripts attached to this template |
Markup is resolved for you, so one call gives you every template's full HTML.
It is the only source of template identifiers
pom_theme_get_html_template, pom_theme_upsert_html_template, pom_theme_delete_html_template and pom_theme_assign_template all work by identifier, and none of them will find one by name.
List the templates and show me each type, name and identifier.
Refresh the list before any write. Identifiers from earlier in a long conversation are the usual cause of the wrong template being replaced.
Names are not unique and not meaningful to the system
Two templates can share a name. The identifier is what distinguishes them, and it is an opaque string.
If a request names a template and two match, say so rather than choosing.
It does not say what is in use
This is the gap worth knowing. The listing shows what exists; it says nothing about what renders.
A site can have nine archive templates with one assigned. Deleting an unassigned template is harmless; deleting the assigned one changes the site. Only pom_theme_get_template_assignments tells you which is which.
Read both before any cleanup:
List the templates and the assignments, and tell me which templates are unused.
css_stylesheets and js_scripts are attachments
Templates reference managed CSS and existing scripts loaded when the template renders. The listing shows native saved references, which may be paths, existing URLs or feature tokens, without source code. Omit unchanged asset fields on writes. New selections use exact identifiers from the corresponding live catalog, including pom_theme_get_script_catalog with target: template for scripts.
That matters when moving a template between sites: the markup travels, the referenced assets do not, and a template whose CSS identifiers point at nothing renders unstyled.
merge_tag_sources points at the theme's own definitions
The response names the theme files where merge tags are defined, one per template type, plus the parser.
They are a pointer for developers reading the theme's source. For writing templates, use the merge tag resources instead — archive, single, feed — which list the tags themselves.
The response can be large
Every template's full markup, in one payload. On a site with many templates this is a lot of HTML.
Ask for what you need:
List the templates and show me only the names and identifiers, grouped by type.
Using it well
Auditing:
List the templates and tell me which use
{{archive_results}}.
Before creating one:
Is there already an archive template that does something similar?
Common problems
| Symptom | Cause |
|---|---|
| The tool is missing | POM Theme is not available |
pom_ai_mcp_forbidden |
Missing edit_theme_options |
| All three lists are empty | No custom templates; the theme's built-in layouts are in use |
| A template's markup is empty | Its file is missing or unreadable |
| Two templates with the same name | Allowed; use the identifiers |
| You cannot tell which is live | Read the assignments |