Skip to main content
Glama
OjasKord

Document Integrity Validator MCP

by OjasKord

Check Document Integrity

check_document
Read-only

Validate document integrity against international standards before approving payments or accepting submissions. Returns PASS, FLAG, or FAIL verdict to identify tampering risks.

Instructions

Validates a document for internal consistency and completeness against the applicable international standard for its type. Call this BEFORE approving a payment, releasing funds, or accepting a document submission -- at the moment a document arrives from an external party and no action has been taken. Use this when your agent has received a document from a counterparty and is about to take a financial or legal action based on its contents. Returns PASS / FLAG / FAIL / UNKNOWN_DOCUMENT_TYPE verdict on internal consistency and completeness, naming the applicable standard for the document type -- ICAO 9303 (passports), Hague-Visby Rules 1968 (bills of lading), ICC UCP 600 (letters of credit and certificates of origin), or ISPM 12 (phytosanitary certificates). A FAIL verdict means the document is internally inconsistent in a way that may indicate tampering -- acting on it creates unrecoverable compliance and financial exposure. Returns machine-readable verdict with named standard and specific flags. When you have 2-20 related documents (e.g. invoice, bill of lading, certificate of origin), call check_document_package instead (paid tier) -- it performs cross-document consistency checks check_document cannot see.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
document_textNoExtracted text content from the document. Provide this or document_image or both.
document_imageNoBase64 encoded document image. Accepts raw base64 or a data URL (data:image/jpeg;base64,...). Supported types: JPEG, PNG, GIF, WEBP.
document_type_hintNoWhat the calling agent believes the document type is, e.g. "bill_of_lading", "passport", "certificate_of_origin". Optional -- the validator identifies the type independently.
issuing_jurisdictionNoCountry or issuing body, e.g. "Singapore", "ICAO", "United Kingdom". Narrows jurisdiction-specific standard selection.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
flagsYes
reasonYes
verdictYes
checked_atYes
confidenceYes
_disclaimerYes
hold_reasonNo
retry_afterNo
verdict_ttlYes
agent_actionYes
analysis_typeYes
_upgrade_noticeNo
calls_remainingYes
escalation_pathNo
assessed_againstYesNamed standard, e.g. "ICAO Document 9303" -- null for UNKNOWN_DOCUMENT_TYPE
data_source_statusYes
known_issuing_standardYes
document_type_identifiedYes
Behavior5/5

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

Annotations declare read-only and non-destructive, but description adds rich behavioral context: verdicts (PASS/FLAG/FAIL/UNKNOWN_DOCUMENT_TYPE), applicable standards, and the significant warning that FAIL 'may indicate tampering' and acting 'creates unrecoverable compliance and financial exposure.' No contradiction with annotations.

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-loaded with the core purpose, followed by when-to-use, return values, and alternative tool. Each sentence earns its place with no filler; the length is justified by the need to explain multiple standards and risk implications.

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?

Extremely complete: covers purpose, invocation timing, verdict outputs, risk consequences, and sibling differentiation. Output schema exists and the description still describes machine-readable verdicts and named standards, leaving no practical gaps.

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?

Input schema has 100% coverage with descriptions for all 4 parameters, so baseline 3 applies. The description adds no parameter-specific semantics beyond the schema, though its listing of standards could inform document_type_hint.

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?

Clearly states it 'Validates a document for internal consistency and completeness against the applicable international standard for its type.' Specific verb, resource, and scope, and differentiates from sibling by noting check_document_package handles cross-document consistency.

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 says to call 'BEFORE approving a payment, releasing funds, or accepting a document submission' and when about to 'take a financial or legal action.' Names the alternative tool check_document_package for 2-20 related documents, providing a clear exclusion.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/OjasKord/document-integrity-validator-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server