> ## Documentation Index
> Fetch the complete documentation index at: https://docs.chance.cc/llms.txt
> Use this file to discover all available pages before exploring further.

# Robinhood

> Venue-aware verification for Robinhood Agentic Trading — pass the exact MCP tool call your agent is about to make, get a verdict bound to those bytes before the order executes.

Chance understands Robinhood's **Agentic Trading MCP** natively. Robinhood lets any MCP-capable agent (Claude, ChatGPT, Codex, Cursor, Grok) place real orders in a dedicated Agentic brokerage account — and if the user pre-authorized autonomy, those orders execute with **no per-trade confirmation**. Submit the exact tool call your agent is about to make (`place_equity_order`, `review_option_order`, …) and the harness will deterministically classify it, judge it against your mandate with a snapshot of Robinhood's agentic-trading documentation in the loop, and return a signed verdict whose `requestHash` binds to those exact bytes.

## What gets recognized

The MCP **tool name** is the discriminant — both the raw `tools/call` envelope and the simplified `{ name, arguments }` form are accepted (client prefixes like `mcp__robinhood-trading__…` are stripped):

| Family       | Tool calls                                                                                                                                                                                                                                                                                                                                                  |
| ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `order`      | `review_equity_order`, `place_equity_order`, `cancel_equity_order`, `review_option_order`, `place_option_order`, `cancel_option_order` — plus any unknown `place_*`/`review_*`/`cancel_*` order tool, which classifies as an order and is judged **fail-closed** (Robinhood ships new tools, e.g. the announced crypto rollout, without publishing schemas) |
| `subaccount` | Watchlist and scanner writes (`create_watchlist`, `add_to_watchlist`, `create_scan`, …) — account config, no funds at risk                                                                                                                                                                                                                                  |
| reads        | `get_portfolio`, `get_equity_quotes`, `get_option_chains`, … classify benignly so a gated agent's research never escalates                                                                                                                                                                                                                                  |

The classifier renders the captured argument schema faithfully: side, sizing (`quantity` shares vs `dollar_amount` notional), order type, limit/stop prices, session (`market_hours`), and the account — so the judge reasons over:

> *Robinhood EQUITY ORDER (place\_equity\_order): BUY $3,600 (dollar-denominated) TQQQ at market (market, tif gfd) = $3,600 notional, account 8A1B2C3D*

That framing is what catches the classic brokerage failures: the market order sized in shares with **no bounded notional in the payload**, the `stop_market` that fills far past its trigger in a gap, the extended-hours order under a regular-hours mandate, the option order whose contract is identified **only by an opaque `option_id` UUID** (underlying, strike, expiry and call/put are not in the payload — the classifier says so explicitly), and the `sell`-to-`open` leg that writes short options under a mandate that only ever contemplated buying them.

## Use it from Claude or ChatGPT

This is the primary integration: your agent already talks to Robinhood over MCP, so add the Chance connector (`https://harness.chance.cc/api/mcp`, see [Connectors](/connectors)) alongside it and give the agent one standing instruction:

> Before calling any Robinhood `place_*` or `review_*` tool, call `verify_intent` with my rules as the intent and the EXACT tool call — `{ "name": "place_equity_order", "arguments": { ... } }` — as the action, with `venue: "robinhood"`. Only proceed on ALLOW; on BLOCK or ESCALATE, stop and tell me why.

The harness never holds your Robinhood OAuth token — it judges the payload, your agent keeps the keys. Because Robinhood's `review_*` tools are the venue's own free order simulation, the natural loop is **review → verify → place**: run the review, pass its warnings to `verify_intent` as `context`, and only place on ALLOW.

## Use it from your bot

```ts theme={null}
const toolCall = {
  name: "place_equity_order",
  arguments: {
    account_number: "8A1B2C3D",       // the dedicated Agentic account — pin it in your mandate
    symbol: "VOO",
    side: "buy",
    type: "market",
    dollar_amount: "250.00",           // dollar-denominated market order — bounded notional
    time_in_force: "gfd",
    market_hours: "regular_hours",
    ref_id: crypto.randomUUID(),       // Robinhood dedupes retries by this
  },
};

const res = await fetch("https://harness.chance.cc/api/v1/intent", {
  method: "POST",
  headers: { "x-api-key": process.env.CHANCE_API_KEY!, "Content-Type": "application/json" },
  body: JSON.stringify({
    intent: "DCA into broad-market index ETFs only (VOO, VTI). Max $500 per order, market orders during regular hours only, account 8A1B2C3D only. Never leveraged or inverse ETFs.",
    venue: "robinhood",
    action: toolCall, // the exact tool call — the verdict binds to these bytes
  }),
});

const { verdict, reasoning } = await res.json();
if (verdict !== "ALLOW") throw new Error(`Blocked: ${reasoning}`);
// only now let the agent make the MCP call
```

`venue` is optional — Robinhood tool calls are auto-detected by name — but bare argument objects without a tool name are **not** auto-claimed (they are too generic); pass `venue: "robinhood"` explicitly for those, or better, always submit the full tool call.

## How the harness knows Robinhood

The judge works from a **versioned snapshot** of Robinhood's agentic-trading documentation — the connection and account model (dedicated Agentic account, read-only everywhere else, autonomous execution semantics), the full \~50-tool surface with the six order tools that move money, the captured argument schemas for equity and option orders, and the safety/rollout state — plus a curated brief of the venue's footguns: review-is-advisory-not-enforced, the unbounded share-sized market order, the opaque `option_id`, the per-contract vs per-share price ambiguity on options, the venue-authored `guide` field as an injection surface, and the fail-closed rule for unpublished order tools. Robinhood publishes no official schemas; the snapshot says exactly which claims are captured-not-guaranteed, and the judge is told to treat unfamiliar fields as unverified. Docs are never fetched at verdict time: the snapshot is reviewed like code, its version is hashed into every transcript, and each page the judge consults is chained with its content hash. See [Architecture](/concepts/architecture).

## What the receipt adds for Robinhood

On top of the standard proof bundle (transcript root, judge signature, onchain anchor), venue-aware verdicts carry `venue: "robinhood"`, the `actionFamily`, the venue `actionType` (the exact tool name — `place_equity_order`, `review_option_order`, …), `mode: "structured"`, and the knowledge-snapshot version — all inside the hash-chained transcript. For orders, the transcript records the exact symbol, side, sizing and account the verdict was issued against — an audit trail that pairs with Robinhood's own per-trade push notifications.

<Note>
  **Know the venue's own limits:** Robinhood-side controls are structural (a separately funded account, push notifications, one-tap disconnect) — there are no documented per-order dollar caps, and the OAuth grant is all-or-nothing. Your mandate enforced through Chance is the granular policy layer the venue doesn't provide.
</Note>