Skip to main content
Glama

StatCite — Verified Economic Statistics

by io.github.asokore

Verify a batch of claimed statistics (fact-check a whole draft)

verify_claims
Read-onlyIdempotent

Fact-check a whole draft or report in one call instead of calling verify_stat once per figure: extract every checkable macro claim from the text. Indicator + country + period + claimed value, and submit them together. Each claim gets the same verdict engine as verify_stat (match, close, mismatch, cannot_verify, with diagnostics), and every verified result carries the full citation for the official number. Same honesty contract as verify_stat: unverifiable claims come back cannot_verify with the reason, never a guessed verdict. Accepts 1–15 claims per call (free-tier subrequest budget). Split larger drafts into multiple calls of up to 15. Results come back in input order with a verdict-count summary; a claim that cannot be resolved (unknown indicator or country) reports its error in place without sinking the rest of the batch.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
claimsYesThe claims extracted from the draft, in the order they appear (max 15 per call).
strict_sourceNoReproducibility mode for the whole batch: never verify any claim against a fallback source, such claims error in place instead. Default false; without it, a claim served from a transient-failure fallback returns cannot_verify with the fallback value as indicative rather than a match/mismatch verdict.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultsYes
summaryYes

TDQS

A4.6/5.0
Behavior5/5

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

Discloses the honesty contract ('unverifiable claims come back cannot_verify with the reason, never a guessed verdict'), result ordering, and error isolation ('reports its error in place without sinking the rest of the batch'), which go beyond the readOnlyHint/idempotentHint annotations.

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 description is longer than necessary but well-structured, front-loading the purpose and then enumerating key behaviors. Every sentence conveys a distinct constraint or behavior, with no fluff.

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?

For a complex batch tool, it covers batching limits, error behavior, output ordering, citation, and honesty contract. The presence of an output schema means return-value details are not required, and the description covers the critical operational aspects.

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

Parameters3/5

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

The schema already covers all parameters with descriptions (100% coverage), and the description's mention of the claim fields ('Indicator + country + period + claimed value') is a summary rather than new semantics. It doesn't explain tolerance parameters, but they are in schema.

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?

Clearly states the tool's function: 'Fact-check a whole draft or report in one call' and distinguishes it from verify_stat by saying 'instead of calling verify_stat once per figure'. The verb is specific (fact-check) and the resource is a whole draft batch.

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

Usage Guidelines5/5

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

Explicitly instructs when to use: 'instead of calling verify_stat once per figure' and provides batch limits ('Accepts 1–15 claims per call... Split larger drafts into multiple calls'). Also clarifies the shared verdict engine with verify_stat.

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

All StatCite — Verified Economic Statistics toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation4/5

Tools are organized into clear functional groups (retrieval, search, verification, conversion), and pairs like get_indicator/get_series and verify_stat/verify_claims have explicit usage distinctions. The only minor overlap is between fetch and get_series, but their descriptions clarify when to use each.

Naming Consistency4/5

Most tool names follow a verb_noun snake_case pattern (get_indicator, verify_stat, compare_sources), with a few single-word or noun-style exceptions (fetch, search, country_snapshot). The overall convention is predictable and consistent.

Tool Count5/5

12 tools is within the optimal range for a domain of this complexity, covering retrieval, search, comparison, verification, conversion, and source listing without unnecessary bloat.

Completeness5/5

The surface covers the full workflow: discover indicators (search_indicators), search data (search), fetch data (get_indicator, get_series, fetch, country_snapshot), compare sources (compare_sources), convert values (fx_convert, inflation_adjust), verify claims (verify_stat, verify_claims), and understand sources (list_sources). No critical gaps are apparent.

Resources