Skip to main content
Glama

Create HelpCenter Article

helpcenter_create_article
Destructive

Create a new article in the connected HelpCenter.io help center.

Requires a write-scoped API key (read-scoped keys get a permission error). Titles, content, and slugs are per-language objects keyed by language code. Slugs auto-generate from the title when omitted.

Args:

  • title (object, required): per-language title, e.g. {"en": "Getting started"}.

  • content (object, optional): per-language body.

  • slug (object, optional): per-language URL slug (auto-generated from title if omitted).

  • category_id (number, optional): primary category id, or 0 for uncategorized.

  • categories (number[], optional): additional category ids to attach.

  • type ('article' | 'faq', optional): default 'article'.

  • visibility ('public' | 'private' | 'link_only', optional): default 'public'.

  • published (boolean, optional): true publishes immediately, false (default) keeps a draft.

  • external_id (string, optional): a stable key you own. Sending it makes this call an UPSERT — the same key twice updates the article it created instead of creating a second one. Use it whenever a run might be retried.

  • content_format ('html' | 'markdown', optional): defaults to 'html'. If you are writing markdown, you must set this or the raw markdown is stored as the body.

  • rehost_images (boolean, optional): ON by default through this connector. Copies the images the content references from other hosts (and inline data: images) into this help center's own storage and points the article at the copies, so it no longer depends on the source site. Send false to keep the original image URLs.

  • change_note (string, optional, up to 2,000 characters): why you are making this change, in a sentence or two of plain text. TEAM-ONLY: the team reads it beside the edit in the dashboard's Overview; it is never in a response, a webhook, search, or anything a reader sees. Give one whenever you change content.

  • change_refs (array, optional, at most 5): links to what asked for the change — a ticket, a pull request, a release note — each { label (up to 80 characters), url (https on a public host name; not an IP address or localhost, no user:password@) }. Team-only, like change_note.

Returns: { status: "success", action: "created" | "updated", article: {...}, images? }. HTTP 201 on create, 200 when an external_id matched an existing article. images — { rehosted, reused, failed, failed_count } — is present whenever content was processed for images; a failed image keeps its original URL, so check failed before reporting the import complete.

Errors: 403 if the key is read-scoped; 400 if a language code is not enabled for the site or a category id does not belong to the site; 409 if the external_id already belongs to a different article (it is deliberately not re-pointed — that would make your next replay overwrite the wrong article). A change_note or change_refs the API refuses (too long, too many links, a url that is not https on a public host) refuses the whole call, and nothing is written.

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": {
      "title": "<title>"
    },
    "name": "helpcenter_create_article"
  }
}

Input Schema

NameRequiredDescriptionDefault
slugNoPer-language URL slug. Auto-generated from the title if omitted.
typeNoContent type (default 'article').
titleYesPer-language title (required), e.g. {"en": "Getting started"}.
contentNoPer-language article body (HTML/markdown as your site uses).
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.
publishedNotrue publishes the article, false keeps it as a draft.
categoriesNoAdditional category ids to attach (multi-category). All must belong to this site.
visibilityNoVisibility: 'public', 'private' (team only), or 'link_only' (shareable token URL).
category_idNoPrimary category id, or 0 for uncategorized. Must belong to this site.
change_noteNoWhy you are making this change, in a sentence or two of plain text, up to 2,000 characters, e.g. "Pro plan renamed Growth in the 4.2 pricing." TEAM-ONLY: kept beside the edit in the dashboard's Overview, never in an API response, a webhook, search or anything a reader sees. Give one whenever you change content.
change_refsNoUp to 5 links to what asked for this change — a ticket, a pull request, a release note — each { label, url }. Team-only, like change_note.
external_idNoA stable key you own (a source filename, CMS id, repo slug). Makes writes idempotent: sending the same key again updates the article it created instead of creating a second one, so an interrupted run can simply be replayed. Strongly recommended whenever you may retry.
rehost_imagesNoCopy images the content references from other hosts (and inline data: images) into this help center's own storage, and point the article at the copies. ON by default through this connector; send false to keep the original image URLs. The response's `images` reports what was re-hosted and what failed.
content_formatNoFormat of the `content` you are sending. Defaults to 'html'. Set 'markdown' when content is markdown and the API will convert it — sending markdown without this stores the raw markup as the article body.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Goes well past the annotations: states the write-scoped key requirement and the 403 it produces, explains the upsert semantics of external_id and why 409 deliberately refuses to re-point a key, documents rehost_images being ON by default with the images report so failures aren't reported as success, and clarifies change_note/change_refs are team-only and never surfaced to readers. The apparent tension with idempotentHint=false is resolved in the text itself — idempotency is conditional on external_id — so this is clarification, not contradiction.

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?

Front-loaded with the purpose, then organized into Args/Returns/Errors, which is easy to scan. However, the Args list duplicates schema text almost one-for-one across 14 parameters, inflating length without adding information — and site_id, the one param that governs which help center is touched, is omitted from the Args block entirely.

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?

With no output schema, the description carries the return contract (status/action/article/images) and HTTP status codes, plus the 403/400/409 failure modes and the atomic-refusal rule for bad change_note/change_refs. For a 14-parameter, nested-object write tool, an agent has everything needed to call it correctly and interpret failures.

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 the baseline is 3. The Args block largely restates the schema descriptions verbatim; the genuinely additive content (upsert consequences, rehost default, change_note visibility) is already reflected in the schema's own descriptions, so the description doesn't meaningfully extend parameter meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence states a specific verb and resource ("Create a new article in the connected HelpCenter.io help center"), which is unambiguous. Sibling tools like helpcenter_update_article and helpcenter_bulk_create_articles are never mentioned, and the external_id upsert behavior blurs the create/update boundary without addressing that overlap explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Strong conditional guidance is embedded per-parameter: use external_id "whenever a run might be retried," set content_format='markdown' or markdown is stored raw, send rehost_images=false to keep original URLs. What's missing is routing guidance against alternatives — when to prefer bulk_create_articles or update_article instead.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources