Skip to main content
Glama

Verify Claims

infobroker_verify_claims

Verify high-stakes or contested claims against independent sources, returning confidence-scored findings that surface agreement, contradiction, gaps, and unverified claims for batch fact-checking.

Instructions

Verify one or more contested claims against independent sources and return confidence-scored findings. Use when a claim is high-stakes or contested and you need agreement, contradiction, and gaps surfaced with confidence scores, or when a finished draft needs a claim-by-claim fact-check in one call. Do NOT use for simple lookups or broad search (use infobroker_search_web) or citation formatting (use infobroker_get_citations). The loop recalls prior findings from the knowledge base, then searches providers and writes findings back; max_iterations bounds the refinement passes and per-provider rate limits apply, with one HTTP-call budget shared across a batch. Supply exactly one of query (one claim, or a string the server splits into up to five) or claims (a list of independent claims seeded verbatim); a batch returns one finding per distinct claim in caller order, identical claims are collapsed and report every input index they cover, and a claim with no attributed source is reported unverified rather than dropped. priority routes the pool by intent (speed, quality, privacy, free_only); providers restricts the pool and omitting it uses the full dispatch chain; confidence_threshold sets the bar for confirmation, and findings below it are reported unverified. Each source carries a span locating its supporting sentence and an advisory modality (asserted, reported, speculative) that never changes confidence. Returns an [OK] or [ERROR] envelope listing confirmed, contested, and unverified findings with per-source claims, spans, and confidence scores.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "infobroker_verify_claims"
  }
}

Input Schema

NameRequiredDescriptionDefault
queryNoOne claim to verify; the server splits it into up to five sub-claims. Supply either query or claims, not both
claimsNoIndependent claims to verify as a batch (bounded by corroboration.max_batch_claims, default 10); seeded verbatim and returned one finding per distinct claim in this order, with identical claims collapsed and every input index reported. Supply either query or claims, not both
priorityNoRoute the corroboration pool by intent
providersNoOptional array of provider slugs to limit the search to
max_iterationsNoMaximum search-refinement passes (1-10, default 5)
confidence_thresholdNoMinimum confidence to report a finding as confirmed (0-1, default 0.8)

Output Schema

NameRequiredDescriptionDefault
metaNo
errorNo
statusYes
noticesNo
resultsNo
providerYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv2026.10.30
    • addedInput schema / properties / claims
      Added value: +{
      +  "description": "Independent claims to verify as a batch (bounded by corroboration.max_batch_claims, default 10); seeded verbatim and returned one finding per distinct claim in this order, with identical claims collapsed and every input index reported. Supply either query or claims, not both",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • changedInput schema / properties / query / description
      Previous value: -"Search query"New value: +"One claim to verify; the server splits it into up to five sub-claims. Supply either query or claims, not both"
    • removedInput schema / required
      Removed value: -[
      -  "query"
      -]
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "http://json-schema.org/draft-07/schema#",
      +  "additionalProperties": {},
      +  "properties": {
      +    "error": {
      +      "additionalProperties": {},
      +      "properties": {
      +        "code": {
      +          "type": "string"
      +        },
      +        "message": {
      +          "type": "string"
      +        },
      +        "remediation": {
      +          "type": "string"
      +        }
      +      },
      +      "required": [
      +        "code",
      +        "message"
      +      ],
      +      "type": "object"
      +    },
      +    "meta": {
      +      "additionalProperties": {},
      +      "properties": {},
      +      "type": "object"
      +    },
      +    "notices": {
      +      "items": {
      +        "additionalProperties": {},
      +        "properties": {},
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "provider": {
      +      "type": "string"
      +    },
      +    "results": {
      +      "items": {
      +        "additionalProperties": {},
      +        "properties": {},
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "status": {
      +      "enum": [
      +        "ok",
      +        "error"
      +      ],
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "status",
      +    "provider"
      +  ],
      +  "type": "object"
      +}
  2. Addedv0.1.1

TDQS

A4.6/5.0
Behavior4/5

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

Goes well beyond the annotations: it discloses the recall-search-write loop into the knowledge base (consistent with readOnlyHint=false), per-provider rate limits, a shared HTTP-call budget across a batch, and max_iterations bounding refinement passes. It also warns that unsourced claims are reported unverified rather than dropped. It stops short of naming auth/permission requirements or cost implications of the shared budget.

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 and well-ordered: purpose, then when/when-not, then mechanics, then return envelope. It is dense and several clauses are run-on (the query/claims and batch-behavior sentence packs many rules), but nearly every sentence carries operative information rather than filler.

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 six-parameter, iterative, batch-capable tool with writes to the knowledge base, the description covers the loop, budgets, ordering, collapsing, threshold behavior, and the [OK]/[ERROR] envelope shape. With an output schema present it need not detail return fields, and nothing an agent needs to call it correctly appears 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 coverage is 100%, so baseline is 3, but the description still adds real semantics: the mutual exclusion of query/claims, the up-to-five sub-claim split, verbatim seeding with caller-order results and identical-claim collapsing reporting all input indices, priority routing intents, and providers omission defaulting to the full dispatch chain. It largely restates rather than extends the schema text for query/claims, which keeps it at 4 rather than 5.

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 and resource ('verify contested claims against independent sources') plus the return shape ('confidence-scored findings'). It explicitly contrasts itself with two named siblings, infobroker_search_web and infobroker_get_citations, so an agent can discriminate without opening any schema.

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?

Gives positive triggers (high-stakes or contested claims, or a finished draft needing a claim-by-claim check in one call) and negative triggers (simple lookups, broad search, citation formatting), each negative paired with the alternative tool to use instead.

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