Otto Intel

Prepare an unsigned Hyperliquid perp order L1 action

otto_prepare_perp_order

Read-only

Prepare and verify an unsigned Hyperliquid perpetuals order (limit, with optional reduce-only take-profit and stop-loss triggers bundled as normalTpsl) for the caller-owned Hyperliquid account, returned as the canonical L1 action plus the exact EIP-712 Agent domain, struct, and connectionId recipe the caller's own signer needs. The asset id, size grid, and price grid come from the live perp universe: an unknown or delisted perp, a size finer than the asset's szDecimals, or a price off the venue's 5-significant-digit / (6 - szDecimals) decimal grid is refused by name rather than rounded to a different order. There is no market order — name your own aggressive limit price with 'Ioc'. Otto's builder attribution is spec'd and valueless today, so the action carries no builder field and the envelope says so. The nonce is chosen by the signer, never here; the envelope's valid_until is committed to the artifact digest AND placed inside the signed digest as expiresAfter, so the venue itself rejects a stale action, while the Hyperliquid signer nonce remains the replay boundary and this tool cannot guarantee single execution. This tool never signs or submits, holds no key, and derives no agent wallet. Every envelope from this server is valid for 300 seconds from construction (valid_until); a stale envelope is refused by the verifier — request a fresh one.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`side`	Yes
`size`	Yes	Order size in base units, e.g. '0.01'. At most szDecimals fractional digits for this perp.
`asset`	Yes	Perp symbol exactly as the venue names it, e.g. 'BTC', 'kPEPE'. Case-sensitive.
`client_ref`	No
`limitPrice`	Yes	Limit price. Must sit on the venue grid: at most 5 significant digits unless integer, and at most (6 - szDecimals) decimals.
`reduceOnly`	No
`timeInForce`	No	Gtc rests, Ioc fills-or-cancels, Alo posts only. There is no market order: name your own aggressive limit price with 'Ioc' instead.	Gtc
`vaultAddress`	No	Trade on behalf of this vault or sub-account. A declared profile fact only.
`stopLossPrice`	No	Optional reduce-only market stop-loss trigger, bundled with grouping normalTpsl.
`tradingSigner`	No	The address that will sign, when it is not the master account itself: a user-held approved API wallet. Declared, never derived.
`accountProfile`	Yes	The Hyperliquid master account. `chainId` must be 1337, the signature chain id Hyperliquid pins for every L1 action.
`takeProfitPrice`	No	Optional reduce-only market take-profit trigger, bundled with grouping normalTpsl.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`rail`	Yes
`payload`	Yes
`operation`	Yes
`assertions`	Yes
`submission`	Yes
`artifact_id`	Yes
`valid_until`	Yes
`intent_digest`	Yes
`schema_version`	Yes
`account_binding`	Yes
`fee_attribution`	Yes
`replay_disclosure`	Yes
`required_capabilities`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 1, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already mark the tool as read-only and non-destructive, and the description strongly reinforces this by stating it never signs, submits, holds a key, or derives a wallet. It adds valuable context beyond annotations: 300-second envelope validity, stale-envelope rejection, signer-chosen nonce, valid_until mapped to expiresAfter, and the absence of a single-execution guarantee. None of this contradicts the annotations.

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 dense but every sentence earns its place, covering purpose, validation behavior, signing responsibilities, timeouts, and exclusions. The core purpose and most important constraint are front-loaded before the detailed behavioral warnings. Given the complexity of the tool, this length is justified rather than bloated.

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

Completeness5/5

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

With a rich input schema, annotations, and an output schema present, the description still adds essential invocation context: live perp universe validation, nonce ownership, envelope expiry, builder-field omission, and the never-signing guarantee. The combination of description plus structured data is sufficient for an agent to call the tool correctly.

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 75%, and the description adds meaningful validation context: unknown or delisted perps are refused, size must honor szDecimals, and price must sit on the venue's significant-digit grid. It also clarifies the Ioc-as-market-order substitute and the accountProfile chainId constraint. Some parameters like client_ref still rely on schema alone, but the description clearly exceeds the baseline.

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 and resource: prepare and verify an unsigned Hyperliquid perpetuals order, and explicitly states what is returned (canonical L1 action plus EIP-712 recipe). It is unmistakably differentiated from sibling tools like prepare_swap, prepare_bridge, and prepare_polymarket_order by naming the Hyperliquid perp domain and the exact signing artifacts.

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?

The description gives strong operational guidance: there is no market order, so the caller should use an aggressive limit price with 'Ioc', and stale envelopes should be replaced with fresh ones. It does not explicitly name alternative sibling tools or say 'use X instead', but the domain and constraints are clear enough that an agent can decide when to invoke it.

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

All Otto Intel 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.

Resources

Need Help?