Skip to main content
Glama

Get HelpCenter Content Performance

helpcenter_get_content_performance
Read-onlyIdempotent

Per-article views and ratings for the connected HelpCenter.io help center. This is the "which articles should I fix" call.

Read-only.

COST AND RATE LIMIT: this is an expensive query, and the three analytics tools share a limit of 6 requests per minute per API key — far below the other read tools. The underlying figures are recomputed only once a day, so asking again in a few seconds returns identical numbers at full cost. Read once, keep the answer, and do NOT poll or retry in a loop. If you are refused with a rate-limit error, stop rather than backing off and retrying.

Leave from/to unset unless the user asked about a specific period: the default window is the trailing 7 days, is served from a pre-computed cache rather than the warehouse, and is the right answer for a general question. Maximum window is 92 days; wider is refused.

IMPORTANT — an article that got NO views in the window has no row here at all. The pipeline records views, not their absence. So 'sort=views_asc' gives you the least-read of the articles that WERE read, not the ones nobody opened; to find those, call helpcenter_list_articles and subtract the ids this returns. The response carries excludes_never_viewed: true as a reminder.

Args:

  • sort ('views_desc' | 'views_asc' | 'rating_asc', optional): default 'views_desc'. Use 'rating_asc' for "what should I fix" — it puts the worst-rated first and breaks ties towards the most-read article, because a badly-rated page nobody visits matters less than one everybody lands on.

  • category_id (number, optional): restrict to one category belonging to this help center.

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

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

  • from / to / lang (optional): see above.

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

Returns: { range, excludes_never_viewed, articles: [{ article_id, title, slug, status, views_in_range, total_views, ratings: { love_pct, thumbs_up_pct, thumbs_down_pct }, updated_at, _links: { view } }], meta }.

Ratings are percentage SHARES of the feedback an article received, not counts — one thumbs-down reads as 100%. Weigh them against views_in_range before acting.

Having found a weak article, fix it with helpcenter_stage_article_changes (edit privately, then publish) or helpcenter_update_article (visible immediately).

Errors: 429 if the shared analytics rate limit is exceeded — stop, do not retry. 422 if category_id belongs to a different help center. 503 if the analytics backend is temporarily unavailable.

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

Input Schema

NameRequiredDescriptionDefault
toNoEnd of the reporting window, YYYY-MM-DD, inclusive. Defaults to today.
fromNoStart of the reporting window, YYYY-MM-DD. OMIT unless the user asked for a specific period — the default window is cheaper to serve and is the right answer for a general 'how are we doing' question.
langNoRestrict to one language code. Must be enabled on the help center. Costs more to serve than the unfiltered call, so only send it for a genuinely multilingual question.
pageNoPage number for pagination (default 1).
sortNo'views_desc' (default) most-read first; 'views_asc' least-read first; 'rating_asc' worst-rated first, ties broken towards the most-read article. Use 'rating_asc' for 'what should I fix'.
limitNoMaximum items to return per page (1-100, default 100).
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 to one category id belonging to this help center.
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 far beyond the readOnly/idempotent annotations: discloses a shared 6-requests-per-minute analytics limit, daily recomputation, a cheaper cache-served default window, a 92-day cap, and the critical semantic that never-viewed articles produce no row at all (with excludes_never_viewed as an in-response reminder). Error behavior (429 stop-don't-retry, 422 cross-help-center category, 503 backend down) is spelled out.

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 then cost, defaults, gotchas, args, return shape and errors — a sensible priority order. It is long and the args section duplicates some schema descriptions near-verbatim, so a small amount of text does not earn its place.

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 supplies the full response shape inline and warns that ratings are percentage shares rather than counts, which is essential to interpreting the numbers. For a 9-parameter analytics tool with a shared rate limit, nothing an agent needs to call and interpret it correctly is 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 baseline is 3; the description does add meaning the schema cannot, chiefly the tie-breaking rationale for 'rating_asc' and the interaction between 'views_asc' and the missing-row behavior, plus why lang costs more. Some of it (from/to omission, sort enum meanings) largely restates the schema's own parameter descriptions, 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?

Names the resource precisely ("per-article views and ratings for the connected HelpCenter.io help center") and frames the job with "which articles should I fix", which separates it from helpcenter_get_analytics_summary and helpcenter_get_search_queries without opening their schemas.

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 when-to-use rules (use 'rating_asc' for what-to-fix, leave from/to unset for a general question) plus when-not guidance (do not poll or retry, do not pass a wider than 92-day window) and names follow-up alternatives: helpcenter_list_articles to find never-viewed articles, helpcenter_stage_article_changes or helpcenter_update_article to fix a weak one.

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