Skip to main content
Glama

Laso Finance

by finance.laso
OverviewDiscussionsAdmin

fund_card_balance

Load a reloadable card balance

Pay USDC to load the account holder's reloadable card balance at the card issuer.

Why this exists: the card issuer only accepts USDC on Base, and a Laso managed agent wallet holds USDC on Solana. Pay this route from either chain and Laso bridges the payment to your own deposit address at the issuer over Circle's CCTP, which burns on the source chain and mints native USDC on Base.

Price: exactly the amount you are loading, and exactly that amount is credited to the balance. Loading $50 costs $50 and puts $50 on the card. Laso covers Circle's bridging fee by burning slightly more than requested.

A linked card issuer account is required. The account holder sets it up at https://laso.finance/agent/dashboard/verified/card.

Delivery starts once your payment settles. The response confirms the payment and returns a top_up_id; the transfer to your card balance follows and usually lands in under a minute. A payment made on Base is already on the issuer's chain, so it is forwarded without a bridge. Watch the top-up under top_ups in GET /list-card-transactions, where status moves paid → bridging → delivered → credited and the transaction hash behind each leg appears as it lands, or poll GET /get-card-deposit-address until balance reflects it.

Follow with POST /create-reloadable-card to create a card against the balance once it has arrived.

If the top-up's status becomes failed, nothing is stranded: the USDC you paid has credited your Laso account balance. Retry, or recover it with POST /withdraw.

PAID ROUTE (5-1000 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 of USDC to load onto the card balance (min $5, max $1,000). The x402 price equals this amount; Laso absorbs the bridge cost.
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": {
-    "asset": {
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "deposit_address": {
-      "description": "The account holder's own deposit address at the card issuer, on Base.",
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "funded_usd": {
-      "description": "USD loaded onto the card balance.",
-      "type": [
-        "number",
-        "null"
-      ]
-    },
-    "network": {
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "note": {
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "payment_network": {
-      "description": "The chain the payment settled on: `solana` (bridged to Base over CCTP) or `base` (forwarded directly).",
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "status": {
-      "description": "Always `paid` here: the payment settled and delivery to the card balance has started. Follow the later states in `GET /list-card-transactions`.",
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "top_up_id": {
-      "description": "Identifies this top-up under `top_ups` in `GET /list-card-transactions`.",
-      "type": [
-        "string",
-        "null"
-      ]
-    }
-  },
-  "type": "object"
-}New value: +null
  2. First observed

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description fully carries the behavioral burden and does so: it discloses payment settlement, CCTP bridging/burning/minting, exact fee behavior, status lifecycle (paid -> bridging -> delivered -> credited), response top_up_id, and failure recovery via withdraw. This is far beyond the minimal 'loads balance' statement.

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?

Although long, the description is front-loaded with the one-sentence purpose and uses bolded section headers (Why this exists, Price, Delivery, Failure) so an agent can scan efficiently. Each paragraph adds a distinct operational fact and none is filler.

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?

For a payment endpoint with no output schema or annotations, the description explains prerequisites, response behavior, status monitoring endpoints, post-conditions, and failure handling. An agent has enough to decide, execute, and verify the operation successfully.

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?

Schema coverage is 100% and already documents amount's min/max and x402 price. The description adds the valuable guarantee that the credited balance equals the paid amount and that Laso covers bridge cost by burning slightly more than the requested amount, which clarifies the financial contract beyond the schema.

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 opens with a clear verb and resource: 'Load a reloadable card balance' and 'Pay USDC to load the account holder's reloadable card balance at the card issuer.' It also explains the unique cross-chain bridging mechanism, which differentiates it from sibling actions like create_reloadable_card or withdraw_card_balance.

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?

It gives concrete usage context: a linked issuer account is required, the wallet must exist and be funded (get_agent_wallet), and the correct follow-up is POST /create-reloadable-card. It does not explicitly list when-not-to-use or name an alternative for the same goal, which keeps it just shy of a 5.

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