Document Integrity Validator
Server Details
AI reasoning checks any document against known international standards before your agent acts on it.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.6/5 across 2 of 2 tools scored.
The two tools have clearly distinct purposes: check_document handles single documents, while check_document_package handles multi-document consistency. The descriptions explicitly state when to use each, eliminating any ambiguity.
Both tools follow a consistent verb_noun pattern (check_document, check_document_package), making the naming predictable and intuitive.
With only 2 tools, the server feels slightly thin for a full document integrity validator, but it covers the essential single and multi-document checking functionalities. Still acceptable given the focused scope.
The tools cover the primary actions for document validation, but lack auxiliary tools like retrieving detailed check results, listing supported standards, or configuring validation parameters. Some gaps exist that agents might need.
Available Tools
2 toolscheck_documentCheck Document IntegrityARead-onlyInspect
Validates a document against international standards for authenticity and internal consistency. 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 assessed against ICAO 9303 (passports), Hague-Visby Rules 1968 (bills of lading), ICC UCP 600 (letters of credit and certificates of origin), and ISPM 12 (phytosanitary certificates). A FAIL verdict means the document is internally inconsistent indicating tampering -- acting on it creates unrecoverable compliance and financial exposure. Returns machine-readable verdict with named standard and specific flags, no further analysis needed.
| Name | Required | Description | Default |
|---|---|---|---|
| document_text | No | Extracted text content from the document. Provide this or document_image or both. | |
| document_image | No | Base64 encoded document image. Accepts raw base64 or a data URL (data:image/jpeg;base64,...). Supported types: JPEG, PNG, GIF, WEBP. | |
| document_type_hint | No | What 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_jurisdiction | No | Country or issuing body, e.g. "Singapore", "ICAO", "United Kingdom". Narrows jurisdiction-specific standard selection. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive. Description adds the verdict outputs, the meaning of FAIL (tampering), the consequence of acting on tampered documents (compliance/financial exposure), and the use of international standards.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (~80 words), front-loaded with usage guidance, and every sentence provides essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's critical role, the description explains verdicts and provides context for decision-making. Minor gap: does not specify which international standards or differentiate between FLAG and FAIL, but overall sufficient for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already has 100% coverage with descriptions. The description does not add significant new per-parameter information beyond restating the purpose. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks document integrity and returns a verdict (PASS/FLAG/FAIL/UNKNOWN_DOCUMENT_TYPE) against international standards. It distinguishes from the sibling tool by specifying it is for individual documents before any action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to call ('BEFORE your agent acts on any received document') and provides specific scenarios (approving payment, onboarding, submission). Also gives explicit instruction on what to do for FAIL verdict (do not proceed).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_document_packageCheck Document Package IntegrityARead-onlyInspect
Validates a package of 2-20 related trade finance documents for cross-document consistency. Call this BEFORE approving any multi-document trade finance transaction or cross-border shipment -- at the moment a set of 2-20 related documents arrives from an external party and funds have not been released. Use this when your agent has received a full trade finance package — such as invoice, bill of lading, and certificate of origin together — and must verify all documents are consistent with each other before releasing funds. Returns PASS/FLAG/FAIL verdict per document with mismatch details. Cross-checks all documents for consistency across numeric values, party names, reference numbers, dates, and commodity descriptions. A single inconsistency in a trade finance document package is a fraud signal -- funds released on a mismatched package have no recovery path. Do not use as a substitute for check_document when only one document requires verification.
| Name | Required | Description | Default |
|---|---|---|---|
| documents | Yes | Array of 2 to 20 related documents to assess individually and cross-check against each other. Each document must have a unique label. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, openWorldHint), the description adds critical behavioral context: it warns that a single inconsistency indicates fraud with no recovery path once funds are released. It also specifies the document count range (2-20) and the nature of checks (numeric values, party names, etc.). This is valuable beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: three sentences that front-load the most critical usage guidance ('Call this BEFORE...') and include a clear exclusion. Every sentence adds value with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool (cross-checking multiple documents) and the absence of an output schema, the description provides strong contextual completeness by explaining the why (fraud detection), when, and what it checks. However, it does not describe the return format or what the agent should expect as output (e.g., list of inconsistencies or a pass/fail). This minor gap prevents a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes all parameters with 100% coverage, including descriptions for each field. The tool's description does not add significant new information about parameters beyond what the schema provides. For example, the schema already states that the label is an 'Agent-assigned identifier' used in conflict reporting. Therefore, baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: cross-checking 2-20 documents for consistency in multi-document trade finance transactions. The verb 'cross-checks' and resource 'document package integrity' are specific. It explicitly distinguishes from the sibling tool check_document, which is for single documents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use: 'Call this BEFORE your agent approves any multi-document trade finance transaction... at the moment a set of related documents is received and no action has been taken.' It also states when not to use: 'Do not use as a substitute for check_document when only one document needs verification.' This leaves no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!