Skip to main content
Glama

Get HelpCenter Analytics Summary

helpcenter_get_analytics_summary
Read-onlyIdempotent

Headline traffic, ratings and authoring activity for the connected HelpCenter.io help center, each compared against the equally-long window before it.

Read-only. This is the "how are we doing" and "what changed since last month" call.

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.

Args:

  • from (string, optional): YYYY-MM-DD start of the window.

  • to (string, optional): YYYY-MM-DD end, inclusive. Defaults to today.

  • lang (string, optional): restrict to one enabled language.

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

Returns: { range: { from, to, days }, summary: { traffic: { article_views, visitors, searches, article_views_per_visitor }, ratings: { total }, activity: {...}, totals: { published_articles } } }. Each traffic metric is { count, change_pct } where change_pct compares against the immediately preceding window of the same length.

summary.traffic.searches.count is the authoritative search volume — helpcenter_get_search_queries deliberately reports no totals of its own.

To act on what this shows: use helpcenter_get_search_queries to find what people cannot find, and helpcenter_get_content_performance to find which existing articles are failing.

Errors: 429 if the shared analytics rate limit is exceeded — stop, do not retry. 503 if the analytics backend is temporarily unavailable; that is not your request's fault and retrying immediately will not help.

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

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

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

Goes well beyond the readOnly/idempotent annotations: discloses the shared 6-requests-per-minute analytics budget, that figures are recomputed only daily so repeats return identical numbers at full cost, that the default window is served from a pre-computed cache, the 92-day maximum, and the meaning of 429 vs. 503 including the instruction not to back off. This is exactly the operational context annotations cannot express.

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/rate-limit, then defaults, then args and returns — a sensible order for an agent scanning for a go/no-go decision. Slightly padded by the Args list duplicating the schema and by a return-shape sketch that is somewhat verbose, but the emphasis on the rate-limit trap earns its 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?

Covers everything needed for a no-output-schema, 5-parameter read tool: return payload structure with change_pct semantics, the authoritative-search-volume note that resolves an ambiguity with a sibling tool, error behavior, cost model, and window limits. Nothing material is left for the agent to guess.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the Args block largely restates the schema descriptions for `from`, `to`, `lang`, and `response_format`, so little is added there. The one genuine addition is the 92-day maximum window, a constraint absent from the schema that prevents a refused request; `site_id` is left to the schema. Baseline 3 is appropriate.

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 (headline traffic, ratings, authoring activity for the connected help center) plus the comparison semantics (each metric vs. the equally-long preceding window). It also self-labels as the "how are we doing" / "what changed since last month" call, which distinguishes it from the sibling content-performance and search-query tools 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?

Explicitly says to leave `from`/`to` unset for general questions and that the default trailing-7-day window is the correct answer, and names the two alternatives (helpcenter_get_search_queries to find gaps, helpcenter_get_content_performance to find failing articles) with the condition that selects each. It also rules out polling/retrying, which is a usage constraint an agent would otherwise get wrong.

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