Skip to main content
Glama

get_kyc_link

Read-onlyIdempotent

Get a KYC verification link (optional)

KYC is optional. 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.

Returns a one-time identity-verification link (kyc_url) for the calling wallet. Open it (or hand it to the wallet owner) to complete verification. The typical flow is: call /get-kyc-status, and only if kyc_verified is false call this to get a link, complete it, then proceed to /send-payment.

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
kyc_urlNoOne-time URL to open to complete identity verification.
user_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • removedInput schema / properties / auth_token
      Removed value: -{
      -  "description": "Laso credential. Only if the MCP connection has no Authorization header.",
      -  "type": "string"
      -}
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "properties": {
      +    "kyc_url": {
      +      "description": "One-time URL to open to complete identity verification.",
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "user_id": {
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    }
      +  },
      +  "type": "object"
      +}
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
      -  "properties": {
      -    "kyc_url": {
      -      "description": "One-time URL to open to complete identity verification.",
      -      "type": [
      -        "string",
      -        "null"
      -      ]
      -    },
      -    "user_id": {
      -      "type": [
      -        "string",
      -        "null"
      -      ]
      -    }
      -  },
      -  "type": "object"
      -}New value: +null
  3. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral context beyond that: the link is one-time, meant to be opened or handed to the wallet owner, and is part of a larger verification flow. No contradictions 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.

Conciseness4/5

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

The description is appropriately sized and well-structured, front-loading the optional nature of KYC and then explaining the flow. A minor redundancy exists in repeating that KYC is optional, but overall each section earns its place.

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 output schema exists, the annotations cover safety/idempotency, and there are no parameters, the description is complete. It explains why the tool exists, when to use it, what it returns, and how it fits with `get-kyc-status` and `send-payment`.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and schema description coverage is 100%, so the description does not need to explain parameters. The baseline is therefore strong, and the description correctly focuses on behavior and flow rather than parameter details.

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 gets a one-time identity-verification link (`kyc_url`) for the calling wallet, with the explicit verb 'Get' and specific resource. It also differentiates itself from related endpoints like `get-kyc-status` by describing the verification flow.

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?

It explicitly says KYC is optional and only needed for certain features such as Venmo/PayPal payouts via `/send-payment`. It also prescribes a clear conditional flow: call `/get-kyc-status` first, and only call this if `kyc_verified` is `false`. This gives strong when-to-use and when-not-to-use guidance.

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