Skip to main content
Glama

Invokely official statistics

Check a claim

check_claim
Read-onlyIdempotent

Check stated figures against the official source: one claim or a batch of up to 20. Use it to fact-check a draft or an article. One call is metered per 5 claims; claims that come back unverifiable are not charged. You extract each claim into fields; the server does not read sentences. Take the number exactly as written and its scale word separately. Pass period only when the claim names one. Pick the indicator id with search_indicators when unsure (for Spanish municipalities use registered_unemployment_rate). Examples: "Spain's unemployment rate fell to 10.5% in the second quarter of 2026" -> {"claims": [{"indicator": "unemployment_rate", "place": "Spain", "period": "2026-Q2", "value": 10.5, "unit_hint": "percent"}]} "Texas has more than 31 million people" -> {"claims": [{"indicator": "population", "place": "Texas", "value": 31, "unit_hint": "millions", "qualifier": "at_least"}]} "US inflation was 3.2% in August 2026" -> {"claims": [{"indicator": "cpi_annual_change", "place": "United States", "period": "2026-08", "value": 3.2, "unit_hint": "percent"}]} "Spain has the third highest unemployment rate in the EU" -> {"claims": [{"indicator": "unemployment_rate", "place": "Spain", "value": 3, "kind": "rank", "rank_within": "EU"}]} Precision: a claim is read with the precision it states. "3.4%" covers 3.35 to 3.45 and "31 million" 30.5 to 31.5 million, both ends included; when the publisher states fewer decimals than the claim, the publisher's precision is used. Trailing zeros of a whole number are read as rounding to its last non-zero digit, keeping two significant digits: 1200 covers 1,150 to 1,250 and 2500000 covers 2,450,000 to 2,550,000, while 30 and 10 stay stated to the unit; qualifier exact turns this off. "about" doubles the band. at_least and at_most are inclusive bounds: "over 10%" holds for 10.0%. Verdicts: accurate (within that rounding); approximately_accurate (within 2% of the official value or twice the rounding band, whichever is wider, with the exact gap); inaccurate (with the official value and the gap); outdated (matches an earlier release that was revised, or an earlier period while a newer figure exists; outdated says which, and with as_of whether it was accurate when made); unverifiable (unknown indicator or place, ambiguous place, no data, or units that cannot be reconciled; error says why). Ranks are exact positions; a place tied with others holds every position the tie spans. Returns {results: [{index, claim, verdict, explanation, confidence: high | medium | low, notes?, official: {indicator, place, period, value, status?, source, transform?, inputs?, computed?, rank?}, comparison: {claimed, official, difference, relative_difference_percent, rounding, approximate_band, claimed_range}, reading?, readings?, outdated?, vintage?, newer_period?, error?}], summary, metered_calls}. comparison.claimed is the claim in the official unit. When a claim can be read several ways (a year on a monthly series: its last month or its average; a city and its province of the same name; a percent change of a rate: points or relative), every plausible reading is tested, the best one is returned in reading and the others in readings, and confidence is lowered. Say which reading the verdict rests on. In your answer, quote the official figure with its period and cite official.source.citation or url. Mention status provisional, estimated or low_reliability. Do not call a claim false when the verdict is unverifiable or approximately_accurate. Pass citation_style for formatted references.

Input Schema

NameRequiredDescriptionDefault
claimsYes1 to 20 claims, each checked on its own.
citation_styleNoOptional. Adds official.source.citations in this style, or in all six with "all".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), yet the description adds real behavioral facts: metering ('one call per 5 claims'), that unverifiable claims are not charged, field-extraction semantics ('the server does not read sentences'), and precision-band rules. It does not, however, disclose rate limits or latency beyond metering.

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?

Front-loaded with purpose, then progressively expands into extraction, precision, verdicts, and return shape — a logical order. It is long, but most sentences carry non-obvious rules (rounding bands, reading selection); some precision detail and return-field enumeration is dense enough to risk obscuring the primary call instructions.

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 takes on the burden of documenting the return object (results, verdict, comparison, official, reading/readings, metered_calls) and the verdict taxonomy, and it does so thoroughly. Nothing an agent needs to call and interpret this tool correctly appears to be 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 description coverage is 100%, so the baseline is 3, but the worked examples map natural-language sentences to exact field shapes (value/unit_hint split, qualifier, kind=rank), which is meaning the schema alone doesn't convey. It does repeat some schema text (number-as-written, trailing zeros), diluting the marginal value slightly.

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?

Opens with a specific verb and resource: 'Check stated figures against the official source', and bounds the scope ('one claim or a batch of up to 20'). It distinguishes itself from siblings by naming search_indicators for indicator lookup and referencing get_value place formats, so an agent can place it in the toolset without reading other schemas.

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 states the use case ('fact-check a draft or an article') and routes the agent to search_indicators when the indicator id is uncertain, even noting the Spanish-municipality special case. The verdict semantics (e.g., don't call a claim false when unverifiable) further constrain correct usage.

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