Skip to main content
Glama

Extract atomic claims

extract_claims
Read-onlyIdempotent

PURPOSE: Split text into independently checkable ATOMIC factual claims — the cheap first step of a verification loop (extract -> ground -> attest). Returns {claims: [...], count, input_sha256} plus a signed receipt bound to the input hash. GUIDELINES: Call when you want to see WHICH claims a document makes before paying to ground them, to budget a verification pass (extract everything, then verify_claim only the claims that matter to your decision), or to prove later exactly which claims were pulled from exactly which text (the receipt binds both). Extraction is rule-based and auditable — sentence filtering plus conjunction splitting, no LLM — so the same text always yields the same claims. Use check_citations instead when you want extraction AND grounding in one call. PARAMETERS: text — the prose to decompose. max_claims — 1..50, default 20. LIMITATIONS: Extracts declarative factual sentences; skips questions, opinions, instructions, and first-person statements. Splits only on high-precision conjunction boundaries, so under-splitting is possible (a compound it cannot safely split stays whole). Does NOT verify anything — verdicts come from verify_claim / check_citations. Paid per call (x402), cheapest tool on this server. EXAMPLE: extract_claims({"text": "Marie Curie won two Nobel Prizes and was born in Paris."}) -> {count: 2, claims: ["Marie Curie won two Nobel Prizes", "was born in Paris."]}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textYesThe text to split into independently checkable atomic factual claims.
max_claimsNoMax claims to return (1-50).

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already mark readOnlyHint, idempotentHint, and destructiveHint:false, and the description adds valuable context beyond that: the tool is rule-based and auditable, deterministic ('same text always yields the same claims'), skips questions/opinions/instructions, may under-split, and does NOT verify. No contradiction with annotations; this is exemplary transparency.

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 long but uses clear section headers (PURPOSE, GUIDELINES, PARAMETERS, LIMITATIONS, EXAMPLE). Every section adds distinct value; it could be marginally tightened but is well-organized and not bloated.

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?

Given no output schema, the description covers the return shape ({claims, count, input_sha256} plus signed receipt), limitations, and pricing. It also clarifies the relationship to verify_claim and check_citations, making it complete for confident selection and invocation.

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 description need not add much. It restates text and max_claims, but the example ('extract_claims({"text": "Marie Curie..."}) -> {count: 2, ...}') clarifies parameter usage and return shape. The small push beyond schema baseline justifies a 4.

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 a specific verb+resource: 'Split text into independently checkable ATOMIC factual claims' and frames it as the first step of a verification loop. It clearly distinguishes from siblings by naming check_citations as the extract+ground alternative, so purpose is unmistakable.

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 when to use: 'Call when you want to see WHICH claims a document makes before paying to ground them...' and also when NOT to, pointing to check_citations for combined extraction+grounding. This is textbook usage guidance with alternatives named.

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.