Stipple — Document Verification & Extraction

Run an Australian identity check

verify_identity

Read-only

Run an Australian identity check over a SET of identity documents. A vision model reads each document (which ID it is, which fields it shows — name/photo/address/signature — and its issue date); a deterministic engine then tallies them against a scheme and reports whether identity is established, and exactly what's still missing if not.

USE THIS WHEN someone needs to verify a person's identity from their documents — KYC /
onboarding / "do these documents satisfy the 100-point check?" Pass ALL the person's
documents together (a passport alone is 70 points; the check needs >= 100).

`documents` is a list, each item ONE of: {"url": "https://..."} (public link, fetched
server-side) or {"bytes_b64": "...", "filename": "passport.pdf"} (inline). Up to 10.
`scheme`: "afp_100_point" (points, default) or "austrac_safe_harbour" (category combinations).

Returns `{established, points/target or satisfied_path, documents[] (per-document: type,
fields shown, whether it counted and why-not), reason, accepts, ...}`. This is identity
COVERAGE, not a forgery judgment — run verify_document for authenticity. Documents are
never stored.

Input Schema

TableJSON Schema

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

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedJun 17, 2026

TDQS

A4.8/5.0

Behavior4/5

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

Annotations only declare readOnlyHint=true, meaning no mutation. The description goes beyond that by disclosing that documents are never stored, which is critical privacy context. It also reveals the deterministic engine behavior and that it returns a structured coverage result. However, it doesn't explicitly state whether the vision model introduces variable latency or potential failures, but that is minor given the strong context.

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 well-structured with a clear opening paragraph on the method, a 'USE THIS WHEN' section for usage, and inline parameter explanations. Every sentence provides value, and the critical distinction (coverage vs. forgery) is front-loaded. It is verbose but appropriately so for a complex 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?

The description covers the purpose, usage, parameters, output structure, and privacy implications. It also routes to siblings when neededcars. Although an output schema exists, the description goes beyond by explaining semantics of the return fields (e.g., whether documents counted and why-not), which is rich enough for an agent to use the results effectively.

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 coverage is 0%, so the description must fully compensate. It does: `documents` is described as a list of one of two forms (url or bytes_b64+filename) with exampleslor and a limit of 10. `scheme` is explained with its two possible values and defaults, and each is defined. This adds substantial meaning beyond the bare 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?

The description clearly states a specific verb 'verify' and resource 'Australian identity check' over documents, and distinguishes it from siblings like verify_document and check_document by explaining it tallies documents against a scheme for coverage, not forgery. It also clarifies what it does not do, which helps an agent differentiate it immediately.

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?

Explicitly states when to use: for KYC/onboarding and 100-point check queries, and when not to: it is not a forgery judgment, so use verify_document for authenticity. It also gives practical guidance to pass all documents together and explains the 100-point threshold, which is essential for correct invocation.

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.