Skip to main content
Glama
Sign In

HelpCenter.io

by io.helpcenter
OverviewDiscussionsAdmin

Get Help Center Template

helpcenter_get_template
Read-onlyIdempotent

Read a help center's current design (the draft): its status, the Template Editor link for the customer to review, and an outline of every page — or one part of the draft 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.

Start here. The outline (the default) gives every component's id and type with only the settings that differ from their defaults, the theme, brand and meta in full, and indexes of navigation, scripts and custom CSS — enough to plan an edit without reading the whole document. Then read the part you are about to change in full: section 'component' with its id, 'page', 'region', a CSS block or script by id.

It also returns the draft's etag: pass it to an edit tool or to helpcenter_publish_template to be refused (instead of silently overwriting) if someone changed the draft meanwhile — a person may be editing it in the Template Editor at the same time.

Args:

  • section: 'outline' (default) | 'document' | 'brand' | 'theme' | 'meta' | 'navigation' | 'scripts' | 'custom_css' | 'page' | 'region' | 'component' | 'translations'.

  • page / region / id: for the 'page', 'region', 'component', 'custom_css' and 'scripts' sections.

  • response_format ('markdown' | 'json'): default 'markdown'.

Errors: 409 template_migration_required for a classic (v1) help center; 404 for an unknown component, CSS or script id.

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

Input Schema

NameRequiredDescriptionDefault
idNoComponent / CSS block / script id, for those sections.
pageNoPage kind: home, category, article, search, contact or notFound.
regionNoRegion of the page: header, hero, sidebar, main, footer or utility.
sectionNo'outline' (default: status, links and a compact map of the draft — every component id, and only settings that differ from their defaults), or one part of the draft document: 'page' (with page), 'region' (with page and region), 'component' (with id), 'custom_css' / 'scripts' (all, or one with id), 'brand', 'theme', 'meta', 'navigation', 'translations', or the whole 'document' (large — prefer parts).outline
site_idNoWhich 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_formatNoOutput format: 'markdown' for a human-readable summary or 'json' for the full structured payload.markdown

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?

Annotations already cover the read-only, idempotent, non-destructive profile, and the description goes well beyond them: it explains that edits target a draft that nothing reaches visitors until publish, that the draft is shared with the dashboard's Template Editor, and that the returned etag triggers a refusal instead of a silent overwrite on concurrent edits. Concrete error codes (409, 404) are also disclosed.

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?

The core purpose is front-loaded in the first sentence and the workflow in the third paragraph, with no filler. It loses a little to redundancy — the six page kinds, six regions and section list are restated in prose even though the schema enums already enumerate them.

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 six-parameter, zero-required tool with no output schema in a complex template domain, the description covers the data model, draft-versus-live semantics, version restrictions, concurrency via etag, and error cases. An agent has everything needed to call it correctly without further documentation.

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 the schema already documents each parameter and enum, and the description largely mirrors those lists. It still adds interpretive value by explaining why 'outline' is the default (component ids plus only non-default settings, sufficient to plan an edit) and by pairing each section with its required companion argument.

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 — read a help center's draft design — and enumerates exactly what comes back (status, Template Editor link, page outline, or one part in full). It clearly separates this read operation from the mutation siblings named later (helpcenter_publish_template, edit tools), so an agent can distinguish it without opening the 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?

Explicitly says 'Start here' and prescribes a sequence: read the outline to plan an edit, then read the specific section in full before changing it. It also warns that only v2 help centers are editable and that v1 returns template_migration_required, which tells the agent when this call will fail and what that means.

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

All HelpCenter.io toolsInspect
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