Ironflow: Hyperliquid data

Start a strategy on a paper box

start_box_strategy

Start a strategy on a Hyperliquid paper box: it runs around the clock with no client connected, in simulation only. No key needed, the box URL authorises it, so a trial box from create_ironbox works. kind is breakout (size_usd, lookback_bars, exit_bars, bar_seconds), grid (lower_px, upper_px, grids, size_usd) or dca (tranche_usd, budget_usd, dip_pct, interval_minutes, take_profit_pct, repeat). Every kind needs market and max_loss_usd: when the net loss reaches it, the strategy closes its position and stops. At most 3 per box, one per market. Follow it with get_box_activity.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "box": "<box>",
      "kind": "<kind>",
      "market": "<market>",
      "max_loss_usd": "<max_loss_usd>"
    },
    "name": "start_box_strategy"
  }
}

Input Schema

Name	Required	Description
`box`	Yes	The paper box: its base_url from create_ironbox, or the ibxs_ secret
`kind`	Yes	Which strategy
`side`	No	breakout: long, short or both (default both). grid and dca: long (default) or short
`grids`	No	grid: rungs, 2 to 25, default 10
`market`	Yes	A live main perp, by display symbol or Hyperliquid name, e.g. BTC-PERP or BTC
`repeat`	No	dca: start a new cycle after a take profit
`dip_pct`	No	dca: move against the last entry that buys the next tranche, default 3
`leverage`	No	Cross leverage on this market, default 3
`lower_px`	No	grid: bottom of the ladder
`size_usd`	No	breakout: notional of each entry. grid: total across the ladder, at least 10 a level
`upper_px`	No	grid: top of the ladder
`exit_bars`	No	breakout: exit channel, default half of lookback_bars
`budget_usd`	No	dca: total notional across the cycle
`bar_seconds`	No	breakout: 60 (default), 300 or 900
`tranche_usd`	No	dca: notional of each entry
`max_loss_usd`	Yes	Net loss in USD that stops the strategy (required)
`lookback_bars`	No	breakout: entry channel, 5 to 120 bars, default 20
`take_profit_pct`	No	dca: close the stack at this gain on the average entry
`interval_minutes`	No	dca: also buy a tranche after this long

Output Schema

Name	Required	Description
`paper`	No	true
`notice`	No	Present when the API added a note: how a market name was read, that data starts later than asked because of the history window, or a next step such as a free key
`strategy`	No	One strategy on a paper box

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 8, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the annotations it discloses behavior that matters: the strategy runs continuously with no client connected, it is simulation-only, no API key is needed because the box URL authorises, and max_loss_usd triggers a position close plus shutdown. The per-box and per-market caps are operational limits an agent could not infer from the schema or hints.

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

Conciseness4/5

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

The core action and its no-key/simulation nature are front-loaded, and every sentence carries information. The dense mid-section of three parenthetical parameter lists is harder to scan than a short bulleted breakdown would be, but nothing is redundant.

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?

For a 19-parameter mutation tool this is close to complete: required fields, kind-specific fields, stop condition, capacity limits and the natural next call are all covered, and an output schema exists so return values need not be described. Only the optional side/leverage defaults and failure behavior are left entirely to the schema.

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?

Schema coverage is 100%, so the baseline is 3; the description goes further by grouping parameters under each kind (breakout: size_usd, lookback_bars, exit_bars, bar_seconds; grid: lower_px, upper_px, grids, size_usd; dca: tranche_usd, budget_usd, dip_pct, interval_minutes, take_profit_pct, repeat). It also explains the runtime meaning of max_loss_usd as a net-loss stop, which the schema only labels.

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 specific verb+resource ('Start a strategy on a Hyperliquid paper box') and immediately clarifies it is a server-side, simulation-only runner. It also enumerates the three strategy kinds, which distinguishes this tool from list_box_strategies, stop_box_strategy and create_ironbox without requiring the agent to open a schema.

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 states the prerequisite (a box from create_ironbox, or its ibxs_ secret) and the follow-up (get_box_activity), plus the hard constraint of at most 3 strategies per box and one per market. It never explicitly says when to prefer list_box_strategies or stop_box_strategy, so routing guidance is strong but not complete.

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

All Ironflow: Hyperliquid data tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.