Skip to main content
Glama

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.

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

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.
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.
order_byNoSort field. Only 'views' is supported; omit for default (recently updated).
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 declare readOnly/idempotent/non-destructive, and the description adds substantive behavior beyond them: default response omits bodies and lists the exact fields returned, page-size caps (25000 chars / 5.0 MB), truncation behavior with `truncated: true`, and body-excerpt cut-before-withhold ordering. It also documents auth and validation error conditions, which the annotations say nothing about.

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 distinction, then cleanly sectioned into Args/Returns/Paging/Errors. The Args section restates the schema descriptions nearly verbatim, which is the main waste; the Paging paragraph is long but each sentence prevents a real mistake (computing page+1, skipping truncated items).

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 an 11-parameter list tool with no output schema, the description supplies the return envelope shape, item fields with and without content, the pagination contract via `next`, truncation semantics, and error cases. Nothing an agent needs in order to call it and page it correctly appears to be missing.

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 Args block is largely redundant with the schema. It still adds genuine meaning: how to drive updated_since for an incremental sync (pass newest updated_at, bound is inclusive, de-duplicate by id), and that include_content=false is the intended inventory pass before fetching bodies. The `next`-over-page+1 guidance is a real semantic addition to page/limit.

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+resource ("List and browse ... articles") and immediately states the distinguishing filter axes. It explicitly contrasts itself with helpcenter_search_articles (text search) and helpcenter_get_article (full body), so an agent can route correctly without opening a 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 concrete use cases ("what's in category Y", "most-viewed articles", audit/backup/incremental sync) and an explicit non-use case with the named alternative: "rather than to search for specific text (use helpcenter_search_articles for that)". The include_content section further routes to helpcenter_get_article for individual full bodies.

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