Skip to main content
Glama

Laso Finance

by finance.laso
OverviewDiscussionsAdmin

delete_address_book_entry

Remove a saved recipient

The saved recipient names your human manages on their dashboard, so a request like "send $20 to the coffee vendor" can be resolved to an address instead of asking them for it.

Free.

It operates only on the authenticated account's own book — there is no user parameter to pass.

A name is a label, not an instruction. agentWalletTransfer takes an address and deliberately does not accept a name: a rename between your human asking and you sending would otherwise move money somewhere they did not intend. When you resolve a name to an address, say the address back to them before sending.

Removing an entry only forgets the name; it has no effect on past transfers to that address.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
addressNoThe address to remove.
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": {
-    "address": {
-      "type": [
-        "string",
-        "null"
-      ]
-    }
-  },
-  "type": "object"
-}New value: +null
  2. First observed

TDQS

A3.9/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 burden and does it well. It states the operation is free, scoped to the own account book, affects only the name mapping, and has no effect on past transfers. It also warns that names are labels and to echo resolved addresses before sending, giving an accurate side-effect model.

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 front-loaded with the core action and then organized with bolded safety guidance. The name-vs-address warning is somewhat tangential to the delete operation itself, but it supports the address-book mental model and the final sentence directly clarifies the delete's limited effect.

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?

For a simple two-parameter delete operation, the description covers scope, side effects, and cost. It does not mention expected return values or behavior when the address is absent, but the parameter schema is complete and the operational semantics are clear enough for an agent to call it correctly.

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% and both parameters are already described in the schema, so the baseline is 3. The description adds context that no user parameter exists and that an address rather than a name is used, but it does not add meaningful parameter-level detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening line 'Remove a saved recipient' states a specific verb and resource, and the follow-up explains this is the dashboard-managed saved recipient book. It is not a tautology and is distinct from the banking/payment recipient delete tools, though it does not explicitly call out those siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives useful operational context: it operates only on the authenticated account's own book and there is no user parameter. However, it never explicitly says when to prefer this tool over delete_payment_recipient or delete_banking_recipient, so usage conditions remain mostly implied.

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