Skip to main content
Glama

HelpCenter.io for agents

List HelpCenter Articles

helpcenter_list_articles
Read-onlyIdempotent

List and browse a HelpCenter.io help center's articles, optionally filtered by category, status or last update, and ordered by views.

Use this to browse "what's in category Y" or "the most-viewed articles", or to walk every article for an audit, a backup or an incremental sync, rather than to search for specific text (use helpcenter_search_articles for that). Read-only. Paginated.

Args:

  • category_id (number, optional): restrict to one category id.

  • status ('published' | 'draft', optional): only published articles, or only drafts. Omit for both.

  • updated_since (string, optional): only articles updated at or after this date or date-time, e.g. '2026-09-01' or '2026-09-01 14:30:00' — the updated_at format items come back in. For an incremental sync pass the newest updated_at from your previous pass; the bound is inclusive, so de-duplicate by id.

  • order_by ('views', optional): only 'views' is supported; omit for default (recently updated).

  • order_type ('asc' | 'desc', optional): sort direction when order_by is set (default 'desc').

  • lang (string, optional): language code for returned text (defaults to the site default).

  • include_content (boolean, optional): default false, so each article comes back WITHOUT its body: id, external_id, title, slug, type, category_id, categories, published, visibility, views, has_staged_changes, staged_locales, staged_updated_at, updated_at and content_length (the body's length in characters, per language). That is the inventory for deciding what to read in full with helpcenter_get_article. true adds every language's full body, for an export, a backup or a content audit.

  • limit (number, optional): items per page, 1-100 (default 100).

  • page (number, optional): page number (default 1).

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

Returns: { total, count, page, per_page, total_pages, has_more, next, items } — items carry the fields listed under include_content, or with include_content: true the full article objects (see helpcenter_search_articles), every language's body included. A page of long articles with bodies can come to several megabytes.

Paging: every response carries next: { page, limit } — the exact arguments that fetch the first item it did not return — or null when nothing is left. Follow next, with the same filters, instead of computing page + 1 yourself. A response is capped at 25000 characters, in its text and in its structured data alike, and 5.0 MB in all: when a page does not fit, only its first items are returned (truncated: true, count says how many) and next points at the rest, usually with a smaller limit and a later page number. Requesting page + 1 with your original limit would skip them. With include_content: true, a page first cuts every body to a plain-text excerpt before withholding any article (those items carry content_truncated: true; read the full body with helpcenter_get_article). Without bodies, the default, far more articles fit in each response.

Errors: auth error if the key is missing/invalid; validation error if category_id is not a category of this site, or if status or updated_since is not a value the API accepts.

Input Schema

NameRequiredDescriptionDefault
langNoLanguage code for returned titles/content (defaults to the site default).
pageNoPage number for pagination (default 1).
limitNoMaximum items to return per page (1-100, default 100).
statusNoOnly published articles, or only drafts. Omit for both.
order_byNoSort field. Only 'views' is supported; omit for default (recently updated).
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.
order_typeNoSort direction when order_by is set (default 'desc').
category_idNoRestrict results to a single category id.
updated_sinceNoOnly articles updated at or after this ISO date or date-time, e.g. '2026-09-01' or '2026-09-01 14:30:00' (the updated_at format items come back in). Inclusive.
include_contentNoDefault false: each article comes back without its body — id, external_id, title, slug, type, category ids, published, visibility, views, staged-change flags, updated_at and content_length per language. Read the ones you need with helpcenter_get_article. true adds every language's full body, for an export, a backup or a content audit; a page of long articles is then several megabytes and may be cut to excerpts.
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 safety profile (readOnly, idempotent, non-destructive), so the description wisely spends its space on behavior annotations cannot express: response caps (25,000 chars / 5.0 MB), item-level truncation with truncated:true, body excerpting with content_truncated, and the next-based paging contract including why page+1 with the original limit would skip items. It also names the error conditions (auth, invalid category_id, invalid status/updated_since).

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 and the sibling exclusion, then organized into Args / Returns / Paging / Errors. It is long, and the Args block substantially duplicates the 100%-covered schema, but the volume is justified by 11 parameters and non-obvious truncation/paging semantics; nothing is padding in the Returns and Paging sections.

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 11 parameters, three enums, and no output schema, the description carries the return-shape burden itself and does so fully — enumeration of item fields, full-object mode, size expectations, and the next-based continuation contract. Little an agent needs in order to call this correctly is left unstated.

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 genuine meaning on top: the inclusive bound on updated_since, the de-duplicate-by-id guidance for incremental syncs, the exact field inventory returned when include_content is false, and that order_by supports only 'views'. Some of this mirrors the schema descriptions rather than exceeding them, which keeps it off a 5.

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 resource ('List and browse ... articles') plus its filterable/sortable dimensions, and immediately contrasts itself with the two nearest siblings: helpcenter_search_articles for text search and helpcenter_get_article for full bodies. An agent can pick this tool 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?

Gives explicit positive cases (browse a category, most-viewed, full audit, backup, incremental sync) and an explicit exclusion with the alternative named ('rather than to search for specific text (use helpcenter_search_articles for that)'). It also prescribes the two-step read pattern (list without bodies, then get_article), which is the key routing decision here.

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