Skip to main content
Glama

Extract claims

extract_claims
Read-onlyIdempotent

Split a text (for example an AI-generated answer) into atomic factual claims. Each claim includes span, grounding_required, claim_type (number|date|quantity|quote|named_entity_fact|comparison|opinion|prediction|other), check_worthiness (high|medium|low), and the source sentence. Hedges are stripped, pronouns are resolved across sentences, and compound sentences are split. Questions, greetings, opinions and predictions are marked grounding_required false. Use before verify_claim. Price: $0.05 USDC on Base per call via x402; this MCP call returns payment instructions and POST /v1/extract_claims returns the claims. Read-only.

Input Schema

NameRequiredDescriptionDefault
textYesThe text to split into claims, for example a chatbot answer. Up to a few thousand characters.

Output Schema

NameRequiredDescriptionDefault
toolYesTool name.
resultNoPaid result: { claims: [{ claim_id, text, span, grounding_required, claim_type, check_worthiness, sentence, sentence_index, next_step? }], recommended_next_steps, summary, priced_usd }.
statusYespayment_required: pay the HTTP route with x402 to get the result. ok: result is included.
messageYesHuman-readable summary.
paymentNoPayment instructions. MCP tools/call does not charge or run the paid work; call the HTTP route with x402.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedOutput schema / properties / result / description
      Previous value: -"Paid result: { claims: [{ claim_id, text, span, grounding_required, claim_type, check_worthiness, sentence, sentence_index }], summary, priced_usd }."New value: +"Paid result: { claims: [{ claim_id, text, span, grounding_required, claim_type, check_worthiness, sentence, sentence_index, next_step? }], recommended_next_steps, summary, priced_usd }."
    • addedOutput schema / properties / result / properties / claims / items / properties
      Added value: +{
      +  "next_step": {
      +    "description": "1.4.8: present only on unsure, low-confidence or unverified high-worthiness claims. A ready-to-send Deep verify request for this claim (optional, paid separately).",
      +    "properties": {
      +      "body": {
      +        "properties": {
      +          "claim": {
      +            "properties": {
      +              "text": {
      +                "type": "string"
      +              }
      +            },
      +            "required": [
      +              "text"
      +            ],
      +            "type": "object"
      +          }
      +        },
      +        "required": [
      +          "claim"
      +        ],
      +        "type": "object"
      +      },
      +      "endpoint": {
      +        "format": "uri",
      +        "type": "string"
      +      },
      +      "method": {
      +        "const": "POST",
      +        "type": "string"
      +      },
      +      "price_usd": {
      +        "type": "number"
      +      },
      +      "tool": {
      +        "const": "deep_verify",
      +        "type": "string"
      +      },
      +      "why": {
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "tool",
      +      "why",
      +      "price_usd",
      +      "endpoint",
      +      "method",
      +      "body"
      +    ],
      +    "type": "object"
      +  }
      +}
    • addedOutput schema / properties / result / properties / recommended_next_steps
      Added value: +{
      +  "description": "1.4.8: summary of claim-level next_step suggestions.",
      +  "properties": {
      +    "count": {
      +      "minimum": 0,
      +      "type": "integer"
      +    },
      +    "endpoint": {
      +      "format": "uri",
      +      "type": "string"
      +    },
      +    "note": {
      +      "type": "string"
      +    },
      +    "tool": {
      +      "type": "string"
      +    },
      +    "total_price_usd": {
      +      "type": "number"
      +    }
      +  },
      +  "required": [
      +    "tool",
      +    "count",
      +    "total_price_usd"
      +  ],
      +  "type": "object"
      +}
  2. Changed2 schema fields changed
    • changedOutput schema / properties / result / description
      Previous value: -"Paid result: { claims: [{ claim_id, text, span: { start, end }, grounding_required }], priced_usd }."New value: +"Paid result: { claims: [{ claim_id, text, span, grounding_required, claim_type, check_worthiness, sentence, sentence_index }], summary, priced_usd }."
    • addedOutput schema / properties / result / properties / summary
      Added value: +{
      +  "type": "object"
      +}
  3. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), and the description goes well beyond them: hedges stripped, pronouns resolved across sentences, compound sentences split, and specific classes (questions, greetings, opinions, predictions) marked grounding_required false. It also discloses the paid flow ($0.05 USDC on Base via x402, MCP call returns payment instructions while POST /v1/extract_claims returns claims) — material behavior an agent cannot infer.

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?

Information-dense and front-loaded: purpose and output shape come first, behavioral transformations next, routing last. The pricing glossary ('MCP call returns payment instructions and POST /v1/extract_claims returns the claims') is a slightly dense clause, but every sentence carries operational value.

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?

Covers input, the paid invocation protocol (critical, since a naive call only yields payment instructions), and the pipeline relationship. An output schema exists, so explaining return values is optional, and the description still summarizes them without bloating the definition. Nothing needed to call this correctly is missing.

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?

Schema description coverage is 100% for the single 'text' parameter, so the schema already carries the input semantics; the description's mention of an AI-generated answer and character limits largely duplicates it. The extra detail provided describes the output fields (span, claim_type, check_worthiness) rather than the input, so the baseline 3 applies.

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?

States a specific verb+resource ('Split a text into atomic factual claims') and immediately qualifies the scope with 'atomic factual claims' rather than generic extraction. The sequencing note 'Use before verify_claim' positions it relative to the sibling pipeline, so an agent can place it without opening another schema.

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

Usage Guidelines4/5

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

Explicitly says 'Use before verify_claim,' which tells the agent where this fits in the workflow, and names the input type ('for example an AI-generated answer'). It does not state exclusions or when to route elsewhere (e.g. vs deep_verify), so it stops short of a full when/when-not treatment.

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.