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.
| Network | MCP endpoint (Streamable HTTP) | Web app |
|---|---|---|
| testnet | https://mcp.testnet.rubin.trade/mcp | https://testnet.rubin.trade |
| mainnet | https://mcp.mainnet.rubin.trade/mcp | https://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):
- Add the MCP URL above as a custom connector / remote MCP server.
- The consent page redirects to the Rubin web app's authorize page.
- 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/mcpThen 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/skillsTestnet 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.