pom_theme_get_css_build_info: inspect asset build information
Explains how POM Theme assembles website.min.css, and includes the current state of that file.
Arguments
None.
Permissions
mcp:read and pom_theme:read, plus edit_theme_options.
What it returns
| Field | Meaning |
|---|---|
entrypoints |
The generator and compiler that produce the file |
bootstrap_imports |
Which Bootstrap partials are included |
theme_sass_imports |
The theme's own Sass partials, in order |
conditional_imports |
Partials included only when a feature is in use |
generated_sections |
The parts built from your settings |
filter |
The hook for adding CSS to the build |
output |
The same metadata pom_theme_get_generated_css returns |
It is a description, not a live trace
The lists are a static account of the build's composition. They do not change based on what happened during the last run, and they do not report whether a particular partial was actually compiled this time.
So this tool answers "what goes into the stylesheet, in principle". For "what happened to the file", read output, or use the generated CSS tool directly.
generated_sections is where your settings end up
Colour palette, typography, buttons, header and the footer contact widget are compiled from POM Theme settings into the stylesheet.
That is the mechanism behind a fact worth internalising: theme settings become CSS at build time. Changing a colour in the settings does nothing to the site until the assets regenerate. This list is what tells you which settings work that way.
It is also why the theme's save routine triggers a rebuild — without it, settings and stylesheet drift apart.
The import lists explain specificity fights
When custom CSS is overridden by something you cannot find, the order here usually explains it. Bootstrap comes first, the theme's own partials after, and the settings-generated sections after that.
Custom CSS added through the global stylesheet or snippets is appended via the reported filter, so it lands late — which is why it usually wins, and why when it does not, the cause is specificity rather than order.
Use this to reason about a stubborn rule before reaching for !important.
conditional_imports explains missing styles
Some partials are compiled only when the relevant feature is in use. A site that has never enabled a feature does not carry its CSS.
So enabling a feature and finding it unstyled is often a build that predates the change. Regenerating the assets is the fix, not more CSS.
filter is for developers
The reported hook is where a plugin or child theme injects CSS into the compiled output. It is the supported way to add styling programmatically, as opposed to the settings-based tools in this chapter.
Nothing an assistant does through MCP uses it. It is here so that someone diagnosing unexpected CSS knows where else it could be coming from — see Public hooks.
When to reach for it
Rarely, and usefully:
- Custom CSS is being overridden and you want to know by what.
- A settings change did not show up and you want to confirm that setting is compiled rather than applied inline.
- Someone asks where a rule in the compiled stylesheet came from.
For everyday work — did my change land, is the file current — pom_theme_get_generated_css is the smaller, more direct answer.
Common problems
| Symptom | Cause |
|---|---|
| The tool is missing | POM Theme is not available |
pom_ai_mcp_forbidden |
Missing edit_theme_options |
| The lists never change | Correct; they describe the build, not a run |
| A settings change is not in the stylesheet | The assets have not been regenerated |
output.exists is false |
The stylesheet has never been built |
| CSS from an unknown source | Check the reported filter |