Skip to main content
Glama

Verify claims against the corpus

verify_claims
Read-only

Fact-check 1 to 25 natural-language claims against Lune's peer-reviewed corpus in ONE call. For each claim the server retrieves the most relevant passages and an LLM judges the claim ONLY against those passages (never outside knowledge), returning one verdict per claim: supported, unsupported, or insufficient_evidence. Use this to ground a draft before you assert it, to vet a user's claim, or to check your own answer against the literature. Every verdict carries a verbatim_quote copied EXACTLY from a retrieved passage (or null when nothing could be quoted, e.g. an insufficient_evidence verdict) plus supporting_paper_ids (the corpus papers the verdict relied on); both are verified server-side, the quote is guaranteed to be a real substring of a retrieved passage and the ids are guaranteed to be real retrieved candidates, so you can cite the quote directly without re-checking. Also returns a confidence (0..1) and short reasoning per claim. Filters (conference, year, year_min, year_max, venues) scope the evidence search and are shared across every claim; context is optional shared framing for the judge. paper_ids are fetch handles for get_paper_fulltext, not for showing to the user, cite papers by title, authors, and venue.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "claims": "<claims>"
    },
    "name": "verify_claims"
  }
}

Input Schema

NameRequiredDescriptionDefault
yearNoRestrict the evidence search to a single publication year.
claimsYes1 to 25 natural-language factual claims to fact-check against the corpus in ONE call. Phrase each as a complete, self-contained assertion (e.g. "LoRA fine-tuning matches full fine-tuning on GLUE while training far fewer parameters"), not a keyword bag. Each claim is retrieved and judged independently, so you get one grounded verdict per claim.
venuesNoRestrict the evidence search to these conference short names (e.g. ["NeurIPS", "ICML"]). Shared across every claim.
contextNoOptional shared framing passed to the judge for every claim, e.g. the surrounding paragraph or the question the claims answer. Use it to disambiguate terse claims; it does not change what is retrieved.
year_maxNoRestrict the evidence search to this publication year or earlier. Shared across every claim.
year_minNoRestrict the evidence search to this publication year or later. Shared across every claim.
conferenceNoRestrict the evidence search to this conference short name, e.g. "CCS", "NeurIPS". Shared across every claim.

Output Schema

NameRequiredDescriptionDefault
verdictsYesOne grounded verdict per input claim, in input order.
claims_processedYesTotal claims judged; equals verdicts.length.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Annotations only declare readOnly/openWorld/non-destructive; the description adds substantial behavior beyond that: per-claim server-side retrieval, judging restricted to retrieved passages ('never outside knowledge'), a null-quote case, and the guarantee that quotes are real substrings and paper ids are real retrieved candidates. It also warns that paper_ids are fetch handles for get_paper_fulltext rather than user-facing citations, which is exactly the kind of operational detail structured fields cannot carry.

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 with the core capability, then verdict semantics, then guarantees, then parameter notes — a sensible information order. It is a single dense paragraph with a few restated facts (claim count, verdict names) but almost no 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?

Though an output schema exists, the description still explains the key return fields and their trust guarantees, and it covers batch limits, shared-filter scoping, and citation etiquette. For a 7-parameter batch tool with an open-world corpus search, nothing an agent needs to call and cite it correctly is 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 parameters are already documented; the description still adds meaning by stressing that all filters are 'shared across every claim' and that context is optional shared framing for the judge that 'does not change what is retrieved.' It adds nuance rather than restating the schema, though most of the per-parameter detail lives in the schema itself.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource+scope: 'Fact-check 1 to 25 natural-language claims against Lune's peer-reviewed corpus in ONE call,' and explains the retrieval-then-judge mechanic and the three-verdict taxonomy. It never names a sibling tool, so the distinction from gather_evidence or search_papers must be inferred from the verdict-based behavior.

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?

Gives concrete use cases: 'ground a draft before you assert it, to vet a user's claim, or to check your own answer against the literature.' That is clear when-to-use guidance, but there are no explicit exclusions or named alternatives for someone deciding between this and a plain retrieval tool.

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.

Resources