HelpCenter.io

Publish the Help Center Design

helpcenter_publish_template

Destructive

Put the draft live: every visitor sees the new design from now on. Records a version (restorable later) and starts a fresh draft from it — exactly the Template Editor's Publish button.

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.

This is the ONE template call that changes the live help center. Publish only when the customer has asked you to — ideally after they reviewed the draft in the Template Editor (the customizer link from helpcenter_get_template). Pass the etag they reviewed, so a draft that changed after their review is refused rather than published unseen.

Args:

message (string, optional): a note for the version history, e.g. 'Brand refresh'.
etag (string, optional): the reviewed draft's etag.

Returns: the published version and the new draft status.

Errors: 409 nothing_to_publish when the draft matches the live design; 412 stale_draft when the draft changed after the etag.

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_publish_template"
  }
}

Input Schema

Name	Required	Description
`etag`	No	The draft etag the customer reviewed. When given, publishing is refused if the draft changed since — so exactly what was reviewed goes live.
`message`	No	A short note for the version history, e.g. 'Brand refresh'.
`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.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 4, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Adds substantial context beyond the annotations: a version is recorded and restorable, a fresh draft is started, and the 409 nothing_to_publish and 412 stale_draft failure modes are named with their triggers. The etag-refusal rule ('refused rather than published unseen') explains a non-obvious safety behavior. It does not contradict the destructiveHint=true annotation — it qualifies it by noting the previous version is restorable.

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

Conciseness3/5

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

The opening sentence and the closing Args/Returns/Errors block are tight and front-loaded, but the middle paragraph inventories six page kinds and six regions, which is reference material about the template model rather than guidance for calling publish. That inventory crowds out an operational detail such as site_id propagation.

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 zero-required-parameter publish call with no output schema, the description covers the return value, both error paths, the review prerequisite, the v1 restriction, and the version/draft lifecycle. An agent has everything needed to decide whether and how to call it.

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 baseline is 3; the description earns an increment by tying etag to a workflow ('Pass the etag they reviewed') and stating the consequence of mismatch, and by giving a message example for version history. site_id is only handled by the schema, though, and nothing in the description tells the agent to pass it on every call of a multi-site task.

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 object ('Put the draft live'), names the underlying resource (the v2 template), and explicitly claims the scope: 'This is the ONE template call that changes the live help center.' An agent can separate it from the other template_* siblings without opening any 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?

Gives an explicit when ('Publish only when the customer has asked you to'), a recommended prerequisite ('ideally after they reviewed the draft in the Template Editor (the customizer link from helpcenter_get_template)'), and a hard blocker (v1 sites answer template_migration_required and migration is the owner's decision). It also routes the agent to helpcenter_get_template for the review link and warns against publishing unreviewed drafts.

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?