Convika

Query traffic over time

query_timeseries

Read-onlyIdempotent

Daily pageviews and unique visitors for one landing page, optionally split by a dimension (device type, country, referrer, page path, UTM source/medium/campaign) and filtered to one device or country.

Use when the user asks how traffic moved day by day, or which device, country, or source drove a change. For a one-call overview use get_analytics_summary; for period-over-period comparison use get_analytics_detail. Each row has date, dimensionValue ("all" when no dimension is set), pageviews, and visitors. Visitors are unique per day, so don't add them up across days. Data covers the last 3 months and excludes known bots and vulnerability scanners, the same as get_analytics_summary. Scans count toward the monthly analytics scan quota and overage billing where applicable. Dates must be valid calendar dates in YYYY-MM-DD format, and startDate must be on or before endDate. Dates are days in the workspace's time zone, UTC when the workspace has none set, and startDate and endDate are whole days in the zone used. Pass timeZone, an IANA name such as America/New_York, for days in another zone; it changes only this response, never the workspace's time zone. The result's timeZone field names the zone used, and timeZoneSource says where it came from (argument, workspace, or default). A row for today's date in that zone counts only the hours so far. When timeZonePending is set, the workspace is switching to that zone once its history is recomputed. Supported filters are device (mobile, desktop, tablet) and country (two-letter code such as JP or US).

Combine results with detect_trend to confirm trends.

Examples:

Basic traffic: query_timeseries(siteId, "2026-09-01", "2026-09-28")
By device: query_timeseries(siteId, "2026-09-01", "2026-09-28", dimension="device")
By UTM source: query_timeseries(siteId, "2026-09-01", "2026-09-28", dimension="utm_source")
Mobile only: query_timeseries(siteId, "2026-09-01", "2026-09-28", filters={device:"mobile"})

Input Schema

Name	Required	Description
`limit`	No	Maximum rows to return. Defaults to 100, max 500.
`siteId`	Yes	The ID of the page to query
`endDate`	Yes	End date (YYYY-MM-DD)
`filters`	No	Optional filters to narrow results. Supported keys: device, country
`timeZone`	No	IANA time zone name for the days in this response, such as America/New_York, Europe/Berlin, or Asia/Tokyo. Leave it out for the workspace's time zone (UTC when none is set). It affects only this response: the workspace's time zone stays as it is, and only the workspace's owner changes it, in the dashboard's Settings. Abbreviations such as EST and offsets such as +09:00 aren't accepted.
`dimension`	No	Optional dimension to break down results by
`startDate`	Yes	Start date (YYYY-MM-DD)

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 2, 2026
- changedInput schema / properties / siteId / description
```
Previous value: -"The site ID to query"New value: +"The ID of the page to query"
```

Changed1 schema field changedOct 23, 2026

addedInput schema / properties / timeZone

Added value: +{
+  "description": "IANA time zone name for the days in this response, such as America/New_York, Europe/Berlin, or Asia/Tokyo. Leave it out for the workspace's time zone (UTC when none is set). It affects only this response: the workspace's time zone stays as it is, and only the workspace's owner changes it, in the dashboard's Settings. Abbreviations such as EST and offsets such as +09:00 aren't accepted.",
+  "maxLength": 64,
+  "type": "string"
+}

First observedOct 18, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description layers on genuine behavioral context: 3-month data window, bot/scanner exclusion, scan-quota and overage billing, visitors being non-additive across days, partial rows for today, and timeZonePending transitions. These are exactly the constraints an agent cannot get from 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.

Conciseness4/5

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

Purpose and sibling routing are front-loaded, and the return-row shape and examples are well ordered. The timezone paragraph is long and packs several edge cases (timeZoneSource, timeZonePending, partial today) that could be tightened, but each sentence still carries information.

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?

No output schema exists, and the description compensates fully by describing each returned row field (date, dimensionValue, pageviews, visitors), the non-additive visitors caveat, and the timeZone/timeZoneSource/timeZonePending response fields. An agent has everything needed to call and interpret the tool.

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 the baseline is 3; the description earns above baseline by enumerating device values (mobile, desktop, tablet) and country codes (JP, US) that the schema does not list, explaining the 'all' dimensionValue, and detailing whole-day/timezone semantics for startDate and endDate. The limit parameter is left entirely to the schema, which keeps it from 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?

States a specific verb and resource (daily pageviews and unique visitors for one landing page) plus the exact optional dimensions and filters. It explicitly names the sibling tools it is not (get_analytics_summary, get_analytics_detail) and the distinction is clear without opening a schema.

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 triggers ('how traffic moved day by day', 'which device, country, or source drove a change'), names the alternatives for overview and period-over-period comparison, and closes with four concrete invocation examples. Nothing about tool selection is left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Convika tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Query traffic over time

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources