Skip to main content
Glama

Laso Finance

by finance.laso
OverviewDiscussionsAdmin

withdraw

Destructive

Withdraw from account balance

Initiate a withdrawal from the user's account balance. The USDC is sent on Solana to the solana_address you supply; the destination is never inferred, so the address is required.

This is an asynchronous operation. A successful call answers 202 Accepted: the withdrawal is created in a pending state and sent within a few minutes. Poll the returned status_url (GET /get-withdrawal-status?withdrawal_id=...) until state reaches a terminal value rather than treating the 202 as completion.

This draws only on the Laso account balance, never on the managed agent wallet. USDC sitting in the agent wallet is moved with agentWalletTransfer instead. When the account balance is too low but the agent wallet holds funds, the 400 response says so and reports both figures.

An agent's withdrawal counts against the account's spend limits, the same as its payments and wallet sends: it must be under the per-payment limit and fit in what is left of the rolling 24-hour limit. Otherwise it is refused with 403 and code agent_spend_limit or agent_daily_limit, and nothing is withdrawn. Do not split it into smaller withdrawals to get under a limit; tell your human.

Input Schema

NameRequiredDescriptionDefault
amountYesAmount to withdraw in USD
solana_addressYesSolana wallet address that receives the USDC. Must be a valid base58 Solana address.

Output Schema

NameRequiredDescriptionDefault
successNo
status_urlNoAbsolute URL to poll for this withdrawal's state. Always present, including on an idempotent replay, so prefer it over the `Location` header.
withdrawalNoA withdrawal record.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedOutput schema / properties / status_url
      Added value: +{
+  "description": "Absolute URL to poll for this withdrawal's state. Always present, including on an idempotent replay, so prefer it over the `Location` header.",
+  "type": [
+    "string",
+    "null"
+  ]
+}
  2. 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": {
+    "success": {
+      "type": [
+        "boolean",
+        "null"
+      ]
+    },
+    "withdrawal": {
+      "description": "A withdrawal record.",
+      "properties": {
+        "amount": {
+          "type": [
+            "number",
+            "null"
+          ]
+        },
+        "id": {
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "solana_address": {
+          "description": "The Solana address the USDC will be sent to.",
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "state": {
+          "description": "One of: pending.",
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "timestamp": {
+          "type": [
+            "number",
+            "null"
+          ]
+        },
+        "timestamp_readable": {
+          "type": [
+            "string",
+            "null"
+          ]
+        }
+      },
+      "type": [
+        "object",
+        "null"
+      ]
+    }
+  },
+  "type": "object"
+}
  3. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "success": {
-      "type": [
-        "boolean",
-        "null"
-      ]
-    },
-    "withdrawal": {
-      "description": "A withdrawal record.",
-      "properties": {
-        "amount": {
-          "type": [
-            "number",
-            "null"
-          ]
-        },
-        "id": {
-          "type": [
-            "string",
-            "null"
-          ]
-        },
-        "solana_address": {
-          "description": "The Solana address the USDC will be sent to.",
-          "type": [
-            "string",
-            "null"
-          ]
-        },
-        "state": {
-          "description": "One of: pending.",
-          "type": [
-            "string",
-            "null"
-          ]
-        },
-        "timestamp": {
-          "type": [
-            "number",
-            "null"
-          ]
-        },
-        "timestamp_readable": {
-          "type": [
-            "string",
-            "null"
-          ]
-        }
-      },
-      "type": [
-        "object",
-        "null"
-      ]
-    }
-  },
-  "type": "object"
-}New value: +null
  4. First observed

TDQS

A4.6/5.0
Behavior5/5

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

With annotations declaring destructiveHint=true, the bar is lower, yet the description adds substantial context beyond them: asynchronous 202/pending lifecycle, the status_url to poll, and specific error codes (400 low-balance with both figures, 403 agent_spend_limit/agent_daily_limit). It also discloses that withdrawals count against per-payment and rolling 24-hour limits, which annotations cannot convey.

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-loads the core action and destination, then layers async behavior, balance scoping, and spend limits in separate paragraphs that each carry distinct information. Slightly long, but no sentence is pure filler and the ordering matches how an agent would need the facts.

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 destructive async withdrawal with an output schema present, everything an agent needs is covered: destination source, async lifecycle and polling, error semantics, and limit interactions. The output schema handles return shape, so the description is complete without over-explaining responses.

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%, so the schema already documents both parameters, giving a 3 baseline. The description reinforces requiredness and semantics of solana_address ('the destination is never inferred, so the address is required') but adds no format detail beyond the schema, which already states base58 validity.

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 ('Initiate a withdrawal from the user's account balance') and immediately pins the mechanism: USDC sent on Solana to a supplied address. It explicitly differentiates from siblings by contrasting with agentWalletTransfer and the managed agent wallet. An agent can distinguish this from withdraw_card_balance and move_agent_wallet_funds without opening a schema.

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?

Explicitly states when to use it (account balance funds) versus when to use the alternative (agent wallet funds -> agentWalletTransfer). It also gives failure-mode guidance ('Do not split it into smaller withdrawals... tell your human'), which is actionable when-to/when-not behavior rather than implied context.

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