Skip to main content
Glama

Fact-check a whole draft

check_citations
Read-onlyIdempotent

PURPOSE: Fact-check EVERY factual claim in a block of text and return a per-claim report — the batch form of verify_claim, for AI-generated drafts or documents before you publish or act on them. GUIDELINES: Call on any multi-claim text you are about to rely on. Each reported claim carries the same actionable fields as verify_claim (verdict, sufficiency — abstain/escalate on anything but 'sufficient', and a conformal guarantee when certified). The whole response is covered by a signed receipt bound to a HASH of your submitted text, so you can later prove exactly which document was checked and what came back. Use verify_claim instead for a single claim. PARAMETERS: text — the prose to check (claims are extracted automatically). max_claims — 1..20, default 8 (caps how many extracted claims are verified). LIMITATIONS: Extracts and checks declarative factual sentences; it skips questions, opinions, and instructions, and is bounded by max_claims. Same source-coverage limits as verify_claim. Paid per call (x402): unpaid calls return HTTP 402 with a payment offer. EXAMPLE: check_citations({"text": "Paris is the capital of France. The Nile flows through Egypt.", "max_claims": 8})

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textYesThe prose whose factual claims should be extracted and checked.
max_claimsNoMax number of extracted claims to verify (1-20).

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnlyHint/openWorldHint/idempotentHint annotations, the description discloses substantial behavioral traits: claims are extracted automatically, questions/opinions/instructions are skipped, results are bounded by max_claims, source-coverage limits match verify_claim, payment is per-call, and a signed receipt is bound to a hash of the text. This is far more than 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.

Conciseness5/5

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

The description is organized into PURPOSE, GUIDELINES, PARAMETERS, LIMITATIONS, and EXAMPLE sections. Each section adds value, and the example is concise and illustrative. At roughly 150 words it is detailed yet not bloated, with the purpose front-loaded.

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?

Even without an output schema, the description covers return fields (verdict, sufficiency, conformal guarantee), signed receipt, limitations, payment behavior, and an example. Combined with rich annotations and a simple two-parameter schema, this is complete for an agent to select and invoke the tool correctly.

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 input schema already describes both parameters (text and max_claims) with full coverage. The description's PARAMETERS section mostly restates the schema, adding only that claims are extracted automatically and providing an example. This does not add significant new meaning beyond the schema, so the baseline score of 3 is appropriate.

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?

The description opens with 'Fact-check EVERY factual claim in a block of text and return a per-claim report' and explicitly calls it 'the batch form of verify_claim'. This clearly distinguishes it from sibling verify_claim (single claim) and states the specific resource (block of text).

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?

The GUIDELINES section explicitly states when to call the tool: 'on any multi-claim text you are about to rely on', and when to use the alternative: 'Use verify_claim instead for a single claim.' It also specifies the context of AI-generated drafts or documents before publishing or acting.

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.

TDQS

A4.7/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: claim verification (single vs batch), claim extraction, identifier resolution, and delivery attestation. The batch vs single claim tools are distinguished by input granularity, resolving any potential confusion.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern (attest_delivery, check_citations, extract_claims, resolve_instrument, verify_claim). This predictable convention makes the tool set easy to navigate.

Tool Count5/5

Five tools is well-scoped for a verification/attestation service. Each tool covers a distinct stage (extract, verify, attest, resolve) without redundancy or bloat.

Completeness5/5

The tool set provides complete coverage of the verification workflow: extraction (extract_claims), single and batch verification (verify_claim, check_citations), identifier resolution (resolve_instrument), and delivery attestation (attest_delivery). Signed receipts enable offline verification, leaving no obvious gaps.