Robinhood MCP Server: What 73 Tools and an OAuth Handshake Look Like Up Close

Robinhood’s trading MCP server lives at https://agent.robinhood.com/mcp/trading, identifies itself in its initialize response as robinhood-trading version 1.4.0, and enumerated 73 tools when this desk connected to it directly on 5 September 2026. Authentication is OAuth 2.0 with PKCE, with dynamic client registration and a refresh-token grant that returns an access token good for roughly nine days.

Every figure here comes from one read-only session run from our own terminal against our own account — no orders were placed, no order endpoints were called, and no balances, positions or account values are recorded anywhere below. Feature-level coverage of this server is easy to find; a tool count, a server version and a protocol transcript are not, which is the only reason to publish this.

What the server answered

The method was deliberately plain: raw JSON-RPC over HTTPS, no client framework in between, so that what is reported is what the server said rather than what a library decided to surface — a different instrument from our earlier run of a read-only market-data MCP server through a client.

What we asked	What the server returned
Endpoint	https://agent.robinhood.com/mcp/trading
Server name and version, from initialize	robinhood-trading v1.4.0
Tools enumerated by tools/list	73
Auth scheme	OAuth 2.0 with PKCE
Grant used	refresh_token
Access-token lifetime	~9 days
Scope returned	internal
Discovery metadata	/.well-known/oauth-authorization-server
Dynamic client registration	/oauth/trading/register
Calls made	initialize, tools/list, read-only tools/call only

Two of those rows do more work than they look like they do. A server that publishes discovery metadata and a dynamic-registration endpoint is built to be connected to by clients it has never seen — that is what DCR is for. And a nine-day access token is a long-lived credential by the standards of most brokerage sessions; whatever holds it is a thing worth treating as a key, not as a cookie.

The handshake, in the shape we ran it

# Illustrative — the shape of the read-only session run on 2026-09-05.
# No order endpoints were called.
tok = oauth_token({"grant_type": "refresh_token", "refresh_token": RT})
# -> access token, scope "internal", ~9-day lifetime

rpc("initialize", {"protocolVersion": ..., "clientInfo": {...}})
# -> serverInfo: {"name": "robinhood-trading", "version": "1.4.0"}

tools = rpc("tools/list")
len(tools)                                  # -> 73

rpc("tools/call", {"name": "get_accounts"})       # read-only
rpc("tools/call", {"name": "get_crypto_quotes"})  # read-only

That is the entire instrument. Anyone with an account and a refresh token can reproduce the two counts above in a few minutes, which is the property that separates this from a feature list.

The crypto surface was already there

The finding worth leading with is a negative one: there was no enable step, because none was needed. When we called get_accounts, the dedicated agentic account — a cash account — already carried a linked crypto account number. Nothing in the app had been toggled. The expansion had been flipped server-side, which means the announcement email is not an invitation to switch something on; it is a notification that something already is.

The tool surface matches. Enumerated in the same tools/list response:

Tool, as enumerated	What the name commits the server to
get_crypto_quotes	Live quotes — we verified one BTC-USD quote through the server, carrying a routing field reading “Exchange Routing”
get_currency_pairs	The tradeable pair list, which came back large and included long-tail assets
get_crypto_positions	Position reads, scoped to the connected account
get_crypto_orders	Order history reads
preview_crypto_order	A dry run, returned before anything is placed
place_crypto_order	The write path
cancel_crypto_order	The undo path

Crypto alerts and crypto watchlist items appear in the enumeration as well. The descriptions in the right column are our plain reading of each tool’s name and of the read-only calls we ran; we did not exercise the write tools, so nothing here is a claim about what they do when invoked.

The guardrails are in the protocol, not in your prompt

This is the design detail that will matter most to anyone building on it, and it is invisible from a feature page.

The write tools carry their safety rails in-protocol. The cancel and delete tools document a server-enforced confirmation step — enforcement sitting on the server rather than resting on the agent choosing to ask first. The place_* tools mirror a preview/review workflow, with tool documentation that tells the calling model to call the review tool before the placing tool. The constraint is expressed in the thing the model reads, not in the thing the developer remembers to write.

And the server steers presentation, not just data. get_accounts responses carry a guide field. That is a broker shaping how an agent should render and talk about an account, which is a different posture from simply serving JSON and letting every client invent its own interpretation.

Both are worth naming because the usual failure mode of an agent with an order endpoint is that the only thing standing between a bad plan and a filled order is a prompt. Here at least some of that lives one layer down.

The account boundary, in one line

The separation between the agentic account and an ordinary one is not a mode the agent is trusted to respect — it is a per-account field the broker sets, and it reaches past order permission to things like options approval level. That finding is the subject of its own comparison piece, and the wider question of how much of your account different connector designs can reach is the one we take apart in broker MCP servers.

What this session did not establish

Nothing about performance, and nothing about money. The positions call returned empty, and no balance, position size, profit, loss or account value was recorded by this session or appears in this write-up. Account numbers stay in the desk’s private records permanently. That is a standing rule here rather than a choice made for this page.

Nothing about the write path. We enumerated the order tools and read their documentation. We did not call them. A tool description is a statement of intent, not evidence of behaviour, and this desk does not test order placement on a live brokerage account to make a page more interesting.

Nothing about reliability. One session, one account, one terminal — well short of what our tool trial protocol asks for before a capability counts as tested. A count of 73 tools is a fact about 5 September 2026; servers version, and v1.4.0 is a number that exists precisely because it is expected to change. Re-run the two calls above rather than trusting this page’s figures in a month.

Nothing about whether you should do this. Connecting any agent to an account that can place orders is a decision with real downside, and the operational scaffolding it needs — kill switches, logging, the failure modes that only appear once something runs unattended — is a separate problem we work through in running an autonomous trading agent.

Frequently asked questions

Does Robinhood have an official MCP server?

Yes. This desk connected to it directly on 5 September 2026 at https://agent.robinhood.com/mcp/trading, on Robinhood’s own domain, and it answered the MCP initialize handshake identifying itself as robinhood-trading v1.4.0. That is a first-party server, not a community bridge driving a logged-in app.

How many tools does the Robinhood MCP server expose?

Seventy-three, as enumerated by a tools/list call on 5 September 2026. That count is a snapshot of that date and of the account the session authenticated as; the server carries a version number, so treat the figure as reproducible rather than permanent and re-run the call yourself.

How does authentication work?

OAuth 2.0 with PKCE. The server publishes discovery metadata at /.well-known/oauth-authorization-server and supports dynamic client registration at /oauth/trading/register. Our session used a refresh_token grant, which returned an access token with a lifetime of roughly nine days and a scope of internal. A credential with that lifetime should be stored like a key.

Did you have to turn on crypto for the agent?

No, and that was the session’s clearest finding. The dedicated agentic account already carried a linked crypto account number when we read it, with no toggle set anywhere. The change had been made server-side before we looked.

Did you place any orders through it?

No. Every call in this session was read-only — initialize, tools/list, and read-only tools/call invocations. No order endpoint was called, and no order was placed, previewed or cancelled.

Is this page sponsored?

No. This site has no affiliate relationship with Robinhood and carries no earning link on this page. Robinhood has not reviewed, seen or paid for any of it.

---

Educational content, not financial advice, and not a recommendation to connect an AI agent to any brokerage account. Doing so carries risk of loss, including total loss, and the responsibility for monitoring an agent’s activity sits with the account holder. All protocol details above are first-hand observations from a single read-only session dated 5 September 2026 and may change without notice.