Skip to main content
Glama

Lenz Fact-Check

Fast fact-check

assess_claim
Read-only

The quick check: a verdict and a bucketed confidence for each factual claim in a text or a list (3-model panel, about 15-20 seconds, one credit per claim). Use it when the user asks to fact-check or double-check a factual statement or a text (“fact-check this”, “double-check that”), asks whether one is true or accurate (“is that true?”, “is this accurate?”), or doubts a factual statement you made (“are you sure?”). Not for opinions, predictions, arithmetic or how code behaves. When the user doubts something you said, pass the specific statement being doubted, not the whole conversation.

For one claim or a whole text (a draft, a pasted text or your previous
answer), pass ONE text in ``claim`` (every claim found gets a row, up to
20) or up to 20 claims in ``claims`` (one row per item, same order). A
pasted text goes in ``claim`` whole and unedited — never split it, reword
it, resolve its pronouns or add figures. ``claims`` is only for claims the
user listed separately.
Verdicts are True / Mostly True / Mixed / Mostly False / False. No sources:
present each verdict as a first read, not as final. A row may carry
``rationale``, a reviewer's reasoning for the verdict, and ``dissent``, the
reasoning of the reviewer farthest from it: reviewers' notes, not checked
sources. A low-confidence row carries ``recommend_verify: true`` and a
``next_step``: recommend `verify_claim`, the deep check, and ask before
running it. On medium offer it; on high mention it. A vague claim is
assessed on its most likely reading (the row's ``claim``). Leave
``language`` unset.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
claimNoONE statement to fact-check, in natural language (e.g. "Honey never spoils"). If the text contains several atomic claims, each is verdicted separately (up to 20, one credit per verdict). Leave empty when passing `claims`.
claimsNoA list of up to 20 claims the user listed separately — one verdict per item, in the same order. Each item is one claim, not a document; a pasted text goes in `claim` instead. A compound item is judged on its main claim and the rest is listed in that row's `identified_claims`. Mutually exclusive with `claim`.
languageNoLeave unset. English is the default. Set this only if the user explicitly asked for the answer in another language — not to match the language of the claim, the conversation, or the user locale. Supported: en, es, de, fr, it, pt, nl, sv, da, no, fi, bg.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnly/openWorld/non-destructive, and the description adds cost (one credit per claim), latency (~15-20s), the model-panel method, the absence of sources ('a first read, not final'), and the confidence-tiered escalation policy. That is substantial context beyond the 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?

Front-loaded with the core behavior and tightly written, but it is long and restates a few schema facts (the claim/claims exclusivity, the language default) that the schema already documents. Every section is useful, yet there is mild redundancy.

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 invocation, field semantics, output shape (verdicts, rationale, dissent, recommend_verify, next_step) and escalation. With an output schema present it does not need to exhaustively document returns, yet explains the pieces an agent must act on.

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?

Even with 100% schema coverage, the description supplies operational semantics the schema lacks: a pasted text goes in `claim` whole and unedited, never split or reworded, while `claims` is only for separately listed items, and `language` should be left unset. This materially changes how the agent fills the fields.

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 ('a verdict and a bucketed confidence for each factual claim in a text or a list'), plus concrete traits (3-model panel, 15-20s, one credit per claim). It also names the sibling it is not — verify_claim is 'the deep check' — so the agent can distinguish it without opening a 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 explicit when-to-use triggers ('fact-check this', 'is that true?', 'are you sure?'), explicit exclusions ('not for opinions, predictions, arithmetic or how code behaves'), and a routing rule to verify_claim that varies by confidence tier. Nothing is left to inference.

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.