Quattr

ai_tracker_health

Read-only

PREFLIGHT for AI-visibility analyses: is this tracker's data complete enough to interpret? Per answer-engine platform: observed collected-prompt count for the period, latest data date, and a structural state (ready / partial / unavailable). Pass comparison_range to also get prompt-basket deltas between periods (a shrinking or grown basket means period-over-period reads need a rebaseline caveat). Run this BEFORE interpreting AI-visibility performance — a tracking gap is not a performance gap. Also reports trackerStatus: a PAUSED tracker stopped collecting on its end date, so anything after it is a tracking gap and its numbers are historical, not current. Counts are OBSERVED collection, not the configured basket.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "tracker": "<tracker>",
      "date_range": "<date_range>"
    },
    "name": "ai_tracker_health"
  }
}

Input Schema

Name	Required	Description
`tracker`	Yes	AI-visibility tracker id (e.g. "AI Tracker"), or a raw market-share segment id.
`date_range`	Yes	Explicit date range, e.g. "2026-05-01 to 2026-05-31". Both endpoints are INCLUSIVE — the END day is covered (a 7-day range = 7 days). Quattr weeks run Sunday–Saturday; for "last week" use the most recent complete Sun–Sat span.
`comparison_range`	No	Prior period for basket-change deltas, e.g. "2026-05-01 to 2026-05-31".

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 19, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare a safe read-only profile, but the description adds substantial semantics: PAUSED trackers stop collecting on their end date, so post-end-date numbers are historical rather than current, and counts are OBSERVED collection rather than the configured basket. These are non-obvious behavioral caveats an agent could not infer from annotations or schema.

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?

The core purpose is front-loaded in the first clause, and each sentence carries distinct information (states, comparison semantics, trackerStatus, observed-vs-configured). It is dense and slightly long, but little of it is wasted.

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 fully: observed prompt counts, latest data date, structural state (ready/partial/unavailable), optional basket deltas, and trackerStatus. Nothing an agent needs to call and correctly interpret this tool is missing.

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, but the description adds meaning beyond the schema by explaining that comparison_range yields prompt-basket deltas and that a shrinking/grown basket implies a rebaseline caveat. It also reinforces that the reported counts are observed, not configured.

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 ('PREFLIGHT for AI-visibility analyses: is this tracker's data complete enough to interpret?') and frames the tool as a completeness gate, which clearly distinguishes it from the many ai_visibility_* performance siblings. An agent can tell immediately this is a pre-check, not an interpretation tool.

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

Usage Guidelines4/5

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

Gives explicit sequencing guidance ('Run this BEFORE interpreting AI-visibility performance — a tracking gap is not a performance gap') and explains when to add comparison_range. It does not name the specific downstream siblings to call afterward, so it stops short of full when/when-not/alternatives routing.

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

All Quattr 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?