Integration with LangChain/LangGraph for building agent systems with document integrity validation tools.
Integration with LangChain/LangGraph for building agent systems with document integrity validation tools.
Integration with OpenAI Agents SDK to provide document integrity validation tools for agents.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Document Integrity Validator MCP Validate this bill of lading against Hague-Visby Rules"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Before your agent accepts, processes, or acts on any document received from an external party -- verify it is internally consistent and matches the known standard for its type. One call. Any document. Machine-readable verdict.
Checks any document for internal consistency, completeness, and anomalies against the known international standard for that document type. Accepts base64 image or extracted text. Returns a structured verdict with a machine-readable agent_action field.
Supported standards include: ICAO Document 9303 (passports), Hague-Visby Rules 1968 (bills of lading), UCP 600 (trade finance documents), ISPM 12/IPPC/FAO (phytosanitary certificates), Vienna Convention on Road Traffic 1968 (driving licences), and more.
Returns UNKNOWN_DOCUMENT_TYPE rather than guessing on unfamiliar documents -- refusal is correct behaviour, not a failure.
AI-powered reasoning -- NOT a database lookup.
Related MCP server: Qiniso
Checks a single document against its international standard.
Input:
document_text (string, optional) -- extracted text from the document
document_image (string, optional) -- base64 encoded image (raw base64 or data URL)
document_type_hint (string, optional) -- agent belief about document type
issuing_jurisdiction (string, optional) -- country or issuing body
At least one of document_text or document_image is required.
Response:
{
"agent_action": "PROCEED",
"verdict": "PASS",
"confidence": "HIGH",
"document_type_identified": "Bill of Lading",
"assessed_against": "Hague-Visby Rules 1968",
"known_issuing_standard": "IMO",
"flags": [],
"reason": "Document is internally consistent and compliant with Hague-Visby Rules 1968.",
"analysis_type": "AI-powered reasoning -- NOT a database lookup",
"checked_at": "2026-05-06T10:00:00.000Z",
"_disclaimer": "..."
}agent_action values:
PROCEED -- document passed
VERIFY_MANUALLY -- flags found, agent should flag for human review
HOLD -- document failed, do not proceed
REFER_TO_HUMAN -- document type unknown, refer for manual assessment
Checks 2-20 related documents individually then cross-checks all for consistency conflicts.
Input:
documents (array, min 2, max 20) -- each item has: label (required), document_text, document_image, document_type_hint, issuing_jurisdiction
Cross-checks performed: weights/quantities/amounts, party names, reference numbers, dates, commodity descriptions, port references.
Tier | Calls | Price |
Free | 10/month per IP | No API key required |
Trial extension | +10 one-time | POST /trial-extension |
Pro | 500/month | $29/month |
Enterprise | 5,000/month | $199/month |
Overage: $0.05 per call above monthly cap.
Subscribe at kordagencies.com.
{
"mcpServers": {
"document-integrity-validator": {
"type": "http",
"url": "https://document-integrity-validator-mcp-production.up.railway.app/mcp"
}
}
}from langchain_mcp_adapters.client import MultiServerMCPClient
client = MultiServerMCPClient({
"document-integrity-validator": {
"url": "https://document-integrity-validator-mcp-production.up.railway.app/mcp",
"transport": "http"
}
})
tools = await client.get_tools()from agents import Agent, HostedMCPTool
agent = Agent(
name="Assistant",
tools=[HostedMCPTool(tool_config={
"type": "mcp",
"server_label": "document-integrity-validator",
"server_url": "https://document-integrity-validator-mcp-production.up.railway.app/mcp",
"require_approval": "never"
})]
)npm install -g document-integrity-validator-mcp
ANTHROPIC_API_KEY=sk-ant-... TRANSPORT=stdio document-integrity-validator-mcpAdd to Claude Desktop claude_desktop_config.json:
{
"mcpServers": {
"document-integrity-validator": {
"command": "document-integrity-validator-mcp",
"env": { "ANTHROPIC_API_KEY": "sk-ant-..." }
}
}
}If you have reached the 10 call/month free limit, request 10 extra calls:
curl -X POST https://document-integrity-validator-mcp-production.up.railway.app/trial-extension \
-H "Content-Type: application/json" \
-d '{"name":"Your Name","email":"you@example.com","use_case":"Brief description"}'One extension per email address.
AI-powered document consistency assessment. Results are for informational purposes only and do not constitute legal, compliance, or authentication advice. We do not log or store your document content. Full terms: kordagencies.com/terms.html
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.
| 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. |
| Name | Required | Description |
|---|---|---|
| flags | Yes | |
| reason | Yes | |
| verdict | Yes | |
| checked_at | Yes | |
| confidence | Yes | |
| _disclaimer | Yes | |
| hold_reason | No | |
| retry_after | No | |
| verdict_ttl | Yes | |
| agent_action | Yes | |
| analysis_type | Yes | |
| _upgrade_notice | No | |
| calls_remaining | Yes | |
| escalation_path | No | |
| assessed_against | Yes | Named standard, e.g. "ICAO Document 9303" -- null for UNKNOWN_DOCUMENT_TYPE |
| data_source_status | Yes | |
| known_issuing_standard | Yes | |
| document_type_identified | Yes |
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.
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.
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.
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.
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.
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.
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 may indicate fraud -- 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. |
| Name | Required | Description |
|---|---|---|
| verdict | Yes | |
| documents | Yes | |
| checked_at | Yes | |
| confidence | Yes | |
| _disclaimer | Yes | |
| verdict_ttl | Yes | |
| agent_action | Yes | |
| analysis_type | Yes | |
| calls_remaining | Yes | |
| package_verdict | Yes | |
| data_source_status | Yes | |
| package_agent_action | Yes | |
| cross_document_conflicts | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, and the description adds substantial behavioral detail: returns PASS/FLAG/FAIL verdicts per document, cross-checks numeric values, party names, reference numbers, dates, and commodity descriptions, and warns that a single inconsistency may indicate fraud with no recovery path. This goes well beyond what annotations alone convey.
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 longer than minimal, but every sentence contributes: purpose, timing, input composition, return format, checks performed, risk rationale, and an exclusion. It is front-loaded with the core purpose in the first sentence. Slightly verbose but not wasteful.
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?
For a complex, safety-critical cross-document validation tool, the description covers purpose, input requirements, return style, what is checked, fraud risk, and when to avoid using it. The output schema exists, so return format details are not required, and the description still mentions the PASS/FLAG/FAIL verdict. This is fully complete for selecting and invoking the tool.
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 single parameter 'documents' has 100% schema description coverage, so the baseline is 3. The description enriches it by framing the array as a 'full trade finance package' with examples (invoice, bill of lading, certificate of origin) and emphasizing the cross-document consistency purpose. It doesn't add new syntax details, but the examples and context add practical meaning beyond the schema.
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 names a specific verb ('Validates'), a specific resource ('a package of 2-20 related trade finance documents'), and a clear outcome ('for cross-document consistency'). It also explicitly distinguishes itself from the sibling tool check_document by warning not to use it when only one document needs verification.
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?
Provides explicit when-to-use guidance: 'Call this BEFORE approving any multi-document trade finance transaction or cross-border shipment' and 'when funds have not been released'. It also gives a concrete example of a full package and an explicit when-not-to-use: 'Do not use as a substitute for check_document when only one document requires verification.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.30check_documentcheck_document_packageThe two tools have clearly distinct purposes: check_document validates a single document's internal consistency, while check_document_package validates cross-document consistency for 2-20 related documents. Their descriptions explicitly state when to use each, leaving no ambiguity about which to select.
Both tool names follow the same verb_noun pattern: 'check_document' and 'check_document_package'. The second name is a logical extension of the first, making the relationship and function predictable.
With only two tools, the server is borderline minimal, but this is appropriate for a narrow domain focused on document validation. The two tools cover the two core scenarios (single document and package), with no unnecessary bloat.
The server covers the primary validation workflows: single-document internal consistency and multi-document cross-consistency. Minor gaps exist, such as not exposing a way to list supported standards or validate against a user-specified standard, but these are not critical for the core use case.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Document forensics: tamper/AI checks, fields, tables, identity, screening, tenders, citations.
Preflight QA for AI-agent deliverables with structured verdicts and repair guidance.
Checksum validation for AI agents: IBAN, ISBN, EAN/GTIN, UUID, ULID. Deterministic, no auth.
AI document intelligence: extract, summarize, claim-check, notarize, and signed action receipts.
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
