Skip to main content
Glama

Laso Finance

by finance.laso
OverviewDiscussionsAdmin

send_payment

Send a payment via Venmo or PayPal

Pay USDC to send money to a Venmo or PayPal recipient. The x402 USDC price is the requested amount plus a 4.9% fee (with a $1.50 minimum fee). On-chain payment credits the calling wallet's Laso account balance via the standard deposit webhook; the callable then debits the gross amount and dispatches the payout.

KYC required. The first time a wallet sends a Venmo or PayPal payout it must complete identity verification. If the wallet is not yet verified the response returns kyc_required: true and a kyc_url — open the URL, complete the flow, and retry. If you don't want to proceed, the credited account balance can be withdrawn with POST /withdraw.

Recipient details. Both Venmo and PayPal require the recipient's first name and last name. For Venmo, recipient_id is the recipient's 10-digit U.S. phone number and recipient_email is required. For PayPal, recipient_id is the recipient's PayPal email, which also serves as recipient_email (so recipient_email is optional).

Fee: 4.9% with a $1.50 minimum (included in the USDC price).

PAID ROUTE (6.50-1049 USD): the x402 USDC price is paid automatically from your managed agent wallet. Make sure the wallet exists and is funded first (get_agent_wallet).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
amountYesUSD amount to send to the recipient (min $5, max $1,000). The x402 payment price is this amount plus a 4.9% fee (with a $1.50 minimum).
platformYesPayment platform.
auth_tokenNoLaso credential. Only if the MCP connection has no Authorization header.
recipient_idYesRecipient identifier. For Venmo: 10-digit U.S. phone number. For PayPal: email address.
recipient_emailNoRecipient's email address. Required for Venmo. Optional for PayPal, where it defaults to recipient_id (the PayPal email).
recipient_last_nameYesRecipient's last name (English letters A-Z and a-z only).
recipient_first_nameYesRecipient's first name (English letters A-Z and a-z only).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
-  "anyOf": [
-    {
-      "properties": {
-        "amount": {
-          "type": [
-            "number",
-            "null"
-          ]
-        },
-        "auth": {
-          "properties": {
-            "expires_in": {
-              "description": "Token lifetime in seconds",
-              "type": [
-                "string",
-                "null"
-              ]
-            },
-            "id_token": {
-              "description": "ID token — use as Bearer token for Laso Finance APIs",
-              "type": [
-                "string",
-                "null"
-              ]
-            },
-            "refresh_token": {
-              "description": "Use with POST /auth (grant_type=refresh_token) to get a new id_token when it expires",
-              "type": [
-                "string",
-                "null"
-              ]
-            }
-          },
-          "type": [
-            "object",
-            "null"
-          ]
-        },
-        "callable_base_url": {
-          "type": [
-            "string",
-            "null"
-          ]
-        },
-        "message": {
-          "type": [
-            "string",
-            "null"
-          ]
-        },
-        "platform": {
-          "description": "One of: venmo, paypal.",
-          "type": [
-            "string",
-            "null"
-          ]
-        },
-        "recipient_id": {
-          "type": [
-            "string",
-            "null"
-          ]
-        },
-        "state": {
-          "description": "Payment lifecycle state (e.g. `in-process`, `queued`).",
-          "type": [
-            "string",
-            "null"
-          ]
-        },
-        "success": {
-          "type": [
-            "boolean",
-            "null"
-          ]
-        },
-        "user_id": {
-          "type": [
-            "string",
-            "null"
-          ]
-        }
-      },
-      "type": "object"
-    },
-    {
-      "properties": {
-        "amount": {
-          "type": [
-            "number",
-            "null"
-          ]
-        },
-        "auth": {
-          "properties": {
-            "expires_in": {
-              "description": "Token lifetime in seconds",
-              "type": [
-                "string",
-                "null"
-              ]
-            },
-            "id_token": {
-              "description": "ID token — use as Bearer token for Laso Finance APIs",
-              "type": [
-                "string",
-                "null"
-              ]
-            },
-            "refresh_token": {
-              "description": "Use with POST /auth (grant_type=refresh_token) to get a new id_token when it expires",
-              "type": [
-                "string",
-                "null"
-              ]
-            }
-          },
-          "type": [
-            "object",
-            "null"
-          ]
-        },
-        "callable_base_url": {
-          "type": [
-            "string",
-            "null"
-          ]
-        },
-        "kyc_required": {
-          "description": "One of: true.",
-          "type": [
-            "boolean",
-            "null"
-          ]
-        },
-        "kyc_url": {
-          "description": "URL the wallet owner must open to complete identity verification. No payout was sent, but the x402 payment you made was still credited to your Laso account balance. After verifying, retry /send-payment to dispatch the payout, or call POST /withdraw to pull the credited USDC back to your wallet.",
-          "type": [
-            "string",
-            "null"
-          ]
-        },
-        "message": {
-          "description": "Human-readable explanation of the KYC requirement and how to recover the credited funds via retry or POST /withdraw.",
-          "type": [
-            "string",
-            "null"
-          ]
-        },
-        "platform": {
-          "description": "One of: venmo, paypal.",
-          "type": [
-            "string",
-            "null"
-          ]
-        },
-        "recipient_id": {
-          "type": [
-            "string",
-            "null"
-          ]
-        },
-        "user_id": {
-          "type": [
-            "string",
-            "null"
-          ]
-        }
-      },
-      "type": "object"
-    }
-  ],
-  "type": "object"
-}New value: +null
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full transparency burden and meets it: it discloses the 4.9% fee with minimum, the on-chain credit/deposit-webhook mechanism, the debit from the callable, and the KYC verification gate with its kyc_required/kyc_url response. It also warns about the wallet-funding prerequisite for the paid route and offers the withdraw alternative. This goes well beyond a generic 'sends money' statement.

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 long but organized with bold headers and each section earns its place. The main redundancy is the fee being stated twice — once in the intro and again under 'Fee' — which could be consolidated. Overall, the density is justified by the amount of operational detail needed to make a cross-platform payout correctly.

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?

The description covers the KYC failure path, platform-specific recipient requirements, fee computation, and wallet funding prerequisites. Without an output schema, it leaves the successful response shape unspecified and doesn't mention polling via get_payment_status, but the information provided is sufficient to invoke the tool correctly and handle its main failure mode.

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?

Even with 100% schema coverage, the description adds critical meaning: it explains the per-platform interpretation of recipient_id (phone number vs. email), the conditional requirement of recipient_email, the English-letters-only constraint on names, and the fee formula tied to amount. This transforms schema fields into actionable rules an agent would otherwise have to guess at.

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 opening line, 'Send a payment via Venmo or PayPal,' uses a specific verb and resource, and the platform names immediately differentiate it from send_bank_payment. The description's scope is unambiguous: pay USDC to dispatch a payout on either platform. It also distinguishes itself from siblings like pay_x402_endpoint by explaining the payout 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 clearly states the payment mechanism, the KYC requirement, and the fallback withdrawal path, telling the agent what to do when kyc_required is true. It names the paid-route dependency on get_agent_wallet for funding. It doesn't explicitly say 'use send_bank_payment for bank transfers,' but the platform-specific framing makes the intended use obvious.

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

All Laso Finance toolsInspect
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