Skip to main content
Limitless runs a remote Model Context Protocol (MCP) server that gives AI assistants direct, tool-based access to the exchange. An assistant connected to the server can browse and search markets, read orderbooks, check your balance and positions, and propose orders. You approve every order proposal in your browser before anything is submitted. Server URL:
The server uses the Streamable HTTP transport with plain JSON responses and OAuth 2.1 authorization.
This is the trading MCP server. It is separate from the docs MCP server at https://docs.limitless.exchange/mcp, which only exposes this documentation as searchable context. Connect both if you want an assistant that can look up API docs and act on the exchange.

​
How authorization works

The server implements OAuth 2.1 with the standard discovery flow, so any MCP client with remote server support can connect without pre-registered credentials:
  1. The client discovers the OAuth endpoints from https://api.limitless.exchange/.well-known/oauth-protected-resource.
  2. The client registers itself automatically via dynamic client registration. The server accepts only public clients with PKCE (S256).
  3. Your browser opens a Limitless consent page. Log in with your Limitless account and approve the connection.
  4. The client exchanges the authorization code for an access token with the trading scope. That is the only scope the server issues.
Access tokens expire after one hour. Clients refresh them automatically; refresh tokens are single-use and rotated on every refresh. Tokens are scoped to your selected Limitless Wallet. Every tool response that touches funds includes a walletContext object identifying that wallet. This keeps the assistant from confusing it with your login or embedded wallet.

​
Connect an assistant

Any MCP client that supports remote servers with OAuth works. For example, with Claude Code:
Or in a JSON-based MCP client configuration:
On first use, the client walks you through the browser login and consent flow described above.

​
Available tools

​
Market discovery

These tools work for any authenticated connection: To browse by category, the assistant first calls list_market_categories, then passes a returned path (for example /sport) as categoryPath to list_markets. Category responses include categoryFilters (filter groups with option values) that can be passed back as categoryFilter to narrow results further.

​
Portfolio reads

​
Trading

​
Order approval flow

The server is non-custodial. The assistant never holds your keys and cannot sign or submit orders on its own. place_orders only creates a proposal:
  1. The assistant calls place_orders with up to 10 limit orders. Each order specifies a market slug, side (BUY/SELL), outcome index (0 = YES, 1 = NO), a limit price between 0 and 1, shares, and an order type (GTC or FAK). Each order must be worth at least $1 (price × shares).
  2. The server validates the orders, attaches a fee preview per order, and returns an approvalUrl on limitless.exchange. The proposal expires after 600 seconds.
  3. You open the approval URL in your browser, log in with your own Limitless session, review the exact orders and fee previews, and approve or reject them. Approval requires your browser session. The assistant’s token cannot approve its own proposal.
  4. On approval, your wallet signs and submits the orders. The assistant polls check_order_status with the returned state to learn the outcome.
Fee previews show a worst-case taker scenario (ifTaker) calculated as a full taker fill at the limit price, and for GTC orders also a maker scenario (ifMaker). These are conditional scenarios, not predictions. Actual fees are calculated per fill.
Order cancellation does not require a browser approval. cancel_order and cancel_all_orders execute immediately with the connection’s trading scope.

​
Response conventions

  • Token and collateral amounts are raw integer strings. Format them with each market’s collateralToken.decimals (USDC uses 6). Prices are decimals between 0 and 1.
  • List and search responses default to orderableOnly: true. Markets have an orderable flag; groups have hasOrderableMarkets instead, and their child markets come from get_market_group.
  • Position snapshots are cached and can lag recent fills, transfers, or redemptions.
  • Orderbook midpoints are arithmetic and not executable prices.