Lenz Fact-Check

Get deep fact-check result

get_verification

Read-onlyIdempotent

Get the result of a deep check that is running or already finished: wait for a running check by task_id (or several in parallel via task_ids), or fetch a completed one by verification_id.

With a task_id (from verify_claim or select_claims) this waits for the run to finish and returns status: completed with the verdict, the 1–10 Lenz score (or No Public Record, with no score, when nothing public records the claim), confidence, key finding, executive summary, top sources, a suggested_rewrite when the claim can be corrected (not verified itself: a suggestion to review, never a checked fact), the depth the verdict was produced at and the verification_id — pass that to ask_followup for a grounded follow-up. If the check needs a decision (the text holds several claims) it returns status: needs_input with the options. Still processing after the wait means tell the user it is still running and call again; list_verifications finds it later if the conversation moves on. A completed result replaces any earlier quick verdict on the same claim; its supersedes and presentation say how to tell the user. With an 8-character verification_id it returns the stored result immediately.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_verification"
  }
}

Input Schema

Name	Required	Description	Default
`task_id`	No	The task_id returned by verify_claim or select_claims (waits for the running check), or the 8-character verification_id of a completed result (fetches it). Leave empty when passing `task_ids`.
`task_ids`	No	Up to 10 task_ids or verification_ids to wait on or fetch in parallel in one call. Mutually exclusive with `task_id`.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedNov 8, 2026

addedInput schema / properties / task_id / default
```
Added value: +""
```

changedInput schema / properties / task_id / description

Previous value: -"The task_id returned by verify_claim or select_claims (waits for the running check), or the 8-character verification_id of a completed result (fetches it)."New value: +"The task_id returned by verify_claim or select_claims (waits for the running check), or the 8-character verification_id of a completed result (fetches it). Leave empty when passing `task_ids`."

addedInput schema / properties / task_ids

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Up to 10 task_ids or verification_ids to wait on or fetch in parallel in one call. Mutually exclusive with `task_id`.",
+  "title": "Task Ids"
+}

removedInput schema / required
```
Removed value: -[
-  "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 already declare readOnly/idempotent/non-destructive, but the description goes well beyond them: it enumerates the possible `status` values, discloses the wait-vs-immediate semantics, the `supersedes` relationship with an earlier quick verdict, and the caveat that `suggested_rewrite` is a suggestion rather than a verified fact. The No Public Record case (no score) is also disclosed, which an agent could not infer from 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 scope statement is front-loaded and the sentences are dense with usable information, but the paragraph is long and packs return-value details that an output schema already covers. Nothing is off-topic; it is only slightly over-packed for a two-parameter tool.

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 a long-running async operation with multiple terminal states, the description covers every state the caller must handle and what to do next, plus the semantic caveats around superseded verdicts and suggested rewrites. Nothing needed to call this correctly is missing, even though the output schema would have carried some of the return detail.

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 description coverage is 100%, and the schema already documents the dual role of `task_id` (task vs 8-character verification_id), the 10-item cap, and mutual exclusivity with `task_ids`. The description restates these correctly but adds little meaning beyond the schema, so the baseline of 3 applies.

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+resource: retrieve the result of a deep fact-check, either by waiting on a running task or fetching a stored completed result. It clearly separates itself from `verify_claim`/`select_claims` (which produce the task_id) and `list_verifications` (which finds a check later).

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?

Explicit routing rules: use `task_id` to wait, `task_ids` for parallel waits, or an 8-character `verification_id` to fetch immediately. It also prescribes follow-up behavior for each terminal state (`needs_input` → decide, `processing` → tell the user and call again, or move on to `list_verifications`) and names `ask_followup` as the next step with the returned `verification_id`.

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.