DevDome Analytics

Get Site Stats

get_stats

Read-only

Headline KPIs for a site as raw counts: visits, visitors, pageviews, clicks (outbound), bots, bounces, session_seconds, dur_sessions, each for the current and the previous period. Derive the rates yourself the way the dashboard does: bounce rate = bounces / visits; average visit duration = session_seconds / visits (every visit counts, a bounce as 0 s); bounces are one-page visits without an outbound click; visitors are page loaders only, hop_only_visitors passed through a redirect link without loading a page; CTR (the dashboard's CTR/V1 tile) = (clicks - bot_clicks) / visits. Defaults to the full retained history. new_visitors is null (and returning_visitors 0) when the site's Cookieless tracking setting is on: the daily id cannot tell a return visit, do not report them. If new_visitors is almost equal to visitors, the tracker runs cookieless but the dashboard switch is off: tell the user to turn on Website Settings > Cookieless tracking for that site. visitors includes redirect-only hops, so it can exceed pageviews.

Input Schema

Name	Required	Description
`to`	No	YYYY-MM-DD
`days`	No	Window in days (omit for full history)
`from`	No	YYYY-MM-DD
`site`	Yes
`filters`	No	Narrow the report to the visits that match ALL of these (the dashboard's click-to-filter), inside the same window as the report. Omit for everything.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 21, 2026

addedInput schema / properties / filters

Added value: +{
+  "additionalProperties": false,
+  "description": "Narrow the report to the visits that match ALL of these (the dashboard's click-to-filter), inside the same window as the report. Omit for everything.",
+  "properties": {
+    "browser": {
+      "description": "Browser name as get_breakdown dimension=browsers lists it",
+      "type": "string"
+    },
+    "campaign": {
+      "description": "utm source|medium|campaign exactly as a get_breakdown dimension=campaigns row; an empty part matches any, e.g. newsletter||",
+      "type": "string"
+    },
+    "country": {
+      "description": "ISO 3166-1 alpha-2 code, e.g. US; several joined with |, e.g. US|DE",
+      "type": "string"
+    },
+    "device": {
+      "description": "Device class as get_breakdown dimension=devices lists it (desktop, mobile, tablet)",
+      "type": "string"
+    },
+    "event": {
+      "description": "Visits that fired this custom event name (get_events lists the names)",
+      "type": "string"
+    },
+    "goal": {
+      "description": "Visits that completed this saved goal, by the id get_goals returns",
+      "type": "string"
+    },
+    "os": {
+      "description": "Operating system as get_breakdown dimension=os lists it",
+      "type": "string"
+    },
+    "page": {
+      "description": "Visits that viewed this page path, e.g. /pricing",
+      "type": "string"
+    },
+    "referrer": {
+      "description": "Visits that arrived from this referrer host, e.g. google.com",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

First observedSep 5, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Beyond the read-only annotations, the description discloses important behavioral details: raw counts require the caller to derive rates, filters apply to visits matching all criteria within the same window, full history is the default, and cookieless tracking affects new_visitors/returning_visitors reporting. It also warns that visitors can exceed pageviews because redirect-only hops are included.

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 front-loaded with the main purpose and then spends its length on metric definitions and caveats that are necessary to interpret raw counts correctly. Despite being dense, every sentence contributes actionable meaning.

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?

With no output schema, the description carries the return-value burden and does so thoroughly by enumerating the KPIs, period comparison, and edge cases such as cookieless tracking and redirect-only visitors. It is complete for an agent to call and interpret the tool correctly.

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 already 80%, so the schema carries most parameter meaning. The description still adds useful semantics by explaining that filters narrow results to visits matching ALL criteria and by clarifying the full-history default when date parameters are omitted.

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 a specific resource and output type: headline KPIs as raw counts for a site, listing visits, visitors, pageviews, clicks, bots, bounces, and durations for current and previous periods. This clearly separates it from detailed breakdown or time-series tools, though it does not explicitly name sibling alternatives.

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

Usage Guidelines3/5

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

The intended use is implied by 'Headline KPIs' and the default to full retained history, but the description never explicitly says when to choose this over get_breakdown, get_timeseries, or get_visitors. It provides interpretation guidance rather than selection guidance.

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

All DevDome Analytics 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.

Resources

Need Help?