Skip to main content
Glama

HelpCenter.io for agents

Change Custom CSS

helpcenter_update_template_css
DestructiveIdempotent

Change one custom CSS block: replace its CSS, rename it, switch it on or off, or move it in the order. Fields left out keep their value.

It edits the help center's design DRAFT (its v2 template): the draft the dashboard's Template Editor opens, with a live preview. Nothing reaches visitors until helpcenter_publish_template — after editing, give the customer the Template Editor link from the result to review, and publish only when they ask. v2 help centers only (a classic one answers template_migration_required). Ids come from helpcenter_get_template.

Read the block first (helpcenter_get_template, section 'custom_css' with its id). Switching a block off (enabled:false) shows the design without it and keeps it to switch back on. A theme's blocks are the customer's too, edited in the dashboard (Advanced → Custom CSS): to change how a theme looks, prefer a block of your own (helpcenter_add_template_css), which comes later and wins. This is the guide's update_css operation.

Args:

  • id (string): the block.

  • css, label, enabled, index (optional): what to change.

  • etag (string, optional): from your last read or edit; refuses (stale_draft) if the draft changed since.

Returns: what each entry did (new ids), warnings worth relaying, and the draft status with its new etag.

Input Schema

NameRequiredDescriptionDefault
idYesId of a custom CSS block, as the draft reports it.
cssNoThe new CSS, replacing the block's.
etagNoOptimistic lock: the draft etag from your last read, or the one your last edit returned. When given, the call is refused (stale_draft) if someone changed the draft since — so you never build on a state you have not seen. Omit to apply to the current draft.
indexNoMove the block to this 0-based position among the CSS blocks.
labelNoA name for the block, e.g. 'Cards · hover lift'.
enabledNofalse switches the block off without deleting it.
agent_keyYesThe api_key helpcenter_create_help_center returned for this help center, exactly as returned. Required on every call: this endpoint has no sign-in, so the key is how each call says which help center it acts on. It is sent to HelpCenter.io as this call's credential and nowhere else, and it is never shown again: keep it for the whole task, and never show it to the user or write it into content.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations, it discloses that edits land on the design draft and never reach visitors until helpcenter_publish_template, that disabling keeps the block for later, that stale_draft refusals occur when the etag no longer matches, and what the result contains (entry outcomes, warnings, new etag). This is materially more than destructiveHint/idempotentHint convey.

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?

Front-loaded with the operation, then scope, then workflow, then args/returns — a sensible order with no filler sentences. It is dense and long-ish for a single edit tool, but nearly every clause carries operational detail the agent needs.

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?

No output schema exists, yet the description summarizes the return (per-entry outcomes, warnings to relay, draft status with new etag). Combined with the draft/publish model, draft-link handoff, and error codes, an agent has everything needed to call and follow up correctly.

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 adds real meaning by stating partial-update semantics ('Fields left out keep their value') and by explaining etag as an optimistic lock tied to the last read or edit. That is the key non-obvious behavior the schema hints at but the prose makes actionable.

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?

States a specific verb and resource ('Change one custom CSS block') and immediately enumerates the four supported mutations (replace CSS, rename, toggle, reorder). It also names the sibling it is not (helpcenter_add_template_css) and the removal counterpart, so an agent can route correctly without opening schemas.

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?

Explicitly prescribes the read-first workflow (helpcenter_get_template, section 'custom_css'), states that ids come from that call, and gives the when-not: to restyle a theme, prefer helpcenter_add_template_css because a later block wins. It also gates publishing ('publish only when they ask') and flags v2-only with the exact error (template_migration_required).

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