Skip to main content
Glama

pages.statistics

Get CDN traffic for one static website this Vee3 account hosts.

Returns request count, bandwidth, cache hit rate, and bandwidth by country for a UTC date range. Request count includes every file the CDN served, not unique visitors. The range is inclusive. When the user or agent omits dates, the last 7 UTC days including today are used. The range can be at most 31 days.

Cost = 10 tokens.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
date_toNoInclusive UTC end date (YYYY-MM-DD). Defaults to today UTC.
page_idYesPage id returned by pages.create.
date_fromNoInclusive UTC start date (YYYY-MM-DD). Defaults to 6 days before date_to.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
date_toNoInclusive UTC end date actually used (YYYY-MM-DD).
page_idNoUnique identifier for the page.
date_fromNoInclusive UTC start date actually used (YYYY-MM-DD).
request_countNoCDN requests served in the range, including HTML, CSS, images, and other files. Not unique visitors.
cache_hit_rateNoFraction of requests served from cache, from 0 to 1.
bandwidth_bytesNoTotal bytes the CDN served in the range.
traffic_by_countryNoBandwidth by country code, largest first. Omits countries with no traffic.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Added

TDQS

A4.5/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses key behavioral details: request count counts files served, range is inclusive, defaults to the last 7 UTC days, max 31 days, and cost of 10 tokens. It doesn't explicitly state side effects or auth requirements, but 'Get' and the analytics context make the read-only nature clear.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact, front-loaded with the core purpose, then quickly lists return metrics, key caveats, default behavior, constraint, and cost. Every sentence contributes useful information with no fluff.

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?

The description is complete for a low-complexity read tool: purpose, metric semantics, date constraints, defaults, and cost are all covered, and an output schema exists to define the return structure. The schema separately documents that page_id comes from pages.create.

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 description coverage is 100% and each parameter has its own description, so the baseline is met. The description adds value by emphasizing that the range is inclusive and can be at most 31 days, and by clarifying the default date window in prose beyond what the schema states.

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?

The description uses a specific verb and resource: 'Get CDN traffic for one static website this Vee3 account hosts.' It clearly distinguishes this from sibling operations like pages.create, pages.deploy, and pages.get by naming exactly what the tool returns and on what scope.

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

Usage Guidelines4/5

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

The description clearly establishes the context: use this when you need CDN traffic metrics for a single static website on this account. It doesn't explicitly name alternatives or exclusions, but the narrow analytics scope makes it obvious this isn't for managing pages or domains.

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.

TDQS

A4.1/5.0
Disambiguation5/5

Each tool has a distinct purpose, further clarified by group prefixes and clear descriptions. Within each group, tools perform different operations (e.g., domains.lookup vs. domains.whois vs. domains.rdap) with no ambiguity.

Naming Consistency5/5

All tools follow a consistent group.tool_name pattern using snake_case. The naming is predictable and uniformly applied across all groups.

Tool Count4/5

78 tools is high, but the server aggregates multiple distinct API domains (11 groups). Each group has a reasonable number of tools, typically under 10, with TikTok having 17. The count reflects breadth, not bloat.

Completeness5/5

Each domain's tool set covers the primary expected operations (e.g., search, details, reviews, metrics, user info). There are no obvious gaps for read-only analytical use; features like posting are likely out of scope.