Skip to main content
Glama

Read a site's stats

analytics_stats
Read-onlyIdempotent

Visitors (counted per day), pageviews, visits, bounce rate, visit length, time on page and scroll depth, against the period before; by day (or by hour for one day); top, entry and exit pages; channels (search, social, AI assistants, email, paid...), sources, referrers and UTM campaigns; countries, devices, browsers, operating systems; custom events; goals with conversion rates and revenue; and Core Web Vitals. A visit keeps the source it came from on every page. filters narrow all of it. Free.

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": {
      "site": "<site>"
    },
    "name": "analytics_stats"
  }
}

Input Schema

NameRequiredDescriptionDefault
toNoWith period custom: the last day.
fromNoWith period custom: the first day, 2026-10-01.
siteYesThe site's domain (e.g. halversoncycle.example) or its site_id.
limitNo
periodNo30d
filtersNoNarrow the stats: page and entry_page ("/blog/*", * for any part), goal (a goal's name), event, channel (Direct, Organic search, Paid search, Organic social, Paid social, AI assistants, Email, Referral, Affiliates, Display, Paid other, Other campaigns), source ("Google", "Direct"), referrer, campaign, medium, term, content, country ("DE"), device (desktop, tablet, mobile), browser, os. Example: {"channel": "Organic search", "device": "mobile"}.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.4/5.0
Behavior4/5

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

Annotations already cover read-only/idempotent/closed-world safety, so the description earns credit for adding non-obvious behavior: results are compared 'against the period before', granularity is by day (hourly for a single day), and 'a visit keeps the source it came from on every page' discloses the attribution model. It still omits what the response looks like structurally and how `limit` truncates the top/entry/exit lists.

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?

The single sentence is front-loaded with the core metric list, but it sprawls into a semicolon-separated catalogue that is dense to parse. Much of the enumeration could be compressed without losing information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/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 usefully enumerates what comes back (metric groups, dimensions, goals/revenue, Core Web Vitals), which is the main completeness burden here. The remaining gap is the `limit` semantics for top/entry/exit lists and any hint about response shape or size.

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 67% and the schema itself documents site, from/to, period, and the rich filter vocabulary with an example. The description only adds the aggregate statement that 'filters narrow all of it' and the daily/hourly granularity hint; it says nothing about the undefined `limit` parameter's effect on which lists are capped.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the resource and enumerates the metrics returned (visitors, pageviews, bounce rate, channels, goals, Core Web Vitals), so an agent can tell this is a comprehensive site-analytics report. However, it never differentiates itself from close siblings like analytics_breakdown, analytics_web_vitals, analytics_heatmap, or analytics_paths, even though it overlaps with all of them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to use this tool versus analytics_breakdown, analytics_realtime, analytics_web_vitals, analytics_paths, or analytics_heatmap — all of which cover subsets of the metrics listed here. The only usage-adjacent remark is 'Free', which does not guide tool selection.

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