pom_theme_list_settings_schema: list settings schemas
Returns the full structure of POM Theme's options page — sections, tabs, settings and their fields.
Arguments
None. It returns everything.
Permissions
mcp:read and pom_theme:read, plus edit_theme_options.
What it returns
page_slug, always pom-theme-options, and sections. Each section has a title and its tabs; each tab has a title and its settings; each setting has:
| Field | Meaning |
|---|---|
title |
Its label in the admin |
requires_initialization |
Whether it must be saved once before it holds values |
fields |
A summary of every field it contains |
The config section is excluded — it is internal plumbing, not configuration.
It is a map, not the values
This tool tells you what can be configured and what each setting is called. It does not tell you what anything is currently set to; that is pom_theme_get_settings_values, which needs a setting key you get from here.
The two together are the read pair. This one first, always, because setting keys are not guessable.
List the settings schema and show me the sections and tabs.
Use it to find the right key
Setting keys are internal identifiers, and the labels people use do not map onto them cleanly. Someone asking to change "the blog sidebar" is describing something the schema calls post_archive.
Which setting and field control the sidebar layout on the blog archive?
Getting this wrong produces pom_ai_mcp_theme_setting_not_found, or worse, a successful read of the wrong setting.
requires_initialization explains empty values
A setting flagged this way holds nothing until it has been saved once from the WordPress admin. Reading it returns an empty set, and that is not a fault.
So an empty values response for such a setting means "nobody has configured this yet", not "this setting is broken". Saving it once in the admin populates the defaults.
The schema does not say what is writable
This is the important limitation. Every field POM Theme defines appears here, and pom_theme_update_setting will refuse nearly all of them: its allowlist contains two fields by default.
The schema is therefore a map of the theme's configuration, not a menu of what MCP can change. An assistant that reads the schema and offers to adjust any field it finds will be refused with pom_ai_mcp_theme_field_denied on almost every attempt.
Treat the schema as documentation of the admin interface, and the allowlist as the separate, much shorter question of what a connected client may write.
The response is large
A full POM Theme installation has many sections, each with tabs and dozens of fields. Expect a substantial response, and ask for the part you need rather than a recital:
List the schema and show me only the sections related to typography.
Field summaries are structural
Each field summary describes its type and shape, which is how you know whether a value should be text, a choice, or something complex. Fields typed as code — CSS, HTML, JavaScript — are stored as files rather than inline values, which is why reading them needs the resolve_code_files option on the values tool.
JavaScript fields appear in the schema and can never be written; that refusal is unconditional.
Common problems
| Symptom | Cause |
|---|---|
| The tool is missing | POM Theme is not available; check the status tool |
pom_ai_mcp_forbidden |
Missing edit_theme_options |
| No values in the response | Correct; this returns structure only |
| A setting you use is absent | It may live in the excluded config section |
| A field here cannot be written | The allowlist is separate and much shorter |
Empty fields for a setting |
Its field definitions were not found on disk |
Related
pom_theme_get_settings_values— the valuespom_theme_update_setting— what is actually writable- Theme settings schema resource