get_arbitrage

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

No annotations are supplied, so the description carries the full behavioral burden. It does disclose the cost model in detail (fees, tax, FX, funding, order-book slippage scaled to notionalKrw, and latency as 1-minute volatility times sqrt(lagSec/60)) plus the depth-limited/maxNotionalKrw condition, which is genuinely useful. But it never states that this is a read-only calculation with no side effects, and it gives no indication of data freshness, market-hours restrictions, or error behavior for an illiquid asset.

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

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

Density is high and nearly every clause carries technical content, but it is written as a run-on chain of noun fragments with dotted field paths (net.netPct, net.costs.latency) and no front-loaded statement of what the tool returns overall. The most important qualifier, 'All assets if asset is omitted', is buried in the final position.

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

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

With no output schema and no annotations, the description sensibly spends most of its budget defining the returned net.* fields, which is the right call for a three-parameter calculator. What is missing is scope framing: whether this is a snapshot or time series, how it relates to get_convergence_history and preview_pair_order, and whether illiquid assets return an error or a depth-limited flag.

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

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

Schema coverage is 100%, so the schema already documents asset, lagSec, and notionalKrw, making 3 the baseline. The description does add real semantics by linking notionalKrw to net.costs.slippage and net.depthLimited, and lagSec to the latency cost term, which is meaning the schema does not convey; that lifts it just above baseline rather than far above it.

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

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

The description names the exact quantities produced: the premium between the Hyperliquid perp mid and the KRX price, its 5-day regular-session median baseline, and the post-cost net on the gap. That is specific enough to distinguish it as a spread/cost calculator, but it never names the closest sibling (preview_pair_order, get_convergence_history), so the agent must infer the boundary.

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

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

There is no when-to-use guidance, no exclusions, and no pointer to an alternative tool. The only routing-like statement, 'All assets if asset is omitted', is a parameter default behavior rather than a usage rule, leaving the agent to guess whether this is a screening call or an execution-preview call.

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