Stipple — Document Verification & Extraction

Verify a document's authenticity

verify_document

Read-only

Forensically inspect a document (PDF or image) for authenticity: tampering signs, AI-generation indicators, arithmetic reconciliation (financial docs), and provenance.

USE THIS WHEN someone shares a payslip, bank statement, invoice, receipt, ID, certificate,
or contract and asks: is this genuine / real / authentic? has it been edited, doctored, or
photoshopped? can I trust this file? (For "did an AI *write* this prose" use
`detect_ai_text`; for "are this report's citations real" use `verify_references`. Both are
available in this canonical suite.)

Provide the document ONE way: `url` (a public http(s) link — fetched server-side, the
cheapest call: no need to download or encode anything) OR `bytes_b64` (inline base64, plus
`filename` so PDF-vs-image routing is right).

Returns the headline result — `risk_band` (low/medium/high/insufficient/error),
`inspection_quality` (coverage, orthogonal to risk), `recommended_action`, a `summary`, the
RISK-axis `risk_findings`, and a shareable `permalink`. This is a SIGNAL, not a fraud
verdict — a human or agent adjudicates. Use `get_warrant(warrant_id)` for the full evidence
bundle. Identical bytes are cached by content hash — `check_document` first skips a
redundant, paid inspection.

Input Schema

TableJSON Schema

Name	Required	Default
`url`	No
`fresh`	No
`filename`	No	document.pdf
`bytes_b64`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedJun 10, 2026

addedInput schema / properties / bytes_b64 / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / bytes_b64 / default
```
Added value: +null
```
removedInput schema / properties / bytes_b64 / type
```
Removed value: -"string"
```

addedInput schema / properties / url

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Url"
+}

removedInput schema / required
```
Removed value: -[
-  "bytes_b64"
-]
```

First observedJun 7, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only provide `readOnlyHint`, yet the description voluntarily discloses server-side fetching, content-hash caching, the 'signal not a fraud verdict' limitation, and a downstream `get_warrant` path for full evidence. It meaningfully expands beyond annotations and is consistent with readOnlyHint.

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 description is clearly structured with purpose, when-to-use, input mechanisms, and output semantics, and it front-loads the most load-critical information. It is longer than minimal but uses that length for operational nuance such as caching and cost guidance, so the length is justified.

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?

Given the tool's complexity, the description covers purpose, triggers, bypass path, document input choice, output semantics, and next-step evidence retrieval. The only notable completeness gap is the undocumented `fresh` parameter, but the description still gives strong guidance for an agent to invoke and trust the call.

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?

With 0% schema description coverage, the description provides real value by explaining `url` as a server-side-fetched http(s) link and `bytes_b64` plus `filename` as the inline-base64 route with PDF-vs-image routing. It omits `fresh` entirely, which is a minor but real gap given that parameter is otherwise undocumented.

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 description leads with a specific verb and resource: 'Forensically inspect a document (PDF or image) for authenticity', and enumerates concrete checks like tampering signs, AI-generation indicators, and provenance. It also differentiates from siblings by naming `detect_ai_text` and `verify_references` as the tools for other question types, so an agent can disambiguate from related tools.

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?

The 'USE THIS WHEN' block gives concrete document types and user questions, making the trigger condition explicit. It also states when not to use it by pointing to `detect_ai_text` and `verify_references`, and it tells the agent to use `check_document` first to skip a redundant, paid inspection.

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

All Stipple — Document Verification & Extraction 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.