Get Daily Traffic
get_timeseriesDaily traffic series for a site (visits, visitors, pageviews, clicks, bots per day, in the site's timezone).
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | ||
| days | No | ||
| from | No | ||
| site | Yes |
get_timeseriesDaily traffic series for a site (visits, visitors, pageviews, clicks, bots per day, in the site's timezone).
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | ||
| days | No | ||
| from | No | ||
| site | Yes |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already establishes safety, so the description only adds modest behavioral context: daily granularity, metric set, and interpretation in the site's timezone. It does not disclose defaults, date-range behavior, or what the returned series looks like, but there is no contradiction with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. The core action ('Daily traffic series') comes first, followed by a compact parenthetical listing metrics and the timezone behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no parameter descriptions, an agent needs at least the date-range semantics and the shape of the returned series to call this correctly. The description provides only the high-level metric list and time grain, leaving important invocation details unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description does not explain the date-range parameters (from, to, days) or their defaults. It only names the site and the metric set; an agent cannot infer parameter formats, optionality beyond the schema, or how days interacts with from/to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving a daily traffic series for a site and enumerates the metrics included (visits, visitors, pageviews, clicks, bots). It does not explicitly name a sibling for contrast, so it stops short of a 5, but it conveys the resource and the time grain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'daily traffic series' and 'per day' imply this is for daily aggregated traffic rather than real-time or breakdown views, and the site-timezone note narrows usage. However, there is no explicit guidance about when to prefer get_timeseries over get_stats, get_breakdown, or get_realtime, and no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.