Skip to main content
Glama

devtune_get_traffic_summary

Read-onlyIdempotent

Get fixed-window website traffic totals, daily counts, LLM bot and AI-referral counts, coding-agent answer fetches and sensor state. Counts are null on UTC days without machine-sensor coverage, and window totals are null only when no day was covered. Otherwise totals sum covered days; a covered day with no events is 0. coverage.coveredDays gives measured days per event or session count over coverage.windowDays, and follows domain and path filters. Empty bot counts and combined event and session counts need server-side coverage from edge middleware, Cloudflare or a Vercel log drain. Observed bot rows retain their counts even when sensor state is unknown; with no server-side coverage or observed bot rows, combined counts are null. Referrals retain snippet coverage. Null coverage means coverage could not be read. sensors reports configuration-backed accepted-measurement Active state for snippet, edge middleware, Cloudflare, Search Console, GA4, and PostHog. Sensor state is project-wide even when domain filters the traffic totals. edgeSensorSdk lists the @devtune/ai-traffic versions the edge middleware reported in the last 14 days (null means 0.8.0 or earlier) and whether an upgrade is available; it is null when the reports could not be read. edgeSensorVercelLinks lists the Vercel projects linked to send edge middleware traffic without an ingest key: each has vercelProjectId, vercelOwnerId, the vercelOwnerSlug and vercelProjectName display names, the allowed environments, and lastSeenAt, where null names and a null lastSeenAt mean no traffic has been accepted from that link yet. The field is absent when the links could not be read. vercelDrain, absent only when the drain state could not be read, has connection: null when the project has no drain, or its status (pending, active, errored or needs_reconnect), vercelTeamId, vercelProjectIds, lastReceivedAt, lastError, the latest hourly health read from Vercel, behindCdn (true when requests arrived from a Cloudflare or Fastly address in the last 7 days, so they are not address-verified), addressesHidden (true when requests are arriving without client IP addresses because the Vercel team has IP Address Visibility › Show in Log Drains off, so they cannot be verified), and hosts, each with the one source counting it: vercel_drain, edge_middleware or cloudflare. pendingRemovals counts Vercel drains DevTune is still trying to delete for the project. abandonedRemovals lists drains DevTune gave up deleting (Vercel rejected the token, or a week of attempts failed), each with drainId, vercelTeamId and abandonedAt: the drain may still exist in Vercel and must be deleted there by hand. provenance, when present with state unavailable, means DevTune could not check whether some counts come from a source that cannot verify requests, so some counts may be unverified. codingAgents counts answer fetches by Aider, Claude Code, Crush, Gemini CLI, OpenCode and Qwen Code per agent and platform since countedFrom, beside answerFetches, the parent total read with them; compare with that, not botEvents. codingAgents.coverage partial means unattributedAnswerFetches answer fetches in the span could not be attributed, for example Cloudflare pulls; state not_yet_observed means none recorded yet.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "devtune_get_traffic_summary"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.6/5.0
Behavior5/5

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

Beyond the read-only annotations, the description thoroughly discloses null semantics, coverage behavior, sensor state meaning, edge SDK reporting, Vercel drain states, abandoned removals, provenance caveats, and coding-agent attribution limits. These are exactly the behavioral details an agent would otherwise lack. It does not contradict the read-only annotations.

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

Conciseness2/5

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

The description is a single extremely dense paragraph that mixes purpose, output-field semantics, null rules, sensor states, Vercel drain details, and edge-case caveats without headings or bullets. The first sentence is front-loaded, but the remaining text is difficult to scan and uses many sentences on advanced fields such as pendingRemovals and abandonedRemovals. It is thorough but not concise.

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?

There is no output schema, so the description carries the burden of explaining return data. It does this extensively for nulls, coverage, sensors, edge middleware, Vercel drains, provenance, and coding-agent counts. However, it lacks clear usage context and structural grouping, and the window size behind 'fixed-window' is not specified.

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?

The tool has zero parameters, so there is no parameter schema for the description to enrich. Under the stated rubric, a zero-parameter tool receives a baseline of 4 when the description adds no contradictory or misleading parameter information. The description does not discuss parameters, which is appropriate here.

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 opening states a specific verb and resource: 'Get fixed-window website traffic totals, daily counts, LLM bot and AI-referral counts, coding-agent answer fetches and sensor state.' That is clear enough to understand what is returned. It does not explicitly distinguish this tool from related siblings such as devtune_get_traffic_platforms or devtune_get_ai_referrals, so it stops short of a 5.

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?

The description explains data semantics but gives no explicit when-to-use guidance. It does not say when to choose this summary over devtune_get_traffic_platforms, devtune_get_ai_referrals, or devtune_get_visits_per_answer_fetch. The isolated comparison note 'compare with that, not botEvents' is field-level guidance rather than tool-selection guidance.

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