Otto Data — Robinhood Chain

execute_onchain_swap

Destructive

Execute a REAL on-chain swap on Robinhood Chain via the Rialto router, signed by Otto's server-side trading wallet. side=buy spends usd_amount USDG to buy the ticker's Hood token; side=sell sells qty tokens back to USDG. The server enforces hard guardrails independently of the caller: USDG<->allowlisted-token pairs only, per-trade and daily USD caps, and a slippage cap. On success the matching order_filled/position_closed event (payload mode=onchain, with tx_hash) is written automatically — the position book, performance stats and trade chart update without a separate report_agent_status call. key: the operator's OTTO_AGENT_KEY. agent: gap-trader | narrative-trader. Returns tx_hash, fill qty/price/usd and pnl_bps (sells with a known entry).

Input Schema

TableJSON Schema

Name	Required	Default
`key`	Yes
`qty`	No
`side`	Yes
`agent`	No	gap-trader
`reason`	No
`run_id`	No
`ticker`	Yes
`usd_amount`	No
`slippage_bps`	No

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations (destructiveHint, readOnlyHint false), the description adds critical real-world context: signing via server wallet, server-enforced guardrails (allowlisted pairs, USD caps, slippage cap), and automatic side effects (order_filled/position_closed events, position book updates). This fully discloses the consequences of calling the tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and packs essential operational details into four sentences. Every sentence adds value covering side semantics, guardrails, side effects, and return values, with no fluff or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (9 params, real-money mutation, multi-step effects), the description covers safety, auth, side effects, and return values, even without an output schema. It lacks error behavior and does not reference pre-swap quote workflow, but overall it is remarkably complete for such a high-stakes tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description compensates well by explaining key (OTTO_AGENT_KEY), side (buy vs sell semantics), usd_amount and qty roles, agent options, and slippage cap. However, reason and run_id are entirely unaddressed, and ticker is only implied, leaving a few gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a clear verb and resource: 'Execute a REAL on-chain swap on Robinhood Chain via the Rialto router'. It explicitly contrasts with paper trading ('REAL') and explains side=buy/side=sell semantics, making it unmistakably distinct from siblings like competition_paper_trade or partner_swap_quote.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides context on when to use (agent: gap-trader | narrative-trader) and explicitly states that on success no separate report_agent_status call is needed. However, it does not explicitly mention alternatives like partner_swap_quote for pre-trade quotes, so it stops short of a full when/when-not guide.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Otto Data — Robinhood Chain tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.6/5.0

Disambiguation4/5

Most tools have clearly distinct purposes, with detailed descriptions that separate e.g. hood_basis_snapshot from hood_basis_history and perp_spot_basis. A few clusters like flow_summary vs token_flows and multiple gap/basis tools could still cause slight ambiguity, but the descriptions are strong enough to guide correct selection.

Naming Consistency5/5

All tool names follow a consistent snake_case pattern with domain prefixes (hood_, agent_, competition_, partner_), and verbs are used predictably (report_, execute_, get_, etc.). There is no mixing of conventions or vague generic names.

Tool Count3/5

39 tools is on the high side, but the server covers a very broad domain (market data, signals, trading execution, competition, partner APIs, agent reporting). While many tools earn their place, a few could be consolidated (e.g., gap/basis variants), making it feel heavier than necessary for typical usage.

Completeness4/5

The surface covers the core lifecycle: market data, signals, paper/real/partner trading, position tracking, and performance reporting. Minor gaps exist (e.g., no explicit wallet balance or order cancellation), but the core workflows are well-covered and derived endpoints fill most needs.

Resources

Need Help?