Skip to main content
Glama

HelpCenter.io for agents

Search HelpCenter Articles

helpcenter_search_articles
Read-onlyIdempotent

Full-text search a HelpCenter.io help center's articles by query string, returning ranked matches.

This performs keyword search (Meilisearch-backed) over published article titles and content for the connected help center. Use it to answer "find the article about X" intents. It is read-only and does not modify anything. For browsing by category rather than searching, use helpcenter_list_articles.

Args:

  • query (string, required): search text matched against titles and content.

  • lang (string, optional): language code to search within (defaults to the site default).

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

  • include_content (boolean, optional): default false, so each match comes back WITHOUT its body (the fields are listed under helpcenter_list_articles). Read the matches you need with helpcenter_get_article. true adds every language's full body.

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

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

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

Returns: a payload with { total, count, page, per_page, total_pages, has_more, next, items }, ranked best match first. Each item is an article without its body (see include_content), or with include_content: true the full article (id, per-language title/slug/content, category_id, categories, type, published, visibility, views, ratings, timestamps).

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.

To answer a question from the help center, search, then read the best one to three matches with helpcenter_get_article.

Errors: returns an auth error if the key is missing/invalid; a validation error if category_id is not a category of this site.

Input Schema

NameRequiredDescriptionDefault
langNoLanguage code to search within (defaults to the site's default language).
pageNoPage number for pagination (default 1).
limitNoMaximum items to return per page (1-100, default 100).
queryYesFull-text search string matched against article titles and content.
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.
category_idNoRestrict results to a single category id.
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?

Goes well past the annotations: it discloses the 25000-character and 5.0 MB response caps, that overflowing pages are truncated with a truncated flag, that bodies are cut to excerpts with content_truncated, and that include_content can make a page several megabytes. It also documents the two error classes (auth, invalid category_id), none of which the readOnlyHint/idempotentHint annotations convey.

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-loads purpose and the sibling distinction, then sections Args/Returns/Paging/Errors so an agent can jump to what it needs. It is long, and the include_content and limit/page details duplicate the schema descriptions almost sentence for sentence, which is the main wasted space.

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 8-parameter open-world search tool with no output schema, the description supplies the full return payload shape ({ total, count, page, per_page, has_more, next, items }), the pagination contract via next, truncation semantics, and error behavior. Nothing essential to calling it 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 decision-relevant meaning: why include_content defaults to false (bodies excluded, read via helpcenter_get_article), that limit is capped at 100, and that lang falls back to the site default. It largely restates the include_content schema text rather than extending it, which keeps this below 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 (full-text search of help center articles by query string), names the ranking/backend (Meilisearch over titles and content), and explicitly distinguishes the intent from the sibling helpcenter_list_articles. An agent can pick between browsing and searching without opening either 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 the selecting condition verbatim ('find the article about X' intents), names the alternative for browsing by category, and prescribes the follow-up workflow: search, then read the best one to three matches with helpcenter_get_article. Exclusions and next steps are both explicit.

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