Skip to main content
Glama

Metis — Verify Claim

verify_claim

Check whether a claim's cited document, page, figures, and quoted text actually exist in the indexed corpus using deterministic rules only, with no model to hallucinate a verdict.

Instructions

Tier A — check a claim against the indexed corpus, deterministically.

Verifies what can be verified WITHOUT a model: that the cited document is
indexed, that the cited page exists, that the claim's figures appear on that
page, and that any quoted string is actually present. It cannot hallucinate a
verdict because it contains no model.

A `supported` verdict means the deterministic checks passed. It does NOT mean
the passage supports the claim — that is entailment (Tier C, Critic's job).
For a source that is not in the corpus, use `verify_doi` to establish whether
it exists at all.

Args:
    claim: The sentence or statement being checked.
    source: Cited document title or filename, as written in the answer.
    page: Cited page number; 0 or omitted searches the whole document.
    quote: An exact quotation to locate, if the claim contains one.
    record: Append the verdict to the citation ledger (default True).

Returns:
    The verdict, what was tested, and which figures (if any) were missing.

Input Schema

NameRequiredDescriptionDefault
pageNo
claimYes
quoteNo
recordNo
sourceNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.5

TDQS

A5/5.0
Behavior5/5

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

Without annotations, the description carries the full burden and does so well: it explains the deterministic/no-model behavior, clarifies that a supported verdict does not mean entailment, and discloses the ledger side effect via the record parameter. It also states what is tested and what the return contains.

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?

Front-loads the key distinction, then provides structured Args and Returns sections. Every sentence is useful, with no filler or repetition, and the tier/entailment distinction is clear.

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 the tool's complexity, lack of annotations, low schema coverage, and presence of an output schema, the description is complete: it covers purpose, boundaries, all parameters, side effects, and return semantics. An agent has enough information to select and invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the Args section fully documents all five parameters: claim, source, page (including 0/omitted behavior), quote, and record with its default. This adds substantial meaning beyond the bare schema.

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 a claim against the indexed corpus deterministically. It also clearly delineates scope by explaining what is checked and what is left to Tier C entailment, and distinguishes itself from verify_doi for sources outside the corpus.

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 says when to use this tool and when not to: deterministic checks only, not semantic entailment, and use verify_doi when the source is not in the corpus. The alternatives and boundary conditions are unambiguous.

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

Deploy Server

Other Tools