Robinhood Crypto

Start a synthetic order type as a durable background job, passing parameters as an untyped record. Prefer the per-strategy tools (algo_twap_start, algo_bracket_start, and so on): they declare the parameters that strategy actually takes, so a missing or misnamed field is caught by the schema rather than inside the job. Use this one only for a strategy assembled programmatically. THIS SPENDS REAL MONEY over time, not just once: the job keeps placing orders until it completes or is cancelled, and it survives this conversation, so cancel it explicitly when unwanted.

Follow the market with a stop that ratchets in your favour and never retreats, exiting the full size when price retraces past the trail. Robinhood has no native trailing stop. THIS SPENDS REAL MONEY OVER TIME, not just once: the job keeps placing orders until it completes or is cancelled, and it outlives this conversation. Cancel it with algo_cancel_job when it is no longer wanted. Per-order caps still apply to every order the job places, but the job total is not itself capped. Set exactly one of trail_percent or trail_amount. Until activation_price is reached (if given) the stop does not arm,…

Split one large order into evenly spaced slices over a duration, so the entry averages across the window instead of paying a single spread. THIS SPENDS REAL MONEY OVER TIME, not just once: the job keeps placing orders until it completes or is cancelled, and it outlives this conversation. Cancel it with algo_cancel_job when it is no longer wanted. Per-order caps still apply to every order the job places, but the job total is not itself capped. Without limit_price each slice is a market order, which is the usual TWAP and has no price guard. With limit_price a slice that would trade through it is…

Summarize trading performance from filled orders: win rate, average win and loss, profit factor, best and worst trades, and the largest drawdown in realized P&L. Use this to answer "am I actually any good at this".

Description is built at runtime.

Description is built at runtime.

Request cancellation of an open order by id. Cancellation is best-effort: an order that has already filled cannot be canceled. Confirm the resulting state with get_order.

Report which configuration variables are set and what each one currently does, without printing any secret value. Use this to answer "why is trading disabled" or "why was my order rejected" before changing anything.

Run every check that distinguishes the common causes of a 401 against this API: key format, derived public key, clock skew, and whether a live authenticated call actually succeeds. Run this FIRST when anything returns 401 or 403, instead of guessing. Never returns secret material.

Estimate what crossing the spread costs for a given size, using the live quote. Robinhood publishes no order book depth, so this models the quoted spread only and is a floor on true cost, not a simulation.

Show exactly what gets signed for a given request: the concatenated message, its components, and the resulting header. Use this when building a client in another language and its signatures are rejected, to compare byte for byte. Uses the configured credential but never reveals the private key.

Emit a runnable, correctly signed request in Python, TypeScript, or curl for any endpoint. Use this when a user wants to call the API from their own code rather than through this server. The signing logic is the same one this server uses.

Generate a fresh Ed25519 keypair in the format Robinhood expects. Register the PUBLIC key at robinhood.com/account/crypto (web classic only) and Robinhood issues an API key in return. The private key is returned once and never stored: treat it like a password.

Fetch the Robinhood crypto account: account number, status, and buying power. On API v2 this also includes fee-tier status. Use this to confirm credentials work and to check available buying power before sizing an order.

Current portfolio weights by asset, with each position valued at its live price. Use this before rebalancing, or to answer "how concentrated am I".

Current best bid and ask for one or more trading pairs. On API v1 the response includes the spread-inclusive prices actually used for execution (bid_inclusive_of_sell_spread / ask_inclusive_of_buy_spread) alongside the mid price. Use this to price an order before placing it.

Report how this server is configured: API version, base URL, and the public key derived from the configured private key: without revealing any secret. Use this first when authentication fails: if the public key shown here does not match the one registered with Robinhood, the wrong private key is configured.

Compute FIFO cost basis, open tax lots, and realized P&L from filled order history. Robinhood does not report any of this: it tells you what you hold and what it is worth now, not what you paid. Use this for "what is my average cost" and "how much have I actually made".

Estimated execution price for a given quantity, which accounts for depth rather than quoting only the top of book. Use side "ask" when buying and "bid" when selling. On API v2 the response also carries fee estimates.

Report the execution mode and every limit this server enforces, plus how much has been committed this session. Check this before planning a strategy so sizing fits the caps.

List crypto holdings with total quantity and the quantity available for trading. Optionally filter to specific asset codes (the base asset, e.g. BTC, not the BTC-USD pair).

Fetch a single order by its Robinhood order id, including its executions (fill price and quantity). Use this after placing an order to confirm the fill.

List orders, newest first, with optional filters by symbol, side, type, state, and creation/update time. Use this to review order history or to poll an order until it fills.

List every closed disposal with proceeds, cost basis, gain or loss, and whether the holding period exceeded one year. Use this for tax preparation and for answering "what did I actually realize this year".

