HelpCenter.io for agents

Create a Help Center (no account needed)

helpcenter_create_help_center

Create a new HelpCenter.io help center for the user, with no account and no sign-in: the first step of building or migrating a help center for someone who does not have HelpCenter.io yet.

What it returns (also as structuredContent): site_id, subdomain, api_key, claim_url, expires_at, limits, docs_url.

api_key: this help center's agent key, shown ONLY in this result. Every other tool here that acts on the help center REQUIRES it as agent_key: pass it on each call, exactly as returned, for the rest of the task. This connection has no sign-in, so the key cannot become its credential; the argument is how each call proves which help center it acts on. Keep it to yourself: never show it to the user, write it into content, or send it anywhere but agent_key.
site_id: the help center's id, for helpcenter_get_help_center and helpcenter_discard_help_center.
claim_url: the link the user claims the help center with (they sign up or sign in and verify their email). Give it to the user once the help center is ready. Nothing is emailed to them.

The help center starts private and hidden from search engines, on a temporary address, and is deleted 7 days after creation (expires_at) unless the user claims it. Until it is claimed it holds at most 500 articles (drafts included), 100 categories and 5 languages, and answers only its content and design tools.

Next: fill it — helpcenter_scan_import for a public Zendesk, Intercom, Document360, Help Scout, Front or HelpDocs help center, or helpcenter_create_category and helpcenter_create_article / helpcenter_bulk_create_articles, giving each article the external_id of its address at the source; check it with helpcenter_get_help_center, whose preview_url shows the help center as its readers will see it; then give the user claim_url.

Limits: in ChatGPT, whose connection carries OpenAI's client certificate, creation counts in OpenAI's shared pool, an hourly and an open-at-once allowance across every ChatGPT agent. From any other client it counts in this connector's own pool: 60 help centers an hour and 300 open at once, across every agent using the connector. Migration requests are limited to 30 a day across every agent using the connector, ChatGPT included. On limit_reached or capacity_reached, file a migration request with helpcenter_request_migration instead: it creates the help centers too, up to 50 at once.

Each call creates another help center: call it once per help center the user wants.

Args:

name (string, required): usually the user's product or company. 1-100 characters.
source_url (string, optional): the knowledge base you are migrating, if any.
language (string, optional): the default language, e.g. 'en' (the default), 'de'.

Input Schema

Name	Required	Description
`name`	Yes	The help center's name, usually the user's product or company. A name containing a protected brand name is refused (name_blocked).
`language`	No	The help center's default language, as a locale code: 'en' (the default), 'de', 'pt-BR', 'zh-Hans'...
`source_url`	No	The https address of the knowledge base you are migrating, if any. Kept for HelpCenter.io's migration team and used as the default source of a migration request; never fetched by this call.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 3, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare non-read-only, open-world, non-idempotent, non-destructive, but the description adds substantial undisclosed behavior: the returned api_key is shown only once and must be passed as agent_key on every later call, the help center is private/SEO-hidden on a temporary address, and it is deleted after 7 days unless claimed. It also discloses pools and rate limits (60/hour, 300 open, 30 migration requests/day, OpenAI's shared pool in ChatGPT). Minor gap: it does not state whether creation can fail for reasons other than name_blocked/limits, or how errors surface.

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?

It is front-loaded (purpose, then return values, then lifecycle, then next steps, then limits) and every section is scannable, but it is long for a three-parameter tool and repeats the no-account/no-sign-in point across the title, the opening sentence and the api_key bullet. The bulk is justified by genuinely non-obvious behavior, so it stops short of being verbose padding.

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 creation tool with no output schema and open-world semantics, the description covers the return payload field by field, the post-creation lifecycle and expiry, the unclaimed-state capacity caps, rate limits, and the handoff path to migration. An agent can run the full flow from this description without guessing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so all three parameters are already documented, including constraints like name_blocked and the 'never fetched by this call' note on source_url. The description mostly restates name/source_url/language without adding format or edge-case detail beyond the schema; baseline 3 applies.

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 opens with a specific verb and resource ('Create a new HelpCenter.io help center for the user, with no account and no sign-in') and pins down the exact scenario: the first step for someone who does not have HelpCenter.io yet. It is clearly distinguished from the sibling that also creates help centers (helpcenter_request_migration), which is named only as the fallback on limits.

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 states when to call (first step, once per help center), what to do next (helpcenter_scan_import for a named set of source platforms, or create_category/create_article/bulk_create_articles with external_id), and when to switch tools (on limit_reached/capacity_reached, use helpcenter_request_migration). Explicit alternatives and exclusions are both present.

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 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?