Skip to content

AI Agents & MCP

Rubin ships an official MCP (Model Context Protocol) server so that AI agents can trade and read account data without hand-rolling REST calls. The MCP server signs transactions with a scoped on-chain trading key, verifies fills, and enforces safety limits that raw REST cannot.

NetworkMCP endpoint (Streamable HTTP)Web app
testnethttps://mcp.testnet.rubin.trade/mcphttps://testnet.rubin.trade
mainnethttps://mcp.mainnet.rubin.trade/mcphttps://rubin.trade

The network is pinned per deployment — it is not part of the credential.

Connecting

claude.ai, Claude Desktop, ChatGPT (OAuth)

Hosts that support MCP OAuth discover it automatically (/.well-known/oauth-protected-resource, /.well-known/oauth-authorization-server, dynamic client registration):

  1. Add the MCP URL above as a custom connector / remote MCP server.
  2. The consent page redirects to the Rubin web app's authorize page.
  3. Connect a wallet and approve — the web app issues a scoped trading key for that account and completes the flow. The private key travels in a POST body, never in a URL, and never enters the model context.

Claude Code

claude mcp add --transport http rubin https://mcp.testnet.rubin.trade/mcp

Then run /mcp to authenticate (same OAuth flow as above).

Headless: static Bearer credential

For hosts without OAuth support (API integrations, Cursor, mcp-remote), the web app's More → API Trading Keys dialog issues a credential — base64(JSON) of:

{ "tradingPrivateKey": "<hex, omit for read-only>", "masterAddress": "rit1…" }

Send it as Authorization: Bearer <base64> on MCP initialize:

  • Anthropic Messages API: mcp_servers: [{ url, authorization_token }];
  • Cursor / VS Code mcp.json: "headers": { "Authorization": "Bearer <base64>" };
  • Any stdio host: npx mcp-remote https://mcp.testnet.rubin.trade/mcp --header "Authorization: Bearer <base64>".

Omit tradingPrivateKey for a read-only session (market data and account reads only).

What the trading key can and cannot do

The trading key is a Permissioned Key registered on-chain as an x/accountplus authenticator with the scope:

  • can: place order, cancel order, batch cancel — on subaccount 0 only;
  • cannot: withdraw or transfer funds, or touch any other subaccount.

This boundary is enforced by the chain, not by the MCP server. One authorization is bound to one account; to trade from another wallet, authorize the connector again from that wallet.

Accounts have two address forms — the same 20 bytes as 0x… and rit1…. Trading keys can be authorized directly by an EVM wallet signature (EIP-712). See Addresses: EVM & Native.

Agent skill

A ready-made skill teaches agents the Rubin workflow (connection, order flow, safety rules). Source: https://github.com/rubin-trade/skills

npx skills add rubin-trade/skills

Testnet funds

The testnet faucet is available in the web app's deposit flow, or via REST:

curl -X POST https://faucet.testnet.rubin.trade/faucet/tokens \
  -H "Content-Type: application/json" \
  -d '{"address": "rit1…"}'

Send the rit1 form. If you hold the address as 0x, convert it first — see Addresses: EVM & Native.