Lenz Fact-Check

Ask a follow-up

ask_followup

Answer a question about a finished deep check (a verify_claim result), using its full evidence.

A deep-check result summarises its evidence; this reads all of it (every source, the research and the reviewers' reasoning) and answers question from it. Pass the verification_id of a completed deep check (on a verify_claim or get_verification result, or a list_verifications row; NOT a task_id). Only works on a completed verify_claim — not on assess_claim results. Costs credits at the cheap rate, same as assess_claim. The conversation is kept server-side per verification, so ask follow-ups sequentially rather than in parallel. Replies in the language of the check unless the user explicitly asked for another one — leave language unset. The answer is markdown whose links point at the check's own sources: when you relay it, keep its source links as links.

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": {
      "verification_id": "<verification_id>",
      "question": "<question>"
    },
    "name": "ask_followup"
  }
}

Input Schema

Name	Required	Description
`language`	No	Leave unset: the answer follows the language of the deep check it is about. Set it only when the user asks for the answer in another language. Supported: en, es, de, fr, it, pt, nl, sv, da, no, fi, bg, sr.
`question`	Yes	The follow-up question, answered from the check's full evidence. Maximum 500 characters — ask one focused question rather than a multi-part one.
`verification_id`	Yes	The verification_id of a COMPLETED deep check (on a verify_claim or get_verification result, or a list_verifications row) — NOT a task_id.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 8, 2026

changedInput schema / properties / language / description

Previous value: -"Leave unset: the answer follows the language of the deep check it is about. Set it only when the user asks for the answer in another language. Supported: en, es, de, fr, it, pt, nl, sv, da, no, fi, bg."New value: +"Leave unset: the answer follows the language of the deep check it is about. Set it only when the user asks for the answer in another language. Supported: en, es, de, fr, it, pt, nl, sv, da, no, fi, bg, sr."

changedInput schema / properties / language / enum

Previous value: -[
-  "",
-  "en",
-  "es",
-  "de",
-  "fr",
-  "it",
-  "pt",
-  "nl",
-  "sv",
-  "da",
-  "no",
-  "fi",
-  "bg"
-]New value: +[
+  "",
+  "en",
+  "es",
+  "de",
+  "fr",
+  "it",
+  "pt",
+  "nl",
+  "sv",
+  "da",
+  "no",
+  "fi",
+  "bg",
+  "sr"
+]

Changed3 schema fields changedOct 22, 2026

changedInput schema / properties / language / description

Previous value: -"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."New value: +"Leave unset: the answer follows the language of the deep check it is about. Set it only when the user asks for the answer in another language. Supported: en, es, de, fr, it, pt, nl, sv, da, no, fi, bg."

changedInput schema / properties / question / description

Previous value: -"The follow-up question, answered from the verification's full research, debate, and adjudication. Maximum 500 characters — ask one focused question rather than a multi-part one."New value: +"The follow-up question, answered from the check's full evidence. Maximum 500 characters — ask one focused question rather than a multi-part one."

changedInput schema / properties / verification_id / description

Previous value: -"The verification_id of a COMPLETED verify_claim result (returned by get_verification) — NOT a task_id."New value: +"The verification_id of a COMPLETED deep check (on a verify_claim or get_verification result, or a list_verifications row) — NOT a task_id."

First observedOct 6, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only declare readOnly=false, openWorld=true, idempotent=false, destructive=false; the description adds the credit cost and its rate tier, the fact that conversation state is kept server-side per verification (which explains both the non-idempotent and non-read-only hints), and the sequencing constraint that follows from it. It also discloses the response shape constraint (markdown whose links point at the check's own sources, to be preserved on relay), which nothing in the structured fields conveys.

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 purpose and scope, then cost/state constraints, then answer-format guidance — a sensible ordering with no filler sentences. It loses a point for restating schema-documented parameter rules (`NOT a task_id`, leave `language` unset), which makes it longer than strictly necessary.

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 stateful, credit-consuming follow-up tool, the definition covers input provenance, cost, sequencing, language behavior, and output-format handling; the output schema means return values needn't be spelled out. An agent has everything needed to call it correctly and relay the result faithfully.

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

Parameters3/5

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

Schema coverage is 100% and the description largely restates what the schema already documents — the `verification_id` provenance and non-task_id warning, and the 'leave `language` unset' instruction appear in both places. It does reinforce priority and links `verification_id` to sibling tool outputs, but it adds little syntax or format detail the schema lacks. Baseline 3 is appropriate.

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 first sentence gives a specific verb ('Answer a question') tied to a specific resource and scope ('a finished deep check'), and immediately identifies the tool's relation to `verify_claim`. The follow-up sentence explicitly excludes `assess_claim` results, so an agent can distinguish this tool from `get_verification`, `list_verifications`, and `assess_claim` without opening another 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?

It states the precondition (a completed deep check), where to obtain the identifier (`verify_claim` result, `get_verification`, or a `list_verifications` row), and an explicit exclusion ('NOT a task_id', 'not on assess_claim results'). It also gives an operational rule — ask follow-ups sequentially rather than in parallel — and a language rule, which is when-to-use guidance an agent would otherwise have to guess.

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.