Report why this Robinhood server has no working credentials and what to set. Every other tool is unavailable until credentials are configured, so call this first if no trading or market-data tools are listed.

List supported trading pairs with their minimum and maximum order sizes and price/quantity increments. Check these increments before placing an order: a quantity with too many decimals is rejected.

Annualized realized volatility for an asset, computed from prices you supply. Robinhood publishes no historical candles, so this cannot fetch its own series: pass one from your own records or another data source.

Per-day traded volume, buy and sell counts, and net realized P&L, in UTC days. Realized P&L is attributed to the day a round trip closed, not spread across the days it was held, so a day with a large number is the day a position was exited. Days with no activity are omitted rather than emitted as zeroes.

Render fills or round-trip trades as RFC 4180 CSV text for the user to save to a file. Fields containing a comma, a quote or a newline are quoted and internal quotes doubled, and a field that would otherwise be read as a spreadsheet formula is neutralised. This tool returns the CSV as text; it writes nothing to disk, so the caller is responsible for saving it.

List every execution in the account: time, pair, side, quantity, price, and notional, oldest or newest first. This is the raw tape, one row per fill rather than one row per order, because a single order can execute at many prices and the average hides that. Derived from filled orders returned by the API, so transfers in from another venue, staking rewards and airdrops do not appear. Use journal_trade_history when you want positions rather than executions.

List every order currently working, with its age, its resting price, how far that price sits from the live market, and whether it looks stale. A stale order is one that is both old and far from the market: it is not protecting anything and not going to fill, but it is still capital the account cannot use. Distance is measured against the side the order would actually cross, so a buy is compared to the ask. An order whose price or market cannot be resolved is reported with stale=null rather than a guess.

Aggregate performance over closed round-trip trades: total trades, win rate, average win, average loss, profit factor, largest win and largest loss, broken out per pair and overall. DERIVED FROM ROBINHOOD ORDER HISTORY ONLY. It excludes external transfers, deposits and withdrawals, assets moved in from another venue, staking rewards and airdrops, and it is before fees and taxes, so it is not a statement of account performance. It measures the trades this account executed, which is the question "am I trading well" actually asks.

Compare what this toolkit recorded that it submitted against what Robinhood actually reports, and list every disagreement. This is the audit an operator runs after a crash, a restart or an unexplained position. An intent is written to the local job database BEFORE the order is sent, so a crash in between leaves a record with no order, and the opposite (an order that exists while the local record says it failed) is the dangerous case worth finding. Absence is never inferred from an incomplete search: if the order history could not be walked far enough back, the verdict is "unresolved", not "mis…

Group executions into round-trip trades: a position from the first fill that opened it to the fill that closed it flat, with holding period and realized P&L for the whole trade. This is the unit a trader reviews, and it is deliberately not the same as a tax lot. get_realized_pnl matches individual FIFO lots for reporting; this matches whole positions for reviewing decisions, so one trade here can span several lots and several orders. A position still open reports a null P&L rather than a mark-to-market guess.

List which capability modules are loaded and which exist but are switched off. If a capability you need is listed as available but not loaded, tell the user which ROBINHOOD_MCP_MODULES value would enable it rather than reporting it as impossible.

Report which Robinhood API version this server is configured for, what differs between v1 and v2, and how to switch. The differences are not cosmetic: v2 orders count toward fee tiers and report fee information, most v2 endpoints require an account_number query parameter, estimated_price moves from /marketdata/ to /trading/, and v2 reports a partly-filled order as "pending" where v1 says "partially_filled". Code written against one version can fail against the other for any of those reasons.

Compare this machine's clock to Robinhood's, using the Date header on an API response. Every request is signed over a Unix timestamp and Robinhood rejects a signature more than 30 seconds old, so a drifting clock is one of the most common causes of a 401 that looks like a bad key. The measurement uses an unauthenticated request on purpose, so it still works when signing does not. Accuracy is bounded by the round trip and by the header's one second resolution, so a sub-second reading is noise, not signal.

Run health, clock skew, key check and API version in one call and return them as a single document to paste into a bug report or an issue. Every section is collected independently, so one failing section does not lose the others, and the whole document is scrubbed of credential material before it is returned: it contains the PUBLIC key (which is meant to be shared) and never the private key or the API key. Read the output before sharing it anyway, as a habit worth keeping.

Run the full startup check: credentials configured, private key usable, API reachable, signature accepted, account resolvable. Each check reports pass, fail or unknown, and every failure carries the specific remediation for that failure rather than a generic error. Run this first whenever anything is not working. A check reports "unknown" when it could not be performed, which is not the same as passing, and is never reported as one.

List order intents that were reserved but never settled. Each intent is written to the local database BEFORE the order is sent, so a row still marked pending means the process died somewhere between reserving and recording the outcome, and the order may or may not exist at Robinhood. This is the first thing to check after a crash. Do NOT resubmit these by hand: reconciliation looks each one up by its client_order_id and adopts the order if it exists, and a manual resubmit under a new id is how one intended fill becomes two real ones. Use journal_reconcile for the full comparison against Robinh…

Print the PUBLIC key derived from the configured private key, so it can be compared character for character against the key registered at robinhood.com/account/crypto. A mismatch here is the single most common cause of a 401: the private key in the environment belongs to a keypair whose public half was never registered, or was registered on a different credential. The private key and the API key are NEVER printed by this tool, only a non-reversible fingerprint of the API key so two installations can be told apart.

Report the client-side token bucket and the limits Robinhood documents: 100 requests per minute with a burst of 300. The bucket is a floor that keeps a well-behaved client under the global ceiling, not a mirror of Robinhood's accounting: the documented limits are per endpoint and vary, so a 429 is still possible while the local bucket shows tokens available. If the live token count cannot be read it is reported as unknown rather than assumed full.

Report whether durable jobs are actually being advanced: is the supervisor ticking in this process, how many jobs sit in each status, when the next one is due, and whether the standalone daemon is needed. This is the check for the failure that produces no error at all, where jobs exist and look healthy but nothing is moving them because the process that owned the tick loop exited. A TWAP that is not ticking is not slow, it is stopped.

Description is built at runtime.

Description is built at runtime.

Description is built at runtime.

Test a proposed order against every policy control WITHOUT placing it, and get back a plain allowed true or false plus exactly which control would reject it and why. Nothing is sent, no spend is committed, and no confirmation is implied. This is the pre-trade gate: call it for each leg before committing to a plan, so a multi-order plan fails on paper instead of halfway through with real money spent. It runs the same pricing and the same assertions a live order runs, so its verdict cannot drift from the real gate.

Flag every position worth more than a chosen percentage of the portfolio. Use it to answer "is any single asset too large a share of what I hold" before adding to a winner. By default this refuses to answer when some holding cannot be priced, because an unknown denominator makes every percentage wrong in the direction that hides a breach.

Largest peak-to-trough decline in total P&L (realized plus unrealized), rebuilt from filled order history and marked to the live price at the end. What it CANNOT see, and this matters: Robinhood exposes no deposit or withdrawal record here, so this is a P&L curve, not an account-balance curve, and a withdrawal will never appear as a decline. It is sampled only at the moments you traded, so a crash between two fills is invisible. It reaches back only as far as the order history the API returns, and a sell with no matching buy in that window is excluded rather than guessed at. Assets quoted in s…

Total and per-symbol USD exposure from the real account holdings, each valued at the live bid, with every position's share of the portfolio. This is what you are actually carrying right now, as opposed to what you paid for it. An asset that cannot be quoted is listed as unpriceable rather than counted as zero, and the result says so.

HALT ALL EXECUTION. Every order is refused at the executor from the moment this returns, and every running algo job is paused, so neither a tool call nor a background strategy can spend anything. The halt is written to disk, so it survives a restart of this server and of the daemon, and it stays in force until an operator explicitly releases it. Use it when something is going wrong and you would rather stop everything than work out what: a strategy behaving unexpectedly, a price that looks wrong, or a user saying stop. It does NOT cancel resting orders already at Robinhood: use cancel_order fo…

Resume execution after an emergency stop: orders are accepted again, subject to the usual limits, and the jobs this switch paused are set running again. Jobs paused for any other reason are left alone. Requires confirm=true, because releasing it is the act of turning real spending back on. Check risk_status first and satisfy yourself the reason it was engaged no longer applies.

Dump every limit this server enforces, with the environment variable that sets it, its current value, and what it does when it fires. Use it to answer "why was that refused" and "what would I change to allow it", and to hand an operator an exact list of what is configured rather than a description of what could be.

Work out how much to buy so that being stopped out costs a chosen fraction of the account, rather than picking a size and accepting whatever loss follows. Equity comes from the real holdings priced live unless you override it, the entry defaults to the live price, and the stop is given either as a price or as a distance in percent. The returned quantity is rounded DOWN to the venue increment, so it is a size that can actually be submitted, and the notional is recomputed from that rounded quantity. It fails rather than guesses if equity, the entry price, or the venue increment cannot be determi…

The complete picture of what this server will and will not do right now: execution mode, every configured limit, how much of the session spend allowance is already committed, whether the kill switch is engaged, and how many algo jobs are live. Call this first when an order was refused and the reason is not obvious, and before starting anything unattended.

Description is built at runtime.

Description is built at runtime.

Compute how much to buy so that hitting your stop loses a chosen percentage of the account, rather than picking a size first and accepting whatever loss follows. Returns the quantity, notional, and the exact dollar amount at risk.

Check whether a private key corresponds to a given public key, without sending anything anywhere. Use this when a 401 might mean the configured private key belongs to a different credential than the one registered with Robinhood.