Skip to main content
Glama

Verify claims against the corpus

verify_claims
Read-only

Fact-check 1 to 25 natural-language claims against a peer-reviewed corpus in one call. Each claim receives a verdict with a verified quote, confidence, and reasoning.

Instructions

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 instead of stating things from memory. 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.

Input Schema

TableJSON 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

TableJSON Schema
NameRequiredDescriptionDefault
verdictsYesOne grounded verdict per input claim, in input order.
claims_processedYesTotal claims judged; equals verdicts.length.
Behavior5/5

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

Beyond annotations (readOnlyHint, openWorldHint, non-destructive), the description details the process: retrieval + LLM judging only against passages, verdict types, verbatim quote guarantee, confidence/reasoning, and filter sharing. No contradictions with annotations.

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 front-loaded with the core purpose and efficiently covers process, output, and usage nuances. At ~150 words, it is well-structured but slightly longer than necessary; could be tightened marginally.

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 7 parameters (100% schema coverage), output schema present, and sibling tools, the description is comprehensive. It explains verdicts, quote guarantees, confidence/reasoning, filter sharing, and handle usage. No major gaps; the open-world nature is addressed via insufficient_evidence.

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 covers 100% of parameters with descriptions. The description adds value by explaining that filters are shared across claims, that paper_ids are handles not for display, and that claims should be self-contained assertions. This compensates beyond 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?

The description clearly states the tool's purpose: fact-checking 1-25 claims against a corpus in one call, with verb 'fact-check' and specific resource. It distinguishes from sibling tools like search_papers by focusing on verdict generation, and explicitly mentions use cases like grounding drafts or vetting claims.

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?

The description provides explicit use cases: 'ground a draft before you assert it, to vet a user's claim, or to check your own answer against the literature.' It implies when to use over memory-based answers but lacks explicit when-not or alternative comparison. However, the context is clear.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/RetrogradeLabs/lune-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server