Stipple — Document Verification & Extraction

Check a document pack's completeness

check_pack

Read-only

Check whether a SET of documents satisfies a checklist — completeness, cheaply.

USE THIS WHEN you have an application / onboarding pack and need "do we have the required
documents, and what's still missing?" Each document is CLASSIFIED (one cheap page-1 read —
never full field extraction or multi-page), then matched against the checklist's required
slots. (For "is a document genuine?" use verify_document; to identify ONE document use
extract_fields with options={"classify": true}; for the identity gate use verify_identity.)

Define the checklist ONE of two ways:
  - `scheme`: a named preset — "income_proof", "lending_prequal", "rental_application".
  - `requirements`: an ad-hoc checklist — a list of document-type names like
    ["payslip","bank_statement"], or objects {"key":..., "accepts":[types], "optional":bool}.

`documents` is a list (up to 12), each ONE of: {"url": "https://..."} (public link, fetched
server-side) or {"bytes_b64": "...", "filename": "statement.pdf"} (inline).

Returns `{complete, slots[] (key, satisfied, matched), missing[], documents[] (filename,
classified_type), unmatched_documents[]}`. COVERAGE, not approval — that the right document
TYPES are present, NOT that any is genuine (run verify_document) or that an application is
approved. Documents are never stored.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`scheme`	No
`documents`	Yes
`requirements`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedJun 17, 2026

TDQS

A5/5.0

Behavior5/5

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

Annotations provide readOnlyHint=true, and the description adds complementary context: documents are never stored, classification is a cheap page-1 read only, and the tool checks type coverage not authenticity or approval. This goes well beyond the annotation and manages agent expectations about side effects and output semantics.

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?

The description is front-loaded with a clear purpose, then organized into short labeled segments ('USE THIS WHEN', 'Define the checklist ONE of two ways:', 'Returns...'). Every sentence conveys necessary information without redundancy. The length is justified by the zero-coverage schema.

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 tool with 3 parameters, 0% schema coverage, no parameter enums, and an output schema, the description is complete: covers input formats, limits (12 docs), checklist definitions, alternatives, and return semantics. It also clarifies exclusions (not authenticity check, not approval). Nothing an agent needs to invoke it correctly is missing.

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

Parameters5/5

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

Schema description coverage is 0%, so the description carries full responsibility for parameter meaning. It thoroughly explains scheme presets (with example names), requirements ad-hoc forms (strings or objects with key/accepts/optional), and the documents list (up to 12, with url or bytes_b64+filename formats, including URL fetching behavior).

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 states a specific verb and resource: 'Check whether a SET of documents satisfies a checklist — completeness, cheaply.' It clearly distinguishes this tool from siblings by explicitly naming alternatives for other use cases (verify_document, extract_fields, verify_identity), so an agent can tell which tool fits.

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 description includes an explicit 'USE THIS WHEN' condition with a concrete scenario ('application / onboarding pack') and the exact question the tool answers ('do we have the required documents, and what's still missing?'). It also gives when-not-to-use guidance and names alternative tools for different intents.

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.