Laso Finance

start_signup

Start a signup for a human with no Laso account

Begins account creation for a human who does not have a Laso account yet. Requires no authentication, because the caller has no account.

This does not create the account. An agent cannot: the account is created in the human's own browser when they sign in, so it belongs to them and not to their agent. What this returns is a claim_url to hand over.

Give your human the claim_url verbatim in your very next reply (send message_for_human if unsure what to say), and do not open it yourself. Then poll GET /signup-status, which holds the connection open until they finish and hands you your lasoak_ API key.

Rate limited per IP.

Input Schema

Name	Required	Description	Default
`label`	No	Optional label recorded on the minted API key so your human can tell keys apart.
`agent_name`	No	Your name, shown to your human on the claim screen and recorded as the connected agent.

Output Schema

Name	Required	Description
`claim_url`	No	Give this to your human verbatim. Never open it yourself.
`claim_code`	No	The code inside claim_url. Pass it back to /signup-status alongside claim_token.
`expires_at`	No	Epoch ms when the claim link expires.
`expires_in`	No	Seconds until the claim link expires (86400).
`next_steps`	No
`claim_token`	No	Your receipt for this signup. Shown once; store it. Exchanged at /signup-status for your API key.
`agent_terms_url`	No	The Agent Terms your human accepts by finishing the claim link, as plain text. You act for them under these terms.
`message_for_human`	No	A ready-to-send reply containing the link. Send this as your next message.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 20, 2026

addedOutput schema / properties / agent_terms_url

Added value: +{
+  "description": "The Agent Terms your human accepts by finishing the claim link, as plain text. You act for them under these terms.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

Changed1 schema field changedSep 26, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "claim_code": {
+      "description": "The code inside claim_url. Pass it back to /signup-status alongside claim_token.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "claim_token": {
+      "description": "Your receipt for this signup. Shown once; store it. Exchanged at /signup-status for your API key.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "claim_url": {
+      "description": "Give this to your human verbatim. Never open it yourself.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "expires_at": {
+      "description": "Epoch ms when the claim link expires.",
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    "expires_in": {
+      "description": "Seconds until the claim link expires (86400).",
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    "message_for_human": {
+      "description": "A ready-to-send reply containing the link. Send this as your next message.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "next_steps": {
+      "items": {
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "type": [
+        "array",
+        "null"
+      ]
+    }
+  },
+  "type": "object"
+}

Changed1 schema field changedSep 26, 2026

changedOutput schema / (root)

Previous value: -{
-  "properties": {
-    "claim_code": {
-      "description": "The code inside claim_url. Pass it back to /signup-status alongside claim_token.",
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "claim_token": {
-      "description": "Your receipt for this signup. Shown once; store it. Exchanged at /signup-status for your API key.",
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "claim_url": {
-      "description": "Give this to your human verbatim. Never open it yourself.",
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "expires_at": {
-      "description": "Epoch ms when the claim link expires.",
-      "type": [
-        "number",
-        "null"
-      ]
-    },
-    "expires_in": {
-      "description": "Seconds until the claim link expires (86400).",
-      "type": [
-        "number",
-        "null"
-      ]
-    },
-    "message_for_human": {
-      "description": "A ready-to-send reply containing the link. Send this as your next message.",
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "next_steps": {
-      "items": {
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "type": [
-        "array",
-        "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?

Goes well beyond the annotations: discloses that it requires no authentication, that it does NOT actually create the account (creation happens in the human's browser), that it returns a claim_url, that polling holds the connection open until completion, and that it is rate limited per IP. This is the kind of context annotations cannot carry.

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?

Purpose is front-loaded in the first line, followed by the human-interaction protocol and the polling next step. Every sentence carries operational weight (auth exemption, non-creation, claim_url handling, rate limit) with no filler.

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?

With an output schema present, return values need not be re-explained. Given that, the description covers the auth posture, the full human-in-the-loop workflow, the follow-up call, and rate limiting — nothing an agent needs to call this correctly 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 description coverage is 100% and both optional parameters (label, agent_name) are fully documented in the schema. The description adds no additional meaning about either parameter, so it sits at the baseline where structured fields do the work.

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+resource ('Start a signup', 'Begins account creation') and immediately scopes it ('for a human who does not have a Laso account yet'). This cleanly separates it from siblings like get_signup_status (polling), create_agent_api_key, and get_auth_link without needing to open any 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 the triggering condition (human has no Laso account), the precondition (no authentication needed because the caller has no account), and the required follow-through (hand over claim_url verbatim next reply, do not open it, then poll GET /signup-status). When and when-not are both inferable and the next tool is named.

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?