agentcard

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 iPhone HEIC first).

Input Schema

TableJSON Schema

Name	Required	Description
`file_path`	No	Local 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_base64`	No	Base64 image bytes of the license back (optional, recommended — the barcode reads most accurately). Same rule: programmatically sourced only.
`front_base64`	No	Base64 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_type`	No	ONLY 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_path`	No	Local path to the back of the license (optional, recommended). Local/stdio connections only.
`back_mime_type`	No	MIME type of back_base64. Defaults to image/jpeg.
`front_mime_type`	No	MIME type of front_base64 (image/jpeg, image/png, image/webp). Defaults to image/jpeg.
`issuing_country`	No	2-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

Name	Required	Description
`status`	No	processed \| document_expired \| upload_failed \| upload_link_provided
`message`	Yes
`nextStep`	No
`extracted`	No	Fields read from the document (confirm with the user).
`uploadUrl`	No
`unreadable`	No	True 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.
`missingFields`	No
`verificationUrl`	No

Schema Changelog

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

First observedJul 28, 2026

TDQS

A5/5.0

Behavior5/5

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

The description discloses key behaviors beyond annotations: the tool returns extracted fields that should be shown to the user, if no details are read the image is not an ID (don't insist), supported formats (JPEG/PNG/WebP up to 12MB), and conversion of HEIC. Annotations only provide readOnlyHint=false and destructiveHint=false, so description adds significant value.

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 a single paragraph but well-structured: it starts with the core purpose, then enumerates the three input methods, followed by behavioral instructions, and ends with technical constraints. Every sentence is necessary and imparts actionable information without 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?

Given the complexity (8 parameters, multiple input modes, behavioral nuances), the description covers all aspects: input methods, parameter usage rules, format/size limits, and post-submission behavior (show results, handle failed reads). The presence of an output schema further reduces the need to describe return values.

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?

With 100% schema coverage, the description adds meaning beyond the schema: e.g., back_base64 is 'optional, recommended — the barcode reads most accurately'; front_base64 warns 'never type or reconstruct image bytes yourself'; document_type and issuing_country should only be passed if user volunteered. This prevents misuse.

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 clearly states the tool's purpose: 'Submit the user's ID photo for identity verification.' It specifies the verb 'submit' and resource 'ID photo for KYC'. It also distinguishes from siblings like check_kyc_document and start_kyc by focusing on the submission action.

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?

The description provides explicit guidance on when to use each parameter (base64 for programmatic data, file_path for local mode, or omit for upload link). It also instructs not to ask the user for document type or country unless volunteered, and when to relay questions from the result.

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

All agentcard tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0

Disambiguation4/5

Most tools have clearly distinct purposes, especially in areas like card management and shopping. However, the KYC flow has multiple overlapping tools (start_kyc, get_kyc_status, check_kyc_document, submit_kyc_document, submit_kyc_fields) that could confuse an agent despite detailed descriptions.

Naming Consistency4/5

Tool names consistently use snake_case with a verb_noun pattern (e.g., add_funds, create_card, list_cards). A few exceptions like surprise_me and whoami break the pattern but are still intuitive overall.

Tool Count3/5

50 tools is on the high side for a single server, but the broad domain (cards, shopping, KYC, support, settings) partially justifies it. Some tools could be merged (e.g., KYC flow tools) without losing clarity.

Completeness4/5

The tool surface covers core workflows: CRUD for cards, transactions, KYC, support, shopping, and account management. Minor gaps exist (e.g., no update_card general, no cancel order in shopping), but overall the set is comprehensive for the stated purpose.

Resources

Need Help?