Skip to main content
Laso Finance runs a real MCP (Model Context Protocol) server at:
It speaks streamable HTTP on MCP protocol revision 2026-07-28 and is stateless, so it works with every MCP client that can reach a URL: no session affinity, no SSE requirement. Clients on earlier revisions that still open with initialize are served too. The discovery record lives at https://laso.finance/.well-known/mcp/server-card.json. The server is published in the official MCP Registry as finance.laso/laso-finance. The finance.laso/ namespace is verified against this domain, so the registry entry and laso.finance point at each other. It is also listed on Smithery as laso/laso-finance.
The tools are generated from the live OpenAPI spec at runtime, not written by hand. When the API gains a route or a parameter, the MCP server picks it up automatically, so the tool set can never drift from the deployed x402 interface.

​
Connecting

Add the server by its URL. There is no key to paste:
The first time the client connects, it opens a browser tab at laso.finance/oauth/authorize. The human signs in to Laso (or creates an account in the same step) and approves the connection. The client stores the resulting credential and uses it from then on. In Claude Code, run /mcp and choose Authenticate if the tab does not open by itself. This is standard MCP authorization (OAuth 2.1 with PKCE, dynamic client registration, and client ID metadata documents), so it works in any client that supports it, including Claude Code, Claude, Cursor, Hermes, and Smithery. The approved connection is an ordinary Laso API key labelled with the client’s name: it appears with your other keys on the agent dashboard, where you can revoke it.

​
Clients without OAuth

A client that cannot run OAuth can send a Laso credential in the Authorization header instead: a lasoak_ API key (a human issues one at the agent dashboard, see the managed wallet guide) or a current id_token. A request with no credential at all gets a 401 that points at the OAuth metadata, so every tool requires one of the two.

​
What you get

The server also exposes the agent docs (SKILL.md, llms.txt, llms-full.txt, openapi.json, auth.md, the docs-version beacon) as MCP resources, fetched live so they are never stale.

​
How paid tools settle

Tools whose description is marked PAID ROUTE correspond to the x402-paywalled routes (order_card, order_gift_card, order_intl_card, push_to_card, send_payment, send_bank_payment). Over MCP you never build a payment header: the server settles the route’s USDC price from your managed agent wallet, exactly as if you had called agentX402Pay yourself. Before your first paid call:
  1. get_agent_wallet — check the wallet exists and read its balance (create_agent_wallet if it doesn’t).
  2. Fund the wallet’s Solana address with USDC.
  3. Call the paid tool. The price (face value plus the route’s fee) is settled automatically and the route’s response comes back as the tool result.
If you pay from your own wallet (Locus, Sponge, Ampersend) instead of a managed wallet, keep using the plain x402 HTTP API for paid routes: MCP’s paid tools settle only from the managed wallet.

​
Free tools and errors

Free routes (balances, card data, KYC status, webhooks, withdrawals, the gift card catalog) proxy directly with your bearer credential and return the route’s JSON as the tool result. Errors come back as tool errors carrying the route’s real error body, so the failure modes in error handling apply unchanged.

​
Events

The server supports MCP events (protocol revision 2026-07-28), so a client can be told when something happens on the account instead of polling. It advertises events in its server/discover capabilities and answers events/list, events/subscribe, and events/unsubscribe. There is one event, notification.created. It fires for every notification the account owner receives (a deposit landing, a card issued or declined, a refund or withdrawal settling, a balance change) and carries the same title and text they see in the app, by SMS, and by push. Verification codes are the exception: they are never sent as events. How a subscription behaves:
  • Credential. Subscribing needs an API key connection (OAuth, or a lasoak_ key). A subscription stops when the key that last subscribed it is revoked, so disconnecting the client in the Laso dashboard ends its events.
  • Limits. At most 10 subscriptions per account, and at most 10 callback verifications per hour.
  • Verification. Before storing it, the server POSTs a signed {"type": "verification", "challenge": "..."} to your callback. Answer 2xx with the challenge echoed (as {"challenge": "..."} or the bare value). A failure returns JSON-RPC error -32015 with data.reason (challenge_failed, timeout, unreachable, http_error, invalid_url). A URL already verified for your account is not challenged again.
  • Lifetime. Subscriptions last 7 days. Call events/subscribe again with the same arguments before refreshBefore to extend it; a shorter ttlMs is honored, and no-expiry is not granted. Re-subscribing with a new secret rotates it.
  • Delivery. One event per POST, signed per Standard Webhooks with your secret (webhook-id is the eventId, plus webhook-timestamp, webhook-signature, and X-MCP-Subscription-Id). Timeouts, 429, and 5xx are retried with backoff under the same eventId, so deduplicate on it. Answering 410 removes the subscription.
  • No replay. Notifications are not replayable: cursor is always null.

​
Docs search with no account

Everything above is the product surface: it takes actions, so every tool needs a credential. There is a second, separate MCP server that covers the documentation, and it needs no account and no key:
It speaks streamable HTTP, takes no authentication, and is read-only. It has two tools: Connect it the same way, under its own name:
Adding both is the normal setup, and the docs server is the one to add first, because connecting it costs nothing and commits nothing. Use it to settle the questions that come before a credential exists: which route does the job, what a fee is, what an error means, whether a product covers a given country. Then use https://laso.finance/mcp to make the call.
The product server also carries a search_docs tool over the same content, so a client that already holds a Laso credential does not strictly need both. The docs server exists for the case that comes first: an agent evaluating Laso before anyone has signed up.

​
Staying in sync

The MCP surface inherits the docs-freshness machinery:
  • The tool set refreshes from the deployed openapi.json within about ten minutes of a docs deploy.
  • get_version returns the current docs_version; the beacon at https://laso.finance/.well-known/docs-version.json is authoritative.
The HTTP API remains the canonical surface. MCP is a transport over it, so everything in the rest of these docs (fees, limits, flows, error semantics) applies verbatim.