Skip to main content
Glama
Sign In

Checkout Page

by com.checkoutpage
OverviewDiscussionsAdmin

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, heading, 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. Before writing customCss, list the customCss group: its note names the class names on the page and how to write CSS that works there.

Input 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

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. When `customCss` is listed, it also says which class names custom CSS can select and how to write it.
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. Changed1 schema field changed
    • changedOutput schema / properties / note / description
      Previous value: -"Set 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."New value: +"Set 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. When `customCss` is listed, it also says which class names custom CSS can select and how to write it."
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only cover the read-only/idempotent safety profile; the description adds substantial behavior: a fixed list of ~800 properties, a 40-result cap with `total` and `note` in the response, the all-words-then-any-words fallback ordering, server-side rejection of `;{}<>`, the fact that invalid colors are stored and silently ignored by the browser, plan gating for `customCss` and the Powered-by badges, and that `null` resets work on any plan.

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?

It is front-loaded with purpose then narrowing strategy, and the value-format bullets and path map are well organized and decision-relevant. It is long (~500 words) and contains at least one passage — the every-word/any-word/40-match/`total`/`note` sentence — that restates the `search` schema description, which is the main trimming opportunity.

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 3-optional-parameter read tool with an output schema, the description covers everything an agent needs: what it returns conceptually, how to narrow, how to interpret the response's match metadata, the exact `themeOverrides` nesting example, and the reset and plan constraints. Nothing material is left to inference.

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 coverage is 100%, so baseline is 3; the description goes beyond it by mapping `prefix` paths to page regions (`elements.product.*`, `elements.checkout.form.*`) and flagging which groups are small enough to read whole. However, the search fallback/40-match/total/note wording is repeated almost verbatim from the schema's `search` description, so part of the added text is duplication rather than new meaning.

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 names a specific verb and resource — 'List the design and label properties a checkout page, event or form can override' — and adds the return content (value format and allowed values). It is clearly a read-only catalog lookup, distinct from the theme CRUD siblings (list_themes, get_theme, update_theme), and it names the write tools (create_checkout_page, update_form, etc.) where the values are consumed.

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

Usage Guidelines5/5

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

It states explicitly when not to read the whole thing ('the whole list, or the whole `elements` group, is too long to read at once') and which narrowing knob to use, including which groups are small enough to list whole (tokens, layout, labels). It also gives a sequencing rule for the deepest case: 'Before writing `customCss`, list the `customCss` group.'

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

All Checkout Page toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources