Skip to main content
Glama

Laso Finance

by finance.laso
OverviewDiscussionsAdmin

register_webhook

Register a notification webhook (free)

Registers (or replaces) an HTTPS webhook URL to receive the calling wallet's account notifications as signed POSTs — banking application status changes, bank transfer and payout completions, agent wallet deposits, card orders, and every other event the user is notified about. This closes the polling gap for agents: instead of re-fetching status endpoints, point this at any URL you can receive HTTP on (your harness's inbound webhook endpoint, or a relay you poll).

Deliveries are signed per the Standard Webhooks specification (https://www.standardwebhooks.com/): each POST carries webhook-id, webhook-timestamp, and webhook-signature (v1,<base64 HMAC-SHA256>) headers verifiable with any standard-webhooks library using the returned secret. The body is {"type": "notification.<category>", "timestamp": "<ISO 8601>", "data": {"user_id", "title", "text", "category"}}.

The secret is returned exactly once, by this call. Re-registering rotates the secret, replaces the URL, and re-enables a registration that was auto-disabled after 50 consecutive failed deliveries. Registering also notifies the account owner through their other channels and fires a first signed test delivery (type notification.account) at the new URL.

Deliveries time out after 10 seconds and are not retried; treat the webhook as a low-latency hint and the status endpoints as the source of truth. The URL must be public HTTPS.

Input Schema

NameRequiredDescriptionDefault
urlYesPublic HTTPS URL to receive signed notification POSTs. Max 512 characters. Private/internal hosts are rejected.

Output Schema

NameRequiredDescriptionDefault
urlNo
secretNoStandard Webhooks signing secret (`whsec_...`). Shown only in this response — store it now. Rotate by re-registering.
signingNoAlways `standard-webhooks`.
registeredNo

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": {
+    "registered": {
+      "type": [
+        "boolean",
+        "null"
+      ]
+    },
+    "secret": {
+      "description": "Standard Webhooks signing secret (`whsec_...`). Shown only in this response — store it now. Rotate by re-registering.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "signing": {
+      "description": "Always `standard-webhooks`.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "url": {
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "type": "object"
+}
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "registered": {
-      "type": [
-        "boolean",
-        "null"
-      ]
-    },
-    "secret": {
-      "description": "Standard Webhooks signing secret (`whsec_...`). Shown only in this response — store it now. Rotate by re-registering.",
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "signing": {
-      "description": "Always `standard-webhooks`.",
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "url": {
-      "type": [
-        "string",
-        "null"
-      ]
-    }
-  },
-  "type": "object"
-}New value: +null
  3. First observed

TDQS

A4.6/5.0
Behavior5/5

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

The description discloses rich behavioral detail beyond the sparse annotations: registering replaces the existing webhook, rotates the secret, re-enables disabled registrations, sends a test delivery, notifies the account owner, times out after 10 seconds, and does not retry. It also documents the signing headers and one-time secret return. This fully informs the agent of side effects and operational constraints.

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 longer than average but every paragraph adds distinct operational detail: registration semantics, signing format, failure/disabling behavior, and delivery timeout. Small redundancies such as 'free' and repeated HTTPS requirements exist, but the structure is logical and front-loaded with the core purpose.

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 tool with one well-documented parameter and an output schema, the description is complete. It explains the returned secret, webhook payload shape, signature verification, replacement behavior, disable condition, timeout policy, and the relationship to status endpoints. An agent has everything needed to invoke and interpret this tool correctly.

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?

Schema coverage is 100% and the schema already documents the URL requirements. The description adds context about what kind of URL is acceptable ('your harness's inbound webhook endpoint, or a relay you poll') and reinforces that private/internal hosts are rejected. This goes beyond the schema without being redundant.

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 uses a specific verb and resource: 'Registers (or replaces) an HTTPS webhook URL to receive the calling wallet's account notifications as signed POSTs.' This clearly differentiates it from sibling tools like get_webhook and delete_webhook. The scope and effect are unmistakable.

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 clear context for when to use the tool: 'This closes the polling gap for agents: instead of re-fetching status endpoints, point this at any URL...' It also explains delivery limitations and directs agents to treat status endpoints as the source of truth. It does not explicitly name alternatives/exclusions, but the context is strong enough for an agent to decide.

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