Skip to main content
Glama
Sign In

HelpCenter.io for agents

by io.helpcenter
OverviewDiscussionsAdmin

Add Components to the Design

helpcenter_add_template_components

Add components to pages of the draft: a Hero, a CategoryGrid, FeaturedArticles, Faqs, RichText, a CustomHtml block, a Container…

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 names a component type and where it goes: a page and region (header, hero, sidebar, main, footer, utility) at an index (omit to append), or parent_id to put it inside a Hero or Container. Look the type's settings up first (helpcenter_get_template_guide, topic 'components'): omitted settings keep their defaults, and a value outside the editor's options is refused. A new Hero comes with a SearchBar child. To build a container and its children in one call, give the container an id of your own and name it as parent_id in the later entries.

Placement: a banner across the top of a page goes at index 0 of the hero region (a full-bleed CustomHtml) or the top of main — not the header, which themes lay out as one fixed row. A region the outline marks "laid out by custom CSS" arranges what you add the theme's way. header and footer are usually synced (one copy on every page); adding to a synced region whose pages differ is refused until you choose with helpcenter_sync_template_region. This is the guide's add_component operation.

Args:

  • components (array, 1-50): {type, page?, region?, parent_id?, config?, index?, id?}.

  • 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.
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.
componentsYesThe components to add. 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.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only cover readOnly/destructive/idempotent flags; the description adds the real behavioral context: draft-vs-live semantics with a live preview, the migration_required refusal for classic help centers, refusal of config values outside editor options, default retention for omitted settings, and the automatic SearchBar child on a new Hero.

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 organized into placement, draft/publish, version constraints, and a Returns line. It is dense but nearly every sentence carries operational value; the trailing ellipsis list in the opening sentence is slightly wasteful.

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, yet the description still explains what comes back (new ids, warnings, draft status with new etag). Combined with placement rules for banners and custom-CSS regions, sync requirements, and the all-or-nothing nature of the batch, an agent has everything needed to call 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 100%, so the baseline is 3, but the description adds meaning beyond the schema: it explains the self-chosen id trick for building a container and its children in one call, how parent_id overrides page/region, and that a new Hero brings a SearchBar child. It does not add much about etag or the agent_key credential, which the schema already handles.

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 — adding components (Hero, CategoryGrid, CustomHtml, etc.) to pages of the help center design draft — and immediately distinguishes this from the sibling update/move/remove component tools by naming the draft it edits and the publish tool that makes it live.

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 explicit when-to-use and when-not: v2 help centers only (classic returns template_migration_required), nothing reaches visitors until helpcenter_publish_template, publish only when the customer asks, read settings via helpcenter_get_template_guide first, get ids from helpcenter_get_template, and resolve region conflicts with helpcenter_sync_template_region before adding to a synced region.

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

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