Skip to main content
Glama

list_theme_properties

Read-onlyIdempotent

List the design and label properties a checkout page, event or form can override, with their value format and allowed values. A property with a fixed default (every label, and a few other properties) lists it; the others follow the page's theme. Read-only, from a fixed list of about 800 properties: narrow it with group, prefix or a search of one or two words, such as button radius or pay button color, since the whole list, or the whole elements group, is too long to read at once. A search lists the properties that match every word or, when none do, those that match any word, best match first, and at most 40 of them: total counts every match, and note says when to narrow the search or which word matched nothing.

prefix takes the path of the part of the page you are changing. elements.product.* is the product column (title, logo, pricing, pricePicker for the price options), elements.checkout.* the checkout column (cards, variants, ticketGroups, pwyw, confirmation), and elements.checkout.form.* the form (fields, button, priceBreakdown, paymentDetails, discountCode, manualPayments). The tokens, layout and labels groups are small enough to list whole.

Set them under themeOverrides on create_checkout_page, update_checkout_page, create_event, update_event, create_form and update_form, nested by path: tokens.colorPrimary is { "tokens": { "colorPrimary": { "light": "#1A73E8" } } }. Keys you leave out keep their value, and null resets a property, or everything under a key, to the theme default. Labels are the text customers see, so translate a page by setting them. hostedLayoutType (center, double or split) picks the page layout; layout.* properties style the layout they name.

Value formats by type:

  • color: { "light": ..., "dark": ... }, one color for light and one for dark color mode. The page shows the one for its color mode, tokens.colors. Either can be left out. Each is any CSS color value, for example #1A73E8, rgb(26 115 232), hsl(214 82% 51%) or a named color such as navy. The API refuses ;, {, }, < and > but doesn't check that the value is a valid color: an invalid one is stored, and the browser ignores it on the page.

  • font: a Google Fonts family name, such as Inter.

  • size, fontSize: a number of pixels, or "" for Auto when options lists it.

  • fontWeight: 100 to 900 in steps of 100.

  • toggle: true or false.

  • image: { "file": "<id>" }, the ID of an image uploaded with upload_file.

  • text: plain text or inline markdown, no HTML. customCss takes CSS instead.

  • select, shadow, alignment, fontStyle: one of options. When a property has options, only those values are accepted.

customCss needs a plan that includes custom CSS, and the Powered by Checkout Page and Powered by Stripe badges can only be changed with a paid subscription. A null reset works on any plan.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
groupNoOnly list one group. `tokens`: brand colors, fonts and corner radius used across the page. `layout`: backgrounds, images and column settings of each hosted layout. `labels`: the text customers see, which is also where translations go. `elements`: styling of single parts of the page, such as the title, price options, variants, form fields, pay button and trust badges. `customCss`: CSS added to the page, for changes the other properties cannot make.
prefixNoOnly list the properties under this path, matched on whole segments, for example `elements.product.pricePicker` or `elements.checkout.form.button`. The cheapest way to read the properties of one part of the page.
searchNoOne or two words for what you are changing, for example `button radius`, `pay button color` or `heading font`, or a path or key such as `colorPrimary`. Each word matches the start of a word in the property path or description, case-insensitively, so `radi` finds `borderRadius`. Common words such as `corner`, `rounded`, `pay button` and `colour` find the properties they mean. Lists the properties that match every word or, when none do, those that match any word, best match first, and at most 40 of them. Words such as `the`, `on` or `make` are ignored.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataYesThe theme properties the page tools accept under `themeOverrides`.
noteNoSet when a search was cut to its best matches, matched only some of its words, or had a word nothing matches: what to change in the next call.
totalYesNumber of properties that match. A search returns at most the best 40, so `total` can be more than the rows in `data`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/openWorld=false, but the description adds real behavioral context: a fixed list of ~800 properties, a 40-result cap per search with `total` and `note` semantics, plan gating for `customCss` and the Powered-by badges, and the fact that the API rejects `;{}<>` yet does not validate color values. That goes well beyond the annotation set.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and narrowing advice are front-loaded, and the type-format list is bulleted and scannable. It is nonetheless long (several dense paragraphs) and some path/structure detail overlaps the schema, so it is efficient but not maximally tight.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex read tool with an output schema present, the description supplies everything an agent needs to call it correctly: how to scope the query, the shape of the values, how to nest them under themeOverrides, reset semantics (`null`), and plan restrictions. Return values are correctly left to the output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the schema already documents group/prefix/search, so the baseline is 3. The description nonetheless adds usable semantics beyond it: the `elements.product.*` / `elements.checkout.*` / `elements.checkout.form.*` path structure, worked search examples (`button radius`, `pay button color`), and the any-word fallback ranking behavior.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence gives a precise verb (List) and resource (design and label properties a checkout page, event or form can override), plus the scope of what is returned (value format and allowed values). It is immediately distinguishable from sibling tools like list_themes, get_theme or update_theme.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly tells the agent when to narrow (`group`, `prefix`, `search`) because the full list or the `elements` group is too long to read at once, and notes which groups are small enough to list whole. It also routes the agent to the mutation tools where these properties are set (create/update_checkout_page, event, form), though it does not contrast with list_themes/get_theme directly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources