Skip to main content
Glama

HelpCenter.io for agents

Style a Page Region

helpcenter_update_template_region
DestructiveIdempotent

Style one region's wrapper on one page: its background, padding, bottom border and alignment.

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.

config takes background (hex, or 'var(--hc-color-primary)' to follow the theme), padding (compact | standard | tall), borderBottom (boolean) and align (left | center); null resets one, and keys left out keep their value. Themes ship custom CSS that can paint a region itself (Compass paints the header and hero), and that CSS outranks this setting: when the outline marks the region "laid out by custom CSS", restyle it with helpcenter_add_template_css instead. This is the guide's update_region operation.

Args:

  • page, region: which region.

  • config (object): the styling keys 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
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.
pageYesPage kind: home, category, article, search, contact or notFound.
configYesRegion styling: background (hex or 'var(--hc-color-primary)'), padding (compact | standard | tall), borderBottom (boolean), align (left | center). null resets one.
regionYesRegion of the page: header, hero, sidebar, main, footer or utility.
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.9/5.0
Behavior5/5

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

The annotations already declare a non-read-only, destructive, idempotent, open-world operation. The description adds substantial behavior beyond them: draft isolation, live preview, publish gating, the v2-only error path, etag concurrency refusal, and the warning that custom CSS outranks this setting.

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

Conciseness5/5

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

The description is dense but front-loaded and organized around operation, constraints, config semantics, arguments, and returns. Every sentence carries actionable information, with no obvious filler.

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 mutation with a nested config object, no output schema, and draft/publish semantics, the description covers the operation, constraints, safety behavior, alternative path, arguments, and return shape. An agent has enough information to invoke it 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 already 100%, so the schema documents the parameters well. The description still adds useful semantics beyond the schema, especially that null resets a config key, omitted keys retain their values, CSS can override the region, and etag guards against stale-draft edits.

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 description states a specific verb and scope: style one region's wrapper on one page, with background, padding, border, and alignment. It clearly distinguishes the tool from broader template editing by naming the draft template and the separate publish operation.

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 gives explicit usage conditions: this edits the design draft, nothing reaches visitors until helpcenter_publish_template, publish only when the customer asks, v2 help centers only, and ids come from helpcenter_get_template. It also names a concrete alternative when custom CSS controls the region: use helpcenter_add_template_css instead.

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