Bamsai

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.

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

With no annotations, the description carries the full burden and does well: it discloses the fixed start date (2026-04-13), the default window (20 days unless limit is given), the sort order (newest first), and the exact columns returned. It stops short of declaring read-only semantics or what happens when an asset has no records in range.

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?

The content is front-loaded and dense with no filler, packing the time window, record fields, ordering, and default limit into one compact statement. The telegraphic '20:00→08:00' notation and the phrase 'where the prices met' are slightly cryptic but not wasteful.

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?

There is no output schema, so the description must explain return values, and it does so by listing the recorded fields and their ordering. Combined with the disclosed time window and default limit, an agent has enough to call the tool, with only the limit unit and empty-result behavior left unresolved.

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?

The asset enum is fully documented in the schema, but limit has no schema description; the description supplies its default ('20 days unless limit is given') yet leaves the unit ambiguous — days of history versus number of rows. That partially compensates for the 50% coverage but doesn't fully resolve the parameter's meaning.

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 resource (past re-open records, per day) and enumerates the recorded fields: Hyperliquid move while closed, actual re-open move, follow flag, and meeting price. The historical framing ('Past ... record') implicitly separates it from the predictive sibling predict_open, though the contrast is never made explicit.

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?

Usage is only implied: 'Past' signals this is the retrospective counterpart to predict_open, but the description never states when to pick this over get_arbitrage or predict_open. There are no stated prerequisites or exclusions, leaving the agent to infer the historical-vs-predictive split from the wording alone.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses cardinality (one issue per day) and scope (per asset), but omits whether it is read-only, what date range is returned, whether results are empty when no news exists, and what the response format looks like.

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?

The description is a single front-loaded sentence with little wasted wording. The parenthetical '(1 per day)' slightly repeats 'per day', but it usefully clarifies cardinality.

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?

For a simple one-parameter tool with a fully documented enum, the description gives the minimum viable context: scope and cardinality. However, with no output schema and no annotations, it should clarify the time horizon and return format more explicitly.

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 description coverage is 100%, and the asset enum includes a detailed ticker-to-company mapping. The description adds no meaning beyond the schema, so the baseline score of 3 is appropriate.

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 states a specific resource and scope: top issue per day for a given asset, with cardinality of one per day. It is clear enough to identify the tool's purpose, but it does not explicitly say 'news' or differentiate itself from the sibling analytics tools.

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 explicit when-to-use guidance, no when-not-to-use guidance, and no mention of alternatives among the sibling tools. The description only implies that the tool is for retrieving daily top issues for an asset.

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

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

With no annotations, the description carries the full burden and does substantial work: it discloses the in-session branch semantics (preOpen = Hyperliquid at today's 08:00 open), the off-hours payload (current KRW price, US-close price, historical follow statistics, 80% band), and explicitly warns that probUp and the expected price are model output rather than a promise. It omits operational traits like latency, caching, or data freshness beyond the market-state split.

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?

The two modes are reasonably front-loaded, but the prose is a dense run-on mixing field paths (night.follow.ratePct, backtest.followRatePct) with domain jargon. The information earns its place, yet restructuring into short bulleted branches would make it far easier to parse.

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?

There is no output schema, so the description must convey return content, and it does list the key outputs (preOpen, current KRW price, US-close price, follow rate, 80% band, probUp, expected price). Combined with the market-state branching, an agent has enough to call it and interpret results, though exact field names and shapes remain partly implicit.

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 description coverage is 100% and the single enum parameter already documents SMSN=Samsung Electronics, SKHX=SK hynix, HYUNDAI=Hyundai Motor. The description restates the same tickers without adding new meaning about the parameter, so the baseline of 3 applies.

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 a concrete subject (the next domestic re-open at 08:00–08:10 on KRX/NXT versus the 20:00 close) and the exact assets covered (SMSN/SKHX/HYUNDAI), so the agent knows precisely what is being predicted. It does not explicitly distinguish itself from siblings like get_arbitrage or get_convergence_history, which keeps it out of the top band.

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?

It implies usage by explaining the two regimes (while the domestic market trades vs. otherwise), which effectively tells the agent what it will get in each situation. However, there is no explicit when-to-use guidance, no statement of when not to call it, and no routing to alternatives such as get_arbitrage or get_convergence_history.

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

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

With no annotations supplied, the description carries the safety burden itself and does so: "Nothing is ever sent from this server" establishes the read-only, non-mutating nature. It also discloses a non-obvious behavioral trait — pricing is on Hyperliquid testnet by default, so prices can diverge from mainnet — which an agent would otherwise misreport as a live quote.

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?

Three tight sentences, front-loaded with what the tool is, then what it returns, then the two caveats. No filler or repetition; the density is appropriate for a preview operation.

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?

There is no output schema and no annotations, so the description must cover the return shape and safety alone — it handles safety well and sketches the return values in one clause, but leaves the response structure, the derivation of the stock quantity, and the direction semantics unaddressed. Adequate but with clear gaps for a three-required-parameter tool.

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 67%: asset and notionalKrw are documented in-schema, while direction has only self-describing enum values. The description adds essentially nothing about parameters beyond echoing "stock quantity" and the order payload, and does not clarify which leg is perp versus stock per direction value. Baseline 3 fits given partial schema documentation.

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?

"Preview (dry-run) of an arbitrage pair order" gives a specific verb and resource, and the follow-on clause states what the caller gets back: stock quantity plus the Hyperliquid order that would be sent. It does not name a sibling tool to contrast with in the main body (only the notionalKrw schema note references get_arbitrage), so it falls short of full sibling differentiation.

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?

The dry-run framing implies "call before committing," which is useful implied context, but the description never states an explicit when-to-use rule or an exclusion. The only routing hint is buried in the schema: get_arbitrage with the same notionalKrw shows fill prices, slippage and net, so the split of responsibilities between the two tools is left for the agent to infer.

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