Skip to main content
Glama

Document Integrity Validator

Check Document Integrity

check_document
Read-only

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

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed4 schema fields changed
    • addedOutput schema / properties / calls_remaining
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "number"
      +    },
      +    {
      +      "const": "unlimited",
      +      "type": "string"
      +    }
      +  ]
      +}
    • addedOutput schema / properties / data_source_status
      Added value: +{
      +  "enum": [
      +    "full",
      +    "degraded",
      +    "partial"
      +  ],
      +  "type": "string"
      +}
    • addedOutput schema / properties / verdict_ttl
      Added value: +{
      +  "type": "number"
      +}
    • changedOutput schema / required
      Previous value: -[
      -  "agent_action",
      -  "verdict",
      -  "confidence",
      -  "document_type_identified",
      -  "assessed_against",
      -  "known_issuing_standard",
      -  "flags",
      -  "reason",
      -  "analysis_type",
      -  "checked_at",
      -  "_disclaimer"
      -]New value: +[
      +  "agent_action",
      +  "verdict",
      +  "confidence",
      +  "document_type_identified",
      +  "assessed_against",
      +  "known_issuing_standard",
      +  "flags",
      +  "reason",
      +  "analysis_type",
      +  "checked_at",
      +  "_disclaimer",
      +  "calls_remaining",
      +  "verdict_ttl",
      +  "data_source_status"
      +]
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "http://json-schema.org/draft-07/schema#",
      +  "additionalProperties": false,
      +  "properties": {
      +    "_disclaimer": {
      +      "type": "string"
      +    },
      +    "_upgrade_notice": {
      +      "type": "string"
      +    },
      +    "agent_action": {
      +      "enum": [
      +        "PROCEED",
      +        "VERIFY_MANUALLY",
      +        "HOLD",
      +        "REFER_TO_HUMAN",
      +        "UPGRADE_REQUIRED"
      +      ],
      +      "type": "string"
      +    },
      +    "analysis_type": {
      +      "type": "string"
      +    },
      +    "assessed_against": {
      +      "description": "Named standard, e.g. \"ICAO Document 9303\" -- null for UNKNOWN_DOCUMENT_TYPE",
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "checked_at": {
      +      "type": "string"
      +    },
      +    "confidence": {
      +      "enum": [
      +        "HIGH",
      +        "MEDIUM",
      +        "LOW",
      +        "NONE"
      +      ],
      +      "type": "string"
      +    },
      +    "document_type_identified": {
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "escalation_path": {
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "flags": {
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    "hold_reason": {
      +      "type": "string"
      +    },
      +    "known_issuing_standard": {
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "reason": {
      +      "type": "string"
      +    },
      +    "retry_after": {
      +      "type": [
      +        "number",
      +        "null"
      +      ]
      +    },
      +    "verdict": {
      +      "enum": [
      +        "PASS",
      +        "FLAG",
      +        "FAIL",
      +        "UNKNOWN_DOCUMENT_TYPE"
      +      ],
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "agent_action",
      +    "verdict",
      +    "confidence",
      +    "document_type_identified",
      +    "assessed_against",
      +    "known_issuing_standard",
      +    "flags",
      +    "reason",
      +    "analysis_type",
      +    "checked_at",
      +    "_disclaimer"
      +  ],
      +  "type": "object"
      +}
  3. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnly and destructive hints, the description discloses meaningful behavioral details: return verdicts (PASS/FLAG/FAIL/UNKNOWN_DOCUMENT_TYPE), the meaning of FAIL (possible tampering), and consequences of acting on it (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?

The description is well-structured and front-loaded, starting with purpose, then usage, then return values, then alternatives. Every sentence adds value; no fluff or redundancy.

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 purpose, when to use, what it returns, potential risks, and the sibling tool alternative. Given the rich schema and annotations, nothing critical is missing. Output schema exists, so return value details are not required in the description.

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?

Schema description coverage is 100%, so the schema fully documents all four parameters. The description does not add additional parameter-level semantics beyond what is already in the schema. Baseline of 3 is appropriate.

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 the tool validates a document for internal consistency and completeness against applicable international standards, which is a specific verb+resource. It clearly distinguishes from the sibling tool check_document_package by noting when to use each, so purpose is unambiguous.

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 call (BEFORE approving payment, releasing funds, or accepting a document submission, at the moment a document arrives from an external party) and when to use the alternative (check_document_package for 2-20 related documents). This is excellent guidance with clear exclusion criteria.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0
Disambiguation5/5

The two tools have clearly distinct scopes: one validates a single document, the other validates a multi-document package. The descriptions explicitly cross-reference each other and state when to use which, leaving no ambiguity.

Naming Consistency5/5

Both tool names follow the same verb_noun pattern: 'check_document' and 'check_document_package'. The suffix '_package' clearly extends the base name without changing the verb style, resulting in a consistent, predictable naming scheme.

Tool Count3/5

With only two tools, the server feels thin for a domain that could include single-document validation, multi-document validation, and possibly standard lookup or generation. However, the two tools cover the two distinct input types, making the count borderline rather than clearly insufficient.

Completeness3/5

The tools cover single-document standard compliance and multi-document cross-checking, but the package tool only performs cross-document checks, not internal standard compliance. The description telling users to call check_document_package 'instead' of check_document is misleading—a full package validation would require running both tools sequentially, representing a notable gap.