HelpCenter.io

List Help Center Themes

helpcenter_list_template_themes

Read-onlyIdempotent

List the ready-made themes a help center can start from, or describe one in full.

A help center's design is its v2 template: theme tokens (colours for light and dark mode, fonts, radius, density), six page kinds (home, category, article, search, contact, notFound), each built from six regions (header, hero, sidebar, main, footer, utility) holding ordered components, plus a global navigation menu, custom CSS and scripts. You edit a DRAFT — the same draft the dashboard's Template Editor opens, with a live preview — and nothing reaches visitors until helpcenter_publish_template. Only v2 help centers can be edited: a classic (v1) one answers template_migration_required, and migrating is the owner's decision, made in the dashboard.

Use it when the customer wants a new look, or a starting point to customize from. Each theme has a key, a summary, what it suits, its palette and fonts; the one the draft started from is marked current. Pass theme to see what each page of that theme is built from and which sections applying it would change.

Args:

theme (string, optional): a theme key to describe in full.
response_format ('markdown' | 'json'): default 'markdown'.

Returns: the gallery, or one theme with changed_sections. Apply one with helpcenter_apply_template_theme.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "helpcenter_list_template_themes"
  }
}

Input Schema

Name	Required	Description	Default
`theme`	No	A theme key to describe in full — its description, what each page is built from, and which sections applying it would change. Omit to list the gallery.
`site_id`	No	Which help center to act on: an id from helpcenter_list_sites. Needed when this connection reaches more than one help center; omit it when it reaches one. Applies to this call only — pass it on every call of a task, and ask the user which help center they mean if their request does not say.
`response_format`	No	Output format: 'markdown' for a human-readable summary or 'json' for the full structured payload.	markdown

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 4, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: edits target a DRAFT shared with the dashboard's Template Editor, nothing reaches visitors until helpcenter_publish_template, and v1 help centers return template_migration_required with migration being an owner decision. That is exactly the kind of precondition and side-effect knowledge annotations cannot express.

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 is front-loaded in the first line, followed by the domain model, then usage, then args and returns — a sensible order. The middle paragraph is dense (theme tokens, six page kinds, six regions, navigation, CSS/scripts) and is more context than a list operation strictly needs, though it does help an agent interpret the returned theme structure.

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?

With no output schema, the description carries the return burden itself: 'Returns: the gallery, or one theme with changed_sections.' Combined with the draft/publish model, the v1 restriction, and the pointer to the apply tool, an agent has everything needed to call this correctly and act on the result.

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

Parameters3/5

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

Schema coverage is 100%, so all three parameters are already documented, including site_id's multi-site rule. The description reinforces `theme` as the switch between gallery and detail mode and notes changed_sections, but it adds little syntax or constraint information the schema does not already carry, so baseline 3 applies.

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?

Opens with a specific verb and resource: 'List the ready-made themes a help center can start from, or describe one in full.' The dual mode (gallery vs. single-theme detail) is stated up front, and the following sentence defines exactly what a 'theme' is in this system, so the agent knows what it is retrieving rather than guessing.

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?

'Use it when the customer wants a new look, or a starting point to customize from' gives a clear triggering condition, and the closing line routes the agent to helpcenter_apply_template_theme for the actual application step, which is the key alternative. It does not explicitly exclude sibling reads like helpcenter_get_template, but the browse-vs-inspect split is inferable from the framing.

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

All HelpCenter.io tools Inspect

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

Need Help?