Skip to main content
Glama

get_kyc_status

Get KYC verification status (optional)

KYC is optional. Most endpoints (cards, gift cards, push-to-card, account balance, withdrawals) do not require verification. It is only needed for certain features such as Venmo/PayPal payouts via /send-payment, and may be used for additional controls in the future. If you are not using those features, you can ignore the verification endpoints entirely.

Returns the calling wallet's cached KYC verification status. Use this as a free pre-flight check before paying for /send-payment: if kyc_verified is true the payout will go through. If it is false, don't call /send-payment yet — that call would not send the payout (it returns kyc_required and a kyc_url), and the USDC you paid would just land in your account balance, recoverable with POST /withdraw. To start verification when not verified, call /get-kyc-link.

This reads the cached status kept up to date by the verification webhook; it does not start verification or return a verification link.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
auth_tokenNoLaso credential. Only if the MCP connection has no Authorization header.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
      -  "properties": {
      -    "kyc_last_reviewed_at": {
      -      "description": "Epoch milliseconds of the last review, or null if never reviewed.",
      -      "type": [
      -        "number",
      -        "null"
      -      ]
      -    },
      -    "kyc_review_answer": {
      -      "description": "Latest review answer (e.g. GREEN for approved, RED for rejected), or null if never reviewed.",
      -      "type": [
      -        "string",
      -        "null"
      -      ]
      -    },
      -    "kyc_review_status": {
      -      "description": "Latest review status from the verification provider, or null if never reviewed.",
      -      "type": [
      -        "string",
      -        "null"
      -      ]
      -    },
      -    "kyc_verified": {
      -      "description": "Whether the wallet has completed identity verification. When true, /send-payment dispatches the payout. When false, /send-payment does not send: it returns kyc_required and the USDC paid lands in account balance (recoverable via POST /withdraw). Verify before calling /send-payment.",
      -      "type": [
      -        "boolean",
      -        "null"
      -      ]
      -    },
      -    "user_id": {
      -      "type": [
      -        "string",
      -        "null"
      -      ]
      -    }
      -  },
      -  "type": "object"
      -}New value: +null
  2. First observed

TDQS

A4.3/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full behavioral burden. It clearly states this is a read-only cached lookup: 'reads the cached status,' 'does not start verification or return a verification link,' and 'kept up to date by the verification webhook.' This gives strong non-mutation clarity, though it does not discuss cache freshness limits or rate limiting.

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?

The description is longer than strictly necessary, but every section contributes: optionality, when to use, behavioral guarantees, and alternative endpoints. The key information is front-loaded with 'KYC is optional' and the purpose statement before deeper payout-specific details.

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?

For a low-complexity tool with zero required parameters and no output schema, the description covers the return concept ('kyc_verified'), the side-effect-free nature, the webhook-backed cache, and the alternative verification flow. It is not a 5 because it does not fully specify the exact response shape or possible status values beyond true/false.

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 the optional auth_token parameter is already fully documented in the schema. The description adds only the context 'calling wallet's' but no new parameter-specific semantics, so baseline 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?

States a specific verb and resource: 'Get KYC verification status' and 'Returns the calling wallet's cached KYC verification status.' It also distinguishes itself from a sibling by explicitly noting it 'does not start verification or return a verification link,' which separates it from get_kyc_link.

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 guidance: 'Use this as a free pre-flight check before paying for /send-payment.' It also gives when-not-to-use context and alternatives: 'To start verification when not verified, call /get-kyc-link' and 'If you are not using those features, you can ignore the verification endpoints entirely.'

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