Skip to main content
Glama

devtune_get_accuracy

Read-onlyIdempotent

Read Accuracy over 30 or 90 days: how many claims AI answers made about the product were checked against its own site, and how each came out. totals counts facts (claims checked) by outcome: match, contradict (the answer disagrees with the site), site_conflict (the site disagrees with itself), not_on_site (the site does not say), stale, unjudged and dismissed; match_rate is null when nothing was judged. totals.contradict counts contradicted claim groups (distinct AI wordings); contradiction_rows counts the site sentences they contradict, as devtune_list_accuracy_contradictions lists them, and prior_contradiction_rows the same count for the previous window when it compares. unquoted_contradictions counts contradictions whose claim quotes no sentence of the site, which no contradiction row lists. prior_status says whether the previous window of the same length (prior_window) compares: when it is comparable, prior_totals holds its totals, so report the change; when it is incomplete or method_changed, prior_totals is null and no change should be stated. method_changed includes different question or sampling versions, or mixed sampling within either window; sampling_versions lists 1 for one answer per prompt/platform/week and 2 for up to three. weekly gives the trend by Monday-UTC week and platforms the per-platform split, where a claim seen on several platforms counts on each. coverage counts the answers eligible, sampled, checked, with no claims, failed and pending; when facts is zero, pending answers mean the checks have not finished, not that the answers were accurate. series_started_on is null until the first answer is sampled.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
intentNo
windowNo
platformNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

B3.3/5.0
Behavior4/5

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

Annotations already cover safety (readOnly/idempotent/non-destructive), but the description adds real behavioral context: null semantics (match_rate null when nothing judged, prior_totals null when incomparable), the method_changed/prior_status comparison gate, and the pending-answers trap when facts is zero. This is well beyond what the annotations provide.

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 first sentence front-loads the purpose well, but the remainder is one massive run-on paragraph blending field semantics into a single blob with no separation. Given no output schema the content is relevant, but the structure makes it hard to parse.

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?

With no output schema and high domain complexity, the description carries the return-value burden thoroughly: totals breakdown, prior-window comparison rules, weekly trend, per-platform split, coverage states, and series_started_on. Only the intent/platform filter parameters are left unexplained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must carry parameter meaning, yet it never mentions the intent parameter at all and only loosely implies window (30/90 days) and platform (per-platform split, not as a filter). Two of three parameters are effectively undocumented.

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+resource: reading Accuracy (claims checked against the product's own site) over 30 or 90 days, with aggregate totals and rates. It is distinguishable from the singular devtune_get_accuracy_claim and devtune_list_accuracy_contradictions siblings, though it never explicitly contrasts itself with them.

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 rather than stated: the tool is for aggregate accuracy reporting over a window and it names devtune_list_accuracy_contradictions as the source of individual rows. There is no explicit when-to-use-this vs. the claim/contradiction-level siblings, so the agent must infer the selection rule.

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