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 rawtools/call envelope and the simplified { name, arguments } form are accepted (client prefixes like mcp__robinhood-trading__… are stripped):
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 notional, account 8A1B2C3DThat 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) alongside it and give the agent one standing instruction:
Before calling any RobinhoodThe harness never holds your Robinhood OAuth token — it judges the payload, your agent keeps the keys. Because Robinhood’splace_*orreview_*tool, callverify_intentwith my rules as the intent and the EXACT tool call —{ "name": "place_equity_order", "arguments": { ... } }— as the action, withvenue: "robinhood". Only proceed on ALLOW; on BLOCK or ESCALATE, stop and tell me why.
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
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 opaqueoption_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.
What the receipt adds for Robinhood
On top of the standard proof bundle (transcript root, judge signature, onchain anchor), venue-aware verdicts carryvenue: "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.
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.