Skip to main content
Glama
Sign In

Laso Finance

by finance.laso
OverviewDiscussionsAdmin

list_address_book

Read-onlyIdempotent

List saved recipients

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.

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
entriesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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": {
+    "entries": {
+      "items": {
+        "properties": {
+          "address": {
+            "description": "The recipient's Solana address. This is the entry's key.",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "last_used_at": {
+            "description": "When a transfer last went to this address, in milliseconds since epoch. Absent if never sent to.",
+            "type": [
+              "number",
+              "null"
+            ]
+          },
+          "name": {
+            "description": "The name your human gave this recipient.",
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "saved_at": {
+            "description": "When the entry was last saved or renamed, in milliseconds since epoch.",
+            "type": [
+              "number",
+              "null"
+            ]
+          },
+          "send_count": {
+            "description": "How many transfers have gone to this address.",
+            "type": [
+              "number",
+              "null"
+            ]
+          }
+        },
+        "type": [
+          "object",
+          "null"
+        ]
+      },
+      "type": [
+        "array",
+        "null"
+      ]
+    }
+  },
+  "type": "object"
+}
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "entries": {
-      "items": {
-        "properties": {
-          "address": {
-            "description": "The recipient's Solana address. This is the entry's key.",
-            "type": [
-              "string",
-              "null"
-            ]
-          },
-          "last_used_at": {
-            "description": "When a transfer last went to this address, in milliseconds since epoch. Absent if never sent to.",
-            "type": [
-              "number",
-              "null"
-            ]
-          },
-          "name": {
-            "description": "The name your human gave this recipient.",
-            "type": [
-              "string",
-              "null"
-            ]
-          },
-          "saved_at": {
-            "description": "When the entry was last saved or renamed, in milliseconds since epoch.",
-            "type": [
-              "number",
-              "null"
-            ]
-          },
-          "send_count": {
-            "description": "How many transfers have gone to this address.",
-            "type": [
-              "number",
-              "null"
-            ]
-          }
-        },
-        "type": [
-          "object",
-          "null"
-        ]
-      },
-      "type": [
-        "array",
-        "null"
-      ]
-    }
-  },
-  "type": "object"
-}New value: +null
  3. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, and the description does not contradict them. It adds useful behavioral context: the operation is free, scoped to the authenticated account's own book, has no user parameter, and names are labels rather than instructions for sending money. This goes beyond the structured annotations.

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 somewhat longer than needed and repeats the title phrase 'List saved recipients,' but each paragraph earns its place by adding use-case, cost, scope, and a safety warning. The core function is stated up front and the important warning about name resolution is clearly emphasized.

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 zero-parameter, read-only list operation with rich annotations and an output schema, the description provides everything an agent needs to invoke it correctly: purpose, usage scenario, account scope, cost, and a safety caveat. Nothing essential is missing.

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?

The input schema has zero properties, so there is no parameter to document. The description explicitly confirms this by saying there is no user parameter to pass, which is helpful for ruling out a common mistake. This meets the baseline for a zero-parameter tool.

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 description opens with 'List saved recipients' and explains that these are recipient names a human manages on their dashboard and can be resolved to an address. This clearly identifies a specific verb and resource. It does not explicitly contrast itself with sibling recipient-list tools like list_banking_recipients or list_payment_recipients, so it stops short of a 5.

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 gives a concrete use case: when a request names a saved recipient such as 'the coffee vendor', this tool resolves the name to an address rather than asking the human. It also states a scope constraint—it operates only on the authenticated account's own book. It does not name exclusions or alternatives, but the context is clear.

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