Laso Finance

create_banking_account

Open an on-ramp or off-ramp account

Opens a banking rail. An on-ramp issues a virtual US bank account: dollars sent to it arrive as USDC in the managed wallet. An off-ramp pays out to a bank account you have registered, and is opened automatically by /send-bank-payment, so most agents never call this for one directly.

Free.

Input Schema

TableJSON Schema

Name	Required	Description
`rail`	No	The payment rail for the account.
`asset`	No	Crypto asset ticker, uppercase.
`networkId`	No	On-ramp only. Defaults to Solana mainnet.
`auth_token`	No	Laso credential. Only if the MCP connection has no Authorization header.
`accountType`	Yes	Which rail to open.
`capabilities`	No	On-ramp only. Bank rails to support. Defaults to ACH and wire.
`cryptoAddress`	No	On-ramp only. Where the converted USDC should land. Defaults to the managed agent wallet.
`fiatDestinationId`	No	Off-ramp only. The bank destination payouts go to, from `addBankingDestination`.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 26, 2026
- changedOutput schema / (root)
```
Previous value: -{
-  "type": "object"
-}New value: +null
```
First observedSep 26, 2026

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations provided, the description carries the full behavioral burden. It meaningfully explains what happens when an on-ramp or off-ramp is opened, notes the automatic off-ramp creation path, and discloses that the operation is 'Free.' It does not cover prerequisites like KYC or what the response contains, but it provides substantial behavioral context beyond a mere creation 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 well-organized and front-loaded: the primary purpose is in the first line, followed by bolded explanations of on-ramp and off-ramp. The 'Free.' note is economical. Minor redundancy exists between 'Open an on-ramp or off-ramp account' and 'Opens a banking rail,' but overall it is tight and scannable.

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?

Given the tool's moderate complexity, 8 parameters, and the absence of annotations and output schema, the description covers the key context: what the two account types do, when an off-ramp is unnecessary, and default behavior like the managed wallet. It could mention prerequisites such as a banking profile or KYC status, but the provided guidance is sufficient for most agents to decide whether and how to call it.

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 description coverage is 100%, so the baseline is 3. The description adds useful conceptual context about on-ramp vs off-ramp behavior, but it does not clarify ambiguous parameters such as 'rail' or 'capabilities' beyond what the schema already states. It is adequate but does not go further than 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 specific verb and resource: 'Open an on-ramp or off-ramp account.' It then explains what each account type does, and the second sentence, 'Opens a banking rail,' reinforces the core resource. This clearly distinguishes the tool from siblings like create_banking_profile or add_banking_destination.

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?

The description explicitly tells the agent when NOT to use this tool for off-ramps: it 'is opened automatically by /send-bank-payment, so most agents never call this for one directly.' It also implies the correct on-ramp use case: receiving dollars as USDC in the managed wallet. This gives concrete routing guidance relative to a named sibling.

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

All Laso Finance tools Inspect

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

Need Help?