Laso Finance

get_signup_status

Read-onlyIdempotent

Wait for your human to finish the signup

Long-polls until the human opens the claim link and finishes creating the account. Holds the connection open for about 60 seconds and returns 204 No Content if they have not finished yet.

Retry on 204 and nothing else. The call already blocks for you, so add no sleep between attempts. Every other status is final and retrying will not change the answer: 401 means the token is wrong, 410 means the link expired. Both carry "terminal": true in the body. A loop written as "retry until 200" spins at network speed against those, because they answer instantly rather than holding the connection.

On completion it returns your api_key — delivered exactly once. Store it before doing anything else; a later poll returns the account without it. By that point the human is on their dashboard, their agent wallet is provisioned, and you are already recorded as their connected agent, so announceAgentConnection is not needed on this path.

Input Schema

Name	Required	Description	Default
`claim_code`	Yes	The claim_code from the same POST /signup response.
`claim_token`	Yes	The claim_token from POST /signup.

Output Schema

Name	Required	Description
`auth`	No	An id_token / refresh_token bundle you can use immediately.
`status`	No
`api_key`	No	Your lasoak_ key. Delivered EXACTLY ONCE — null on any later poll.
`user_id`	No	The Laso user id of the new account.
`next_steps`	No
`api_key_note`	No	Present only when api_key is null, explaining that it was already delivered.
`callable_base_url`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 26, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "api_key": {
+      "description": "Your lasoak_ key. Delivered EXACTLY ONCE — null on any later poll.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "api_key_note": {
+      "description": "Present only when api_key is null, explaining that it was already delivered.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "auth": {
+      "description": "An id_token / refresh_token bundle you can use immediately.",
+      "type": [
+        "object",
+        "null"
+      ]
+    },
+    "callable_base_url": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "next_steps": {
+      "items": {
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "type": [
+        "array",
+        "null"
+      ]
+    },
+    "status": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "user_id": {
+      "description": "The Laso user id of the new account.",
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "type": "object"
+}

Changed1 schema field changedSep 26, 2026

changedOutput schema / (root)

Previous value: -{
-  "properties": {
-    "api_key": {
-      "description": "Your lasoak_ key. Delivered EXACTLY ONCE — null on any later poll.",
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "api_key_note": {
-      "description": "Present only when api_key is null, explaining that it was already delivered.",
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "auth": {
-      "description": "An id_token / refresh_token bundle you can use immediately.",
-      "type": [
-        "object",
-        "null"
-      ]
-    },
-    "callable_base_url": {
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "next_steps": {
-      "items": {
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "type": [
-        "array",
-        "null"
-      ]
-    },
-    "status": {
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "user_id": {
-      "description": "The Laso user id of the new account.",
-      "type": [
-        "string",
-        "null"
-      ]
-    }
-  },
-  "type": "object"
-}New value: +null

First observedSep 26, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already mark this as read-only, idempotent, and non-destructive, but the description adds substantial behavioral detail: it blocks for ~60 seconds, returns 204 on incomplete signup, treats 401/410 as terminal with 'terminal': true, and delivers api_key exactly once. This goes far beyond the annotations and gives the agent a precise mental model.

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?

The description is long but every sentence earns its place: it front-loads the core purpose, then covers retry behavior, terminal statuses, and the one-time api_key delivery in a structured, bolded format. No filler or repetition beyond the title echo.

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 long-polling tool with an output schema, the description covers all essential context: blocking behavior, status code semantics, retry policy, terminality, api_key delivery, and downstream implications like not needing announceAgentConnection. Nothing critical is missing.

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%, with both claim_token and claim_code described as coming from POST /signup. The description does not add extra parameter-level meaning beyond that, so the baseline of 3 applies.

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: 'Wait for your human to finish the signup' and then explains the long-polling behavior. It clearly distinguishes itself from siblings like start_signup and announce_connection by describing exactly what this tool does and what it does not do.

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 gives explicit when-to-use and when-not-to-use guidance: 'Retry on 204 and nothing else', 'Every other status is final', and 'announceAgentConnection is not needed on this path'. It also warns against a naive 'retry until 200' loop, which is actionable and prevents misuse.

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?