Skip to main content
Glama

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.

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": {
      "query": "<query>"
    },
    "name": "helpcenter_search_articles"
  }
}

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.
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.
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.5/5.0
Behavior4/5

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

Beyond the annotations (readOnly/idempotent/non-destructive), it discloses the Meilisearch-backed keyword matching, that only published titles/content are searched, the 25000-character and 5.0 MB response caps with truncation semantics, and the auth/validation error conditions. The only real gap is that it does not discuss ranking nuance or relevance scoring details, but the truncation and paging behavior — the risky parts — are covered thoroughly.

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?

Purpose and the sibling alternative are correctly front-loaded, and the sections are clearly delimited. However, the Args block duplicates eight parameters that the schema already documents at 100% coverage, and the paging paragraph runs long with repeated warnings about not computing page + 1 manually.

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 full burden of describing the return payload ({ total, count, page, per_page, total_pages, has_more, next, items }), the item shape with and without bodies, and pagination/truncation mechanics. For an 8-parameter search tool this is complete enough to call correctly without trial and error.

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; the description earns more by explaining the consequences of include_content ('every language's full body', pages cut to excerpts with content_truncated) and by tying page/limit together through the `next` cursor contract. The Args block mostly restates the schema, but the paging explanation adds meaning the schema cannot express.

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 a HelpCenter.io help center's articles by query string') plus the ranking behavior ('returning ranked matches'). It explicitly separates itself from the browse sibling: 'For browsing by category rather than searching, use helpcenter_list_articles.'

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?

Names the intent it serves ('find the article about X'), names the alternative for browsing, and prescribes a follow-up workflow: 'search, then read the best one to three matches with helpcenter_get_article.' It also tells the agent when include_content should be true ('an export, a backup or a content audit') versus the default.

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