Skip to main content
Glama
Sign In

DevTune MCP

by ai.devtune
OverviewDiscussionsAdmin

devtune_get_traffic_platforms

Read-onlyIdempotent

Get LLM traffic grouped by AI platform, traffic type and bot class over a fixed rolling window, so a platform's training crawls and answer fetches are separate rows. verifiedEvents confirms the claimed operator by peer address or Web Bot Auth signature; verifiedBySignatureEvents is the part of verifiedEvents a signature verified, and null when the method was not recorded for some verified events in the window (events stored before DevTune began recording it have none); failedEvents contradicts the claimed operator; unknownNoAddressEvents means the sensor supplied no address; unknownNoContractEvents means the operator publishes no supported identity-checking contract; unknownCheckUnavailableEvents means a published check could not complete. The before-verification remainder is totalEvents minus those five counts. actingAgents counts page requests from third-party agents acting on the site for a person (booking, comparing, filling in forms), with current and prior-window totals, current verified and failed counts, and a per-platform split; these are never counted as crawls or answer fetches, and actingAgents is omitted when it could not be read. Only agents that identify themselves are counted, so each count is a minimum; null means unmeasured: a zero needs edge middleware or Cloudflare covering the whole site for the whole period. With a domain filter, a period with no acting-agent requests is null, because coverage is recorded per site, not per host.

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_platforms"
  }
}

Input Schema

NameRequiredDescriptionDefault
domainNoFilter by specific domain.
windowDaysNoRolling window in days: 30 or 90. Defaults to 30.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds substantial context beyond that: null means unmeasured, zero requires full-site edge/Cloudflare coverage, counts are minimums because only self-identifying agents are counted, and actingAgents is omitted when unreadable. It does not discuss response shape/pagination or rate/performance traits, keeping it from a 5.

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

Conciseness3/5

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

Purpose is front-loaded, but the remainder is a single dense run-on paragraph of semicolon-joined field definitions with no bullets or grouping. Most content earns its place given the absent output schema, yet the wall-of-text formatting makes it harder to parse than necessary.

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 and a complex analytics payload, the description carries the full burden and succeeds: it defines every verification bucket, the remainder calculation (totalEvents minus five counts), actingAgents contents and omission behavior, and the null/coverage semantics. An agent can interpret the result correctly without additional documentation.

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 windowDays enum/default is already documented and the baseline is 3. The description adds genuine meaning the schema lacks: domain-filtered results return null for a period with no acting-agent requests because coverage is recorded per site, not per host. That is real semantic value for the domain parameter.

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?

States a specific verb and resource (get LLM traffic) plus the exact grouping dimensions (AI platform, traffic type, bot class) and the rolling window. The clause about training crawls and answer fetches being separate rows clarifies what distinguishes the output from a flat summary, though it never names the sibling it replaces (e.g. devtune_get_traffic_summary).

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?

Usage is implied: call it when you need traffic broken down by platform and bot class. There is no explicit when-to-use/when-not framing, no prerequisites, and no named alternative among the many traffic siblings (summary, referrals, answer fetches). The domain-filter caveat is the closest thing to conditional guidance.

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

All DevTune MCP toolsInspect
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