FactLot

Verify a claim against a document

doc_verify_claim

Read-onlyIdempotent

Check one claim against a document page: {predicate, value} (anything doc_verify_facts accepts) or a short claim sentence ({text} or a bare string), plus the verbatim quote and page it rests on. Returns supported (the quote is on the page and every checked number, date and name in the claim is written in it), contradicted (the quote is on the page and states other numbers or dates of the same kind, listed in quote_states), or unverifiable (the quote is not on the page, nothing in the claim can be checked, or the quote states no value of that kind), with the evidence (document_id, page, quote, span) and each part checked. Textual, not semantic: for a sentence only its numbers and dates are compared, never its meaning, and a quote that mentions the right number for a different term still supports it.

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": {
      "document": "<document>",
      "claim": "<claim>",
      "quote": "<quote>",
      "page": "<page>"
    },
    "name": "doc_verify_claim"
  }
}

Input Schema

Name	Required	Description
`page`	Yes	1-based page the quote is on.
`claim`	Yes
`quote`	Yes	Verbatim text from the page that the claim rests on.
`document`	Yes	The document the quote is from.

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedNov 6, 2026

addedInput schema / properties / claim / anyOf

Added value: +[
+  {
+    "description": "A short claim sentence, read as {text: the sentence}; its numbers and dates are checked.",
+    "maxLength": 2000,
+    "minLength": 1,
+    "type": "string"
+  },
+  {
+    "description": "Either {predicate, value} or {text}.",
+    "properties": {
+      "predicate": {
+        "description": "Predicate of the claim, with value.",
+        "maxLength": 200,
+        "minLength": 1,
+        "type": "string"
+      },
+      "text": {
+        "description": "Or a short claim sentence instead of predicate and value; its numbers and dates are checked.",
+        "maxLength": 2000,
+        "minLength": 1,
+        "type": "string"
+      },
+      "value": {
+        "description": "Claimed value in the predicate's shape, with predicate."
+      }
+    },
+    "type": "object"
+  }
+]

removedInput schema / properties / claim / description

Removed value: -"Either {predicate, value} or {text}."

removedInput schema / properties / claim / properties

Removed value: -{
-  "predicate": {
-    "description": "Predicate of the claim, with value.",
-    "maxLength": 200,
-    "minLength": 1,
-    "type": "string"
-  },
-  "text": {
-    "description": "Or a short claim sentence instead of predicate and value; its numbers and dates are checked.",
-    "maxLength": 2000,
-    "minLength": 1,
-    "type": "string"
-  },
-  "value": {
-    "description": "Claimed value in the predicate's shape, with predicate."
-  }
-}

removedInput schema / properties / claim / type
```
Removed value: -"object"
```

Changed1 schema field changedNov 4, 2026

addedInput schema / properties / document / properties / ocr_pages

Added value: +{
+  "description": "Optional: pages (1-based) whose text came from OCR rather than the file's text layer (doc_read_pdf and factlot.read_pdf report them). Facts and citations on these pages carry ocr: true, so a reviewer checks the scan.",
+  "items": {
+    "maximum": 100000,
+    "minimum": 1,
+    "type": "integer"
+  },
+  "maxItems": 2000,
+  "type": "array"
+}

AddedNov 4, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description goes well beyond them: it enumerates the three outcomes with exact decision rules, discloses the non-obvious 'textual, not semantic' matching rule, and warns about the specific false-positive case where a right number for a different term still supports the claim. That is exactly the behavioral context an agent cannot infer from structured fields.

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 outcomes, and every sentence carries information about behavior or return values. The single dense sentence with nested parentheses around the outcome definitions makes it harder to scan than it needs to be, but no content is padding.

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 four required parameters, a nested document object, and no output schema, the description does the necessary work of describing the return payload (document_id, page, quote, span, quote_states) and the outcome taxonomy. It is slightly thin on the exact structure of 'each part checked', but that is a minor gap for a read-only verification tool.

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 75%, so the schema already documents page, quote, and the claim union, and the description largely restates those shapes rather than adding new meaning. It does clarify that the quote must be verbatim from the given page and that predicate/value must match doc_verify_facts' shapes, but the nested document.sha256 and ocr_pages semantics are left entirely to 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 ('check one claim against a document page') and pins the scope to a single claim, which distinguishes it from the batch sibling doc_verify_facts that the description explicitly names. An agent can tell what it does and how it differs from the plural tool without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The single-claim framing implies when to reach for this instead of doc_verify_facts, and the accepted claim forms give practical input guidance. But there is no explicit 'use this when...' statement, no mention of fact_validate or doc_spread_statement as alternatives, and no guidance on prerequisites such as needing the page text first.

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

All FactLot 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.