Skip to main content
Glama
Sign In

Lenz Fact-Check

by io.lenz
OverviewDiscussionsAdmin

Get citation check result

get_citation_check
Read-onlyIdempotent

Get the result of a citation check (check_citations) that is running or already finished: wait for a running check by its citecheck_id and return it the same way, with the findings per citation.

Use it when check_citations returned status: running, or to read an earlier check again. Still running after the wait means tell the user it is still running and call again. The citecheck_id belongs to a citation check only: a deep check's id goes to get_verification. Use offset only to page the remaining draft citations the user wants checked, one batch at a time. Read-only: it never starts a check.

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": {
      "citecheck_id": "<citecheck_id>"
    },
    "name": "get_citation_check"
  }
}

Input Schema

NameRequiredDescriptionDefault
offsetNoLeave at 0 to read the check. To page the draft citations a check did not cover, pass the result's `next_offset`: the next batch of candidates comes back, starting there.
citecheck_idYesThe citecheck_id returned by check_citations (waits for the running check).

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, so the description correctly focuses on the waiting/polling behavior, the re-call rule while still running, and the paging semantics of offset – none of which annotations express. It does not state how long the wait blocks or what a timeout looks like, which is the one behavioral detail an agent would want.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core purpose in the first sentence, then layers usage, id routing, paging, and the read-only guarantee in short clauses. No filler sentences; every line carries a decision the agent needs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With a full output schema and rich annotations, the description only needs to cover workflow and edge cases, which it largely does (running, re-check, wrong id type, paging). The missing piece is the bounding behavior of the blocking wait, which affects how an agent should handle latency.

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 coverage is 100%, so baseline is 3; the description adds real routing meaning beyond the schema by stating the citecheck_id belongs to a citation check only and that deep-check ids belong to get_verification. It also restates the offset-as-next_offset paging contract, though that is already in the 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?

States a specific verb and resource (get the result of a citation check) and explicitly scopes it to a check that is running or finished. It distinguishes itself from both neighbors by name: check_citations starts a check, get_verification handles deep-check ids.

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 triggers ('Use it when check_citations returned status: running, or to read an earlier check again'), an alternative for a diverging id type ('a deep check's id goes to get_verification'), and a next-step rule for a still-running result. Nothing about when to call it 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.

All Lenz Fact-Check toolsInspect
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.

Resources