agentcard

start_kyc

Idempotent

Begin (or resume) identity verification. Verification is CONVERSATIONAL: it starts with a photo of the user's government ID — the backend reads the printed details automatically and the user confirms every value. Only fields the ID does not carry are asked (like the SSN for US documents, or the national ID number for non-US ones); occupation/income questions are never asked. The only browser step is a short face scan at the end. Relay each step to the user as ONE SHORT message (one or two sentences — the current ask only, never the whole flow, never an unrequested link). Returns the next step, ID-photo upload options, and (for legacy hosted-flow accounts) a hosted verification URL instead.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "start_kyc"
  }
}

Input Schema

Name	Required	Description	Default
`terms_accepted`	No	DEPRECATED — use agreements_accepted. Pass true once the user has explicitly agreed to the card issuer's cardholder terms in the conversation.
`agreements_accepted`	No	Keys of the User Agreements the user explicitly accepted, one by one (the full required set from the agreements list — e.g. e_sign, account_opening_privacy, card_terms, accuracy, non_solicitation). Only pass after presenting each agreement verbatim and getting a yes covering all of them.

Output Schema

Name	Required	Description
`reason`	No	Provider reason on rejection.
`status`	No	"started", "verified", "rejected", or "unknown".
`message`	Yes	Human-readable summary / next step.
`nextStep`	No	Conversational step: id_document \| fields \| terms \| face_verification \| review_pending \| verified \| rejected.
`uploadUrl`	No	Browser upload page for the ID photo (1h validity).
`missingFields`	No	Fields still needed from the user.
`verificationUrl`	No	Face-scan page (conversational flow) or hosted verification page (legacy flow). The link opens for at least 24 hours; call start_kyc again for a fresh one.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 30, 2026

changedOutput schema / properties / verificationUrl / description

Previous value: -"Face-scan page (conversational flow) or hosted verification URL (legacy flow), 48h validity."New value: +"Face-scan page (conversational flow) or hosted verification page (legacy flow). The link opens for at least 24 hours; call start_kyc again for a fresh one."

First observedJul 28, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations cover safety (readOnlyHint=false, destructiveHint=false, idempotentHint=true), and the description adds substantial context beyond that: conversational ID-photo-driven flow, backend auto-read plus user confirmation, only-missing-fields questioning, a single face-scan browser step, and the fact that legacy accounts receive a hosted URL instead. This is exactly the kind of flow-level behavior an agent could not infer from structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action, then progressively more detail; every sentence carries real operational content (ID photo, missing-field logic, face scan, message-length rule, return shape). It is dense with capitalized emphasis and em dashes rather than wasteful, but it verges on a wall of text for what is a zero-required-parameter call.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, yet the description still summarizes the return (next step, upload options, legacy hosted URL), and it explains the whole interaction model. The one gap is the agreements acceptance precondition, which is a real prerequisite for calling this correctly and is only documented inside the schema.

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 coverage is 100% and both parameters (terms_accepted deprecated, agreements_accepted) are fully documented in the schema. The description never mentions the agreements requirement at all, which is a notable omission given the schema's emphasis on passing the full required agreement set, but the baseline of 3 applies when the schema already carries parameter meaning.

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?

Specific verb+resource: "Begin (or resume) identity verification" — an agent immediately knows this is the KYC entry point, distinct from siblings like get_kyc_status, submit_kyc_fields, submit_kyc_document, and start_phone_verification. The parenthetical "(or resume)" also disambiguates it from a purely fresh-start flow.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context on when this applies and, unusually, what NOT to do (never ask occupation/income, don't dump the whole flow, don't send unrequested links). It stops short of explicitly naming alternatives such as get_kyc_status for checking status or submit_kyc_fields for individual field submission, so routing is implied rather than stated.

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

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?