HelpCenter.io

Change Design Settings

helpcenter_update_template_settings

DestructiveIdempotent

Change document-level design settings in the draft: theme colours (light and dark), fonts, corner radius and density; the brand (name, logo, favicon); meta and SEO; and per-page settings such as a page's layout or how a category page lists its articles.

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.

Each entry is a path and its new value — 'theme.colors.primary' → '#635bff' — or a whole group at once: 'theme.colors' → {primary, accent, …}. The paths and the values each accepts are in helpcenter_get_template_guide (topic 'settings'); anything else is refused with the list of what is accepted. Colours take hex, rgb() or hsl() (stored as hex); set theme.darkColors alongside theme.colors so dark mode stays readable. An image setting (brand.logoAssetId, brand.faviconAssetId) takes {source_url: 'https://…'}: the image is copied onto this help center. Region styling has its own tool (helpcenter_update_template_region). This is the guide's set operation.

Args:

settings (array, 1-50): {path, value}; null clears a nullable setting.
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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "settings": "<settings>"
    },
    "name": "helpcenter_update_template_settings"
  }
}

Input Schema

Name	Required	Description
`etag`	No	Optimistic 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.
`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.
`settings`	Yes	The settings to change. Applied in order, all-or-nothing: if one is refused, nothing from this call is saved and the error names it by position (operation 0 is the first entry).

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 4, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already flag destructiveHint/openWorldHint, and the description adds substantial context beyond them: the edit lands in the draft only, a Template Editor link should be relayed to the customer, the v2-only error is named, etag staleness is explained, and unrecognized paths are refused with the list of accepted values. It also documents side effects like images being copied onto the help center and the need to set theme.darkColors alongside theme.colors.

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 purpose, then draft semantics, then format guidance, then the return summary — no filler sentences, and the parenthetical examples ('theme.colors.primary' → '#635bff') do work. It is dense and slightly overpacked in the middle paragraph, but every clause carries actionable information.

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?

Given a mutation tool with no output schema, the description covers the return shape (per-entry results with new ids, warnings, draft status and new etag), the failure modes (stale_draft, template_migration_required, refused paths), and the review-then-publish workflow. Nothing an agent needs to call it safely is missing.

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 still adds real meaning by explaining the path+value entry form, whole-group updates ('theme.colors' → object), accepted colour syntax (hex/rgb()/hsl(), stored as hex), the {source_url} shape for image settings, and null semantics for nullable settings. It stops short of enumerating valid paths (deferring to the guide), which keeps it below the top score.

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 first sentence names a specific verb and resource (change document-level design settings in the draft) and enumerates the scope precisely: theme colours/fonts/radius/density, brand, meta/SEO, and per-page settings. It explicitly carves out region styling to helpcenter_update_template_region and identifies itself as the guide's `set` operation, so it is distinguishable from siblings without opening a schema.

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?

States when to use it (draft design edits, with ids from helpcenter_get_template and paths from helpcenter_get_template_guide topic 'settings'), when not to (region styling → own tool; classic help centers answer template_migration_required), and the workflow constraint: nothing reaches visitors until helpcenter_publish_template, publish only when asked. Alternatives and prerequisites are explicit.

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?