Lenz Fact-Check

Deep fact-check

verify_claim

The deep check: a verdict with a 1–10 score, the key finding, warnings and the main sources for ONE claim (about a minute to a minute and a half).

Not the default. Run only when the user asked for sources, a deep check or
a verification, or agreed after a quick check; a plain "check this" is
`assess_claim`. Never start one unasked. It costs 10 credits against 1 for `assess_claim`
(``depth="low"`` costs 5; `check_usage` has the live price list). Tell the
user the deep check is running. Waits for the check and returns
``status: completed`` when it finishes in time — a claim Lenz has
checked before comes back at once. Otherwise returns ``status: submitted``
with a ``task_id``: call `get_verification` with it, which waits again. A
completed result replaces any earlier quick verdict on the same claim; its
``supersedes`` and ``presentation`` say how to tell the user. A result may
carry ``suggested_rewrite``, the claim with its wrong part corrected: it is
not verified itself, so offer it as a suggestion to review, never as a
checked fact. If the text contains several claims the result is
``status: needs_input`` with a numbered list: show it to the user and call
`select_claims` with the exact text of the chosen claim(s).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`claim`	Yes	ONE claim to check in depth against sources. Run it once the user agreed to a deep check, or when they asked for sources, a deep check or a verification.
`depth`	No	How much research to do. "standard" (default) is the full pass. "low" is a shallower one — fewer sources, the same models — for half the credits; it saves only about a fifth of the time, so both take about a minute or more. Pick "low" when the user wants to spend fewer credits. The charge follows the depth you request; the `depth` on the completed result is the depth the verdict was actually produced at (a "low" request may be served from an existing deeper check).	standard
`language`	No	Leave 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

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 6, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations only establish readOnly=false, openWorld=true, destructive=false; the description goes far beyond by disclosing cost (10 credits vs 1, 5 for depth=low), latency (~a minute to 90s), the completed-vs-submitted status contract, cached-claim behavior, the supersedes/presentation semantics for replacing an earlier verdict, and the caveat that `suggested_rewrite` is not itself verified. That is exactly the behavioral context an agent needs and annotations 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 outcome and then the routing rule, and every clause carries operational weight (cost, timing, statuses, follow-ups). It is dense and long, and a couple of parentheticals (cache behavior, presentation) could be tightened, but nothing is 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 costly, async-capable, open-world tool with three params and an output schema, the description covers the full decision lifecycle: when to call, what it costs, what statuses come back, which tools to call next for each status, and what must be shown to the user. Nothing an agent needs to invoke it correctly is missing.

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 coverage is 100%, so the baseline is 3, but the description adds real meaning: it warns that multiple claims in the text return `needs_input` rather than a verdict, and it reinforces that one claim per call is expected. Combined with the schema's own depth/language guidance (cost tradeoff, time saved, when to override language), parameter intent is unambiguous.

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?

Opens with a specific verb+resource ('The deep check: a verdict with a 1–10 score, the key finding, warnings and the main sources for ONE claim') and immediately scopes it against the sibling it is not ('Not the default... a plain "check this" is `assess_claim`'). An agent can distinguish it from assess_claim, get_verification, and select_claims 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 explicit when-to-use ('Run only when the user asked for sources, a deep check or a verification, or agreed after a quick check'), when-not ('Never start one unasked'), and the alternative for the default path (`assess_claim`). It also names the follow-up tools for the async and multi-claim branches (`get_verification`, `select_claims`) with their trigger conditions.

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

All Lenz Fact-Check tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.