Robinhood Crypto

robinhood-mcp

An execution toolkit for the official Robinhood Crypto Trading API, delivered over the Model Context Protocol.

Robinhood's crypto API exposes four order types and nothing else: market, limit, stop_loss, and stop_limit. There is no bracket, no OCO, no trailing stop, no TWAP, no iceberg, no scale-in ladder, no scheduled DCA, no portfolio rebalance. Those are the order types people actually want, and every one of them has the same requirement: something has to keep working after the request returns. A trailing stop that exists only for the duration of one tool call is not a trailing stop. This package synthesizes the thirteen order types Robinhood lacks and runs them as durable background jobs that survive the agent disconnecting, the server restarting, and the machine rebooting. Around that sit ~73 tools across 8 opt-in modules: quotes and holdings, FIFO cost basis and realized P&L, a trade journal, risk limits with an enforced kill switch, and integration diagnostics.

This is not Robinhood Chain, and it is not Robinhood equities. It targets the brokerage Crypto Trading API at trading.robinhood.com, documented at docs.robinhood.com/crypto/trading.

The signing bench — nirholas.github.io/robinhood-mcp

The project site is an interactive Ed25519 signing bench. You assemble a real Robinhood trading request and produce a genuine signature in your own browser — the math runs client-side on Robinhood's published example key, nothing is sent anywhere — then watch it disprove Robinhood's own documentation: their published test vector verifies against a Python dict repr, not the JSON body every client actually sends. It is a single self-contained page in docs/, so it deploys anywhere static.

Deploy your own copy in one click:

Safety

Robinhood publishes no sandbox. There is no paper account, no test environment, no dry-run host. Every order this package can place is real money in a real brokerage account, and there is no way to rehearse. Read this section before you set ROBINHOOD_CRYPTO_ENABLE_TRADING=1.

Every guard below is enforced in code, inside the single Executor that all orders pass through, never in a tool description. An instruction in a prompt is a suggestion; a thrown error is not.

Two things about those controls are worth stating plainly, because they are the ones people get wrong.

Autonomous removes the human, not the ceiling. The per-order cap, the cumulative cap, the allowlist and the buy-only flag all still apply in autonomous mode. An unattended agent is exactly the case where a runaway order is most likely and least observed.

The kill switch binds the daemon too. It lives beside the Executor rather than inside the risk tool module, because robinhood-mcp-daemon builds its own Executor and loads no tool modules at all. A halt installed by a module would leave the one unattended process in the system still placing orders. Because the state is read from disk on every order rather than cached, throwing the switch from an MCP session stops a daemon that has been running since before the switch existed. It fails closed: a row that cannot be parsed reads as *engaged*, because resuming trading over a corrupted row is exactly the failure a kill switch exists to prevent.

Two limits are honest about what they are not. The cumulative cap is a per-process, in-memory counter that resets on restart: it is a runaway-loop brake, not an accounting system or a hard budget. And a durable job's total spend is not capped at all. Per-order caps apply to each order a job places, but a TWAP with 50 slices under a $100 per-order cap can commit $5,000. Size jobs deliberately and check risk_status before starting anything unattended.

Finally, scope the API key itself. Robinhood lets you pick permissions per credential: if you only want reads, do not grant order placement, and the key cannot trade no matter what software holds it. IP allowlisting is also available and worth using.

Install

Requires Node.js 22.5 or newer (the durable job store uses node:sqlite).

Nothing to install ahead of time: MCP clients launch the servers with npx.

1. Create a credential

npx robinhood-keygen

This prints a fresh Ed25519 keypair as JSON on stdout, with instructions on stderr. Then:

1. Register the public key at robinhood.com/account/crypto. This page exists on web classic only, not the mobile app and not the new web UI.
2. Robinhood issues an API key in return. That is ROBINHOOD_CRYPTO_API_KEY.
3. Keep the private key as ROBINHOOD_CRYPTO_PRIVATE_KEY. It is a base64-encoded 32-byte Ed25519 seed, not a 64-byte expanded keypair and not PKCS#8. Several Ed25519 libraries export seed‖publicKey; pasting that gives 64 bytes and fails every request. Treat the private key like a password: it authorizes trades, and this package never stores or transmits it anywhere except in the signature it computes locally.

If you already have a keypair from elsewhere, verify_keypair (in the dev module) checks that a private key matches the public key you registered, without sending anything anywhere.

2. Add the server to your MCP client

Two binaries ship in the package, and they are separate on purpose.

Read-only. This is the one to start with, and the one to attach to a general-purpose assistant. Paste into claude_desktop_config.json (Claude Desktop), .mcp.json (Claude Code), or your client's equivalent:

{

"mcpServers": { "robinhood-crypto": { "command": "npx", "args": ["-y", "robinhood-mcp"], "env": { "ROBINHOOD_CRYPTO_API_KEY": "rh-api-...", "ROBINHOOD_CRYPTO_PRIVATE_KEY": "your-base64-seed" } } } }

Ask your assistant: *"What is my Robinhood crypto buying power, and what is BTC trading at?"*

Trading. A separate entry, because it places real orders:

{

"mcpServers": { "robinhood-crypto-trading": { "command": "npx", "args": ["-y", "robinhood-mcp-trading"], "env": { "ROBINHOOD_CRYPTO_API_KEY": "rh-api-...", "ROBINHOOD_CRYPTO_PRIVATE_KEY": "your-base64-seed", "ROBINHOOD_CRYPTO_ENABLE_TRADING": "1", "ROBINHOOD_CRYPTO_MAX_ORDER_USD": "50", "ROBINHOOD_CRYPTO_MAX_DAILY_USD": "500", "ROBINHOOD_CRYPTO_SYMBOL_ALLOWLIST": "BTC-USD,ETH-USD" } } } }

Set the caps to numbers you are comfortable losing. They are the only thing standing between a misunderstood instruction and a real fill.

You can run both entries at once. The data server is safe to leave attached permanently; add the trading server when you intend to trade.

If you have not set credentials yet

The data server still starts. Rather than exiting (which most MCP clients surface only as an opaque "server failed to start"), it comes up with a single get_setup_status tool that reports what is missing and how to fix it. If that is the only tool you see, credentials are not configured: set ROBINHOOD_CRYPTO_API_KEY and ROBINHOOD_CRYPTO_PRIVATE_KEY, then restart the server and the full tool set appears.

The trading server is deliberately stricter and refuses to start without ROBINHOOD_CRYPTO_ENABLE_TRADING=1, so it can never be launched by accident.

Modules

The toolkit is larger than any one agent should see at once. Every tool spends context and adds a wrong option to choose between, which measurably degrades tool selection, so capabilities ship as modules the operator turns on with ROBINHOOD_MCP_MODULES. Only the selected ones are registered.

| risk | Exposure, concentration, drawdown, pre-trade checks, and the enforced kill switch. | on | yes