Skip to main content
Glama

submit_kyc_document

Submit the user's ID photo for identity verification. Ways in: (a) image data you hold programmatically (e.g. the user sent the photo in this chat and your platform exposes its bytes) — pass front_base64 (and back_base64 for a license back; its barcode reads most accurately); (b) local (stdio) mode — pass file_path/back_file_path and the file is read from disk; (c) neither — you get a secure upload link to hand the user. Do NOT ask the user what kind of document it is or where it was issued — the type and country are detected automatically from the photo; only relay a question if the result says the type could not be determined. Returns the fields read off the document — SHOW THEM TO THE USER for confirmation before continuing — plus whatever is still missing. If the result says NO identity details could be read, the image did not read as an ID at all: never insist to the user that it was their ID. Supported: JPEG/PNG/WebP up to 12MB (convert HEIC or HEIF photos first).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
file_pathNoLocal path to the ID photo (front of license, or passport photo page). Local/stdio connections only — remote connections without image data receive an upload link instead.
back_base64NoBase64 image bytes of the license back (optional, recommended — the barcode reads most accurately). Same rule: programmatically sourced only.
front_base64NoBase64 image bytes of the ID front (or passport photo page). ONLY pass base64 you received programmatically from your platform (e.g. an injected chat attachment) — never type or reconstruct image bytes yourself.
document_typeNoONLY pass this when the user themselves said what the document is ("here's my license") — otherwise omit it; the type is detected from the photo. Never ask up front.
back_file_pathNoLocal path to the back of the license (optional, recommended). Local/stdio connections only.
back_mime_typeNoMIME type of back_base64. Defaults to image/jpeg.
front_mime_typeNoMIME type of front_base64 (image/jpeg, image/png, image/webp). Defaults to image/jpeg.
issuing_countryNo2-letter ISO country that issued the document (e.g. US, AR). ONLY when the user volunteered it — otherwise omit; it is detected from the photo. Never ask up front.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
statusNoprocessed | document_expired | upload_failed | upload_link_provided
messageYes
nextStepNo
extractedNoFields read from the document (confirm with the user).
uploadUrlNo
unreadableNoTrue when the image was received but NO identity fields could be read from it — it did not read as an ID; never assert to the user that it was one.
missingFieldsNo
verificationUrlNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A5/5.0
Behavior5/5

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

Goes well beyond annotations: discloses automatic detection, the need to show extracted fields to the user, the failure meaning, supported formats and size limit, and HEIC/HEIF conversion requirement. Annotations are only boolean hints; this text supplies the real behavior.

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?

Dense but structured with (a)/(b)/(c), and every clause carries operational value. The most important constraints (don't ask type/country, show extracted fields, failure handling) come after the input-method breakdown; no filler or repetition.

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?

Given the tool's complexity (8 params, multiple input modes, user-interaction constraints) and an available output schema, the description covers all deciding factors: when each input form applies, file requirements, and how to interpret/respond to results. No critical gap for an agent to invoke it correctly.

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 100%, and the description still adds meaning: front_base64 must be programmatically obtained and never reconstructed; document_type/issuing_country should only be passed when the user volunteered them; back barcode accuracy; local-only paths. This materially improves parameter selection beyond the 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?

Description states a specific action—submit the user's ID photo for identity verification—and distinguishes among three input modes (base64, local file path, upload link). The wording clearly separates this from similar KYC siblings like submit_kyc_fields/check_kyc_document by emphasizing automatic detection and submission of the photo itself.

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?

Provides explicit when-to-use routing by source of image data: (a) programmatic bytes, (b) local stdio paths, (c) otherwise upload link. Also gives when-not-to instructions: never ask document type/country, only ask if result says type undetermined, and never insist an unreadable image was an ID.

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.

Resources