Perp Gap API

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

With no annotations, the description does real work: it discloses that the call is paid ($0.25 via x402 with USDC on Base or Solana) and that the response is a bulk JSON export. It omits rate limits, payload size expectations, and failure/refund behavior for the payment.

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?

A single tight sentence, front-loaded with the paywall so the agent sees cost first, then scope and contents. Every clause carries information, though it compresses a lot into one run-on.

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 one-parameter, no-annotation tool with no output schema, the description covers cost, format, temporal scope, and data contents, which is most of what an agent needs. It could still say more about expected volume and whether the export is idempotent/cached.

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% for the single date parameter, so the schema already carries the format ('YYYY-MM-DD, default yesterday'). The description only echoes 'one UTC day', adding no syntax, timezone nuance, or default behavior beyond the schema.

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?

States a specific verb and resource: a bulk JSON export of one UTC day of 30-minute snapshots across all 20 tracked stock perps, including cross-venue gaps, funding and OI. This clearly distinguishes it from the sample/filtered siblings, though no sibling is named explicitly.

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 description implies usage via 'Bulk... all 20 tracked stock perps', suggesting it is for unfiltered full-day pulls vs. the sample tools, but it never says when to prefer it over get_gaps, get_gap_sample or get_history. The paid-access note is a useful prerequisite but not usage guidance.

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 on the most critical trait: it discloses that the call costs $0.02 via x402 in USDC on Base or Solana, which an agent must know before invoking. It also explains what the data represents (funding normalized to hourly and APR) and what the optional history windows cover, though it omits error behavior, rate limits, and failure modes for the paid path.

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 payment cost is front-loaded in the very first clause, which is exactly what an agent needs before committing, and the rest is dense with no filler. It reads as a run-on sentence with heavy comma chaining, which slightly hurts scannability, but every clause conveys distinct information.

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: funding rate, interval, next funding time, cheapest venue per side, carry spread, history series, and a full board mode. For a zero-required-parameter tool over four venues this is close to complete, with only error/payment-failure behavior left unaddressed.

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% and each parameter is already documented, including the enum values for history and tickers, so the baseline is 3. The description mostly restates schema content (history windows, tickers='all' returning the board) and adds only marginal framing such as history applying to a single ticker and min_spread_apr being a board filter.

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 resource (stock-perp funding), the four data sources (trade.xyz, Aster, Lighter, OKX), and the normalization applied (hourly and APR). It also enumerates the returned fields — interval, next funding time, cheapest venue to long/short, carry spread — which separates it cleanly from siblings like get_quote or get_token_premium.

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 description implies usage through its parameter notes (single ticker with optional history, or tickers='all' for the board), but never states explicitly when to pick this over siblings such as get_history or get_quote. There are no exclusions or prerequisites beyond the payment notice, so the agent must infer the selection conditions.

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 the most important thing: it discloses upfront that this is a paid call ($0.01, x402, USDC on Base or Solana), which is critical behavioral context an agent must know before invoking. It also states the max of 60 tickers and the default of 20 large names, though it omits rate limits, failure modes, and payment failure handling.

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?

One dense passage with zero waste, and it front-loads the price signal before any feature detail — the right ordering for a paid tool. Every clause contributes a capability or constraint.

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 two-param read tool with no annotations and no output schema, the description covers purpose, cost, defaults, caps, and the shape of returned fields. It does not describe response structure (e.g. table schema, units, null handling when an xStock is missing), which is the main residual gap.

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 both parameters are already documented, including the venues enum. The description largely restates them ('tickers=all for every auto-discovered US stock perp', 'Set venues=all for a cross-venue comparison'), adding only the note that per-venue funding is hourly and annualized. Baseline 3 is appropriate when the schema does the heavy lifting.

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?

States a specific resource (a gap table for trade.xyz stock perps) and enumerates exactly what it returns: perp mark/oracle vs reference stock price and xStock, basis, hourly/annualized funding, open interest. It is distinguishable in content from siblings like get_funding or get_gap_sample, though it never names those siblings to sharpen 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?

Implied usage is clear (you want the gap/funding table for a ticker set), and it explains what venues='all' unlocks. However it gives no explicit when-to-use-this-vs-alternatives guidance against get_gap_sample, get_funding, or get_history, so the agent must infer which sibling answers a given question.

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 burden and does disclose the key traits: the call is FREE (cost/paywall behavior an agent can't infer), it operates on exactly one ticker, and it returns a fixed three-field payload. It stops short of error behavior (invalid ticker) or latency/rate-limit expectations, which keeps it below a 5.

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 clauses, front-loaded with the most decision-relevant fact ('FREE.'), then scope, then the routing pointer. No sentence is redundant.

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?

No output schema exists, and the description compensates by naming the returned fields, so an agent knows what comes back. For a single-param read tool that is close to complete; only failure modes on a bad ticker are unaddressed.

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% for the single ticker parameter, so baseline is 4. The description still adds real meaning by scoping the ticker to a trade.xyz stock perp symbol (e.g. NVDA) rather than a crypto or xStock ticker, disambiguating the accepted input space.

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?

States a specific verb and resource — perp-vs-stock gap for ONE trade.xyz stock perp — and enumerates the returned fields (perp mark, reference stock price, gap %). It explicitly separates itself from the sibling get_gaps, which covers xStock gap, basis, funding and open interest.

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?

Names the alternative (get_gaps) and the conditions that select it: xStock gap, basis, funding, open interest. The 'basic / ONE ticker' framing tells the agent when this narrower tool is the right pick rather than the richer one.

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 disclose the critical behavioral trait: this is a paid call at $0.02 via x402 in USDC on Base or Solana, so an agent knows payment/auth is required before invoking. It also bounds the data scope to 90 days. It does not cover failure modes for an invalid ticker, rate limits, or response size for a 90-day query at 30m granularity.

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?

Everything sits in one dense sentence whose parentheticals carry pricing, range, granularity, and returned metrics with no filler. Leading with the price instead of the purpose is a slight front-loading miss, but no sentence is wasted.

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 4-parameter tool with no annotations and no output schema, the definition covers payment, time range, granularity, and the conceptual payload well. It stops short of describing the response shape (series of points with timestamps?) or behavior on invalid ticker / out-of-range dates, which matters given there is no output schema to fall back on.

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 baseline is 3, but the description adds real meaning: 'one trade.xyz stock perp' clarifies ticker scope is single-market and restricted to trade.xyz perps, and 'up to 90 days' imposes a hard constraint on from/to that the schema does not state. The interval enumeration merely duplicates the enum, so the gain is modest rather than decisive.

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?

States a specific verb+resource: 'Historical gap time series for one trade.xyz stock perp,' and enumerates the exact metrics returned (perp vs stock gaps, basis, funding, OI, cross-venue marks). It implicitly separates itself from snapshot siblings like get_gaps by emphasizing 'historical... up to 90 days,' but never names those siblings explicitly.

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 through the 'historical... up to 90 days; interval 30m/1h/4h/1d' framing, which suggests this is the time-series counterpart to a point-in-time gap tool. There is no explicit when-to-use or when-not-to-use statement and no mention of the closely related get_gaps or get_gap_sample siblings.

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 provided, the description carries the full burden and does disclose meaningful behavior: a $0.02 x402 payment in USDC on Base or Solana, that failures (bad input, no live market) are free, and the exact shape of the returned signal set. It omits auth/settlement mechanics and any rate or coverage limits, keeping it short of a 5.

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?

Front-loaded with the price and payment rail, then the core question, then the return payload, then error policy and a 'data, not advice' disclaimer. Dense but each clause carries information; only the disclaimer is arguably disposable.

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 values, and it does list the per-outcome fields and the free-error behavior. Missing are coverage limits (how many assets/outcomes) and pagination or result-size expectations, but for a single-asset snapshot tool this is close to sufficient.

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% (asset with default BTC, optional outcome id, min_depth_usd with its 5 pp semantics), so the schema already documents all three parameters. The description adds no format or constraint detail beyond that, which is the expected baseline when the schema does the heavy lifting.

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?

States a concrete question it answers (is a Hyperliquid prediction market on a crypto/stock price cheap or expensive) and enumerates the returned per-outcome fields (bid, ask, depth, implied probability, edge in pp, liquidity flag/signal). The verb+resource is specific, but it never distinguishes itself from the similar-sounding sibling get_pm_scan, so an 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?

Usage is only implied: it tells you the tool answers a cheap/expensive question for 'every live binary price outcome on one asset' and that bad input or no live market is a free error, which hints at when it is worth calling. There is no explicit when-to-use versus get_pm_scan or list_pm_markets, and no stated prerequisites beyond payment.

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 disclose two important traits: it is a paid tool ($0.05 via x402 in USDC on Base or Solana) and it filters out empty and illiquid books. It also adds a 'data, not advice' disclaimer. It stops short of describing payment failure behavior, rate limits, or data freshness guarantees beyond 'right now'.

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?

A single dense sentence, but well front-loaded: the payment cost and rails come first, then the return content, then the filtering and disclaimer. Every clause is informative, though the semicolon chain is heavy.

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, the description must convey return shape and does so by listing the output fields. Payment terms and filtering behavior are covered. Remaining gaps are minor: nothing about pagination, ordering guarantees, or error behavior on failed payment.

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%, so all five parameters (kind, limit, min_edge_pp, max_spread_pp, min_depth_usd) are already documented with defaults. The description mentions the filtering dimensions (edge, spread, depth) but adds no syntax or format detail beyond the schema, 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?

States a specific verb+resource: a ranked scan of mispriced liquid Hyperliquid prediction markets, scoped to crypto and tokenized-stock binary markets. It enumerates the returned fields (model probability vs bid/ask, edge in pp, spread, depth, book age), which cleanly distinguishes it from siblings like get_pm_implied, list_pm_markets, and get_gaps.

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 implied rather than stated: 'most mispriced ... right now' and the liquidity filters signal a screening use case, but no sibling is named and no when-to-use/when-not condition is given. An agent must infer this tool's place among get_gaps, get_pm_implied, and list_pm_markets.

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 exist, so the description carries the full burden, and it leads with the most consequential trait: the call is paid ($0.01 via x402 in USDC on Base or Solana), which an agent must know before invoking. It also describes the 'reference used' semantics (pre/regular/after-hours/overnight/closed) and freshness, though rate limits and failure modes are not covered.

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?

A single front-loaded sentence that opens with cost and then the data payload, so the highest-stakes fact arrives first. It is dense but every clause names a distinct returned field group; only the venue enumeration is slightly list-heavy.

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, the description does the work of enumerating the return fields thoroughly, and it discloses the payment gate. What is missing is secondary: error behavior for unknown tickers, rate limits, and whether a partial batch returns partial results.

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 both parameters and the ticker/tickers mutual exclusivity are already documented in the schema. The description adds only the batching bound ('1-10 stock tickers'), which the schema already states as 'Up to 10'; no syntax or format detail beyond that.

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?

States a specific verb (quote) and resource (1-10 stock tickers) and enumerates the exact data returned: perp mark/mid on trade.xyz, Aster, Lighter, OKX, Solana xStock/Ondo prices, reference close, gap %, spread, arb bps. That field list cleanly separates it from siblings like get_funding or get_pm_implied, which cover other data axes.

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 by the content list – an agent can infer 'call this for a live cross-venue price snapshot,' but there is no explicit when-to-use or when-not, and no sibling is named as the alternative for funding, history, or prediction-market data. Adequate but leaves routing to inference.

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 disclose the most consequential trait: this is a paid call ($0.03 via x402 in USDC on Base or Solana). It also labels the news_context output as a heuristic and flags the payload as data, not advice. Gaps remain — no latency, caching, error behavior for unlisted tickers, or payment-failure handling.

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 price and headline are correctly front-loaded, and every clause names real returned data (needed given there is no output schema). But it is delivered as one run-on sentence with parenthetical nesting, making it dense to parse; a bulleted field list would serve the agent better.

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 complex, paid, multi-source aggregate with no output schema, the description does substantial work by enumerating every returned block including the news heuristic's label semantics. Remaining holes are edge behavior: coverage of the ticker universe, what happens on an unknown symbol, and any staleness/caching guarantees.

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% and the single ticker parameter is fully documented with an example, so baseline is 3. The description adds only one meaningful constraint beyond the schema: "a single stock perp," i.e. one ticker per paid call rather than a list.

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 resource (a perp research card for one ticker) and enumerates exactly which datasets it bundles: spot/session, perp prices on trade.xyz/Aster/Lighter/OKX, gaps, funding/basis, 72h gap history, verdict, token premiums, weekend gaps, news. That is more specific than any single sibling, but it never explicitly states the relationship to get_quote/get_funding/get_gaps/get_verdict, so the agent must infer that this is the aggregate of those.

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 phrase "one-call" plus the price line implies the trade-off (pay $0.03 for the whole bundle vs. call cheap single-purpose siblings), but this is only implied — no sentence says when to prefer this over get_quote or get_verdict, or that lighter endpoints exist for single fields. Usage is inferable rather than stated.

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 disclose the crucial behavior that the call is paid ($0.01 via x402, USDC on Base or Solana) and that scope is a single ticker. It does not cover failure modes (unknown/non-tokenized ticker) or whether untradable tokens still return a payload, which are meaningful gaps for a paid tool.

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?

Front-loads the most consequential fact (the $0.01 paid requirement) and then lists outputs compactly. It is a single dense run-on clause chain, but almost every clause earns its place.

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?

No output schema exists, so the description correctly enumerates the returned metrics; no annotations exist, so it also covers the paid-call behavior. Missing only edge-case handling (invalid ticker, empty liquidity, non-tradable tokens), which keeps it from being fully complete.

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?

One parameter with 100% schema description coverage ('One ticker, e.g. NVDA'), so the schema already does the work; the description only restates 'for one ticker' and the 1%-size/tradable fields are outputs, not parameter semantics. Baseline 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?

States a specific verb and resource (get liquidity for one tokenized-stock ticker) and enumerates the concrete outputs: Solana pool liquidity, $10k buy/sell price impact, size within 1%, tradable flag, and Ondo issuer mint/redeem market. Purpose is unambiguous, but it never contrasts itself with siblings like get_token_premium or get_quote, so an 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?

No when-to-use, prerequisite, or alternative guidance is given. The only implicit signal is that it is paid ($0.01), which is a cost note rather than a routing rule; nothing tells the agent when to pick this over get_token_premium or get_quote.

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 it does disclose the non-obvious economics: a $0.01 charge settled via x402 in USDC on Base or Solana. It also enumerates the returned fields (freshness, chain, liquidity). It stops short of failure modes, per-call vs per-ticker billing, or rate limits.

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 compact sentences, cost front-loaded, no filler. It is dense and jargon-heavy (x402, xStocks, Ondo), but every clause contributes to an agent's decision.

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 2-parameter, no-output-schema, unannotated tool, the description supplies cost, coverage universe, returned fields, and input modes, which is nearly everything needed to invoke it. Only the sibling routing and error/billing behavior are left open.

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%, so both parameters are already documented in the schema and 'One ticker, up to 10, or tickers=all' largely restates them. No extra syntax, precedence rules, or examples (e.g. what happens if both are supplied) are added.

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?

States a concrete output ('each token's price per share vs the real stock reference, premium/discount %, freshness, chain and liquidity') for a named asset class (xStocks on Solana, Ondo Global Markets). An agent knows exactly what this returns, though it never explicitly distinguishes itself from the sibling get_token_liquidity.

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?

No when-to-use, when-not, or alternative guidance is given. The input modes ('one ticker, up to 10, or tickers=all') describe how to call it, not when to prefer it over get_quote, get_token_liquidity, or other siblings.

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 behavioral burden and does well: it discloses the $0.03 x402 payment requirement, USDC chains, signal sources, verdict categories, included news block, news_context labels, and a disclaimer. It does not cover rate limits, latency, or error behavior, so it is strong but not exhaustive.

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 dense but front-loaded: cost/payment comes first, followed by the core verdict purpose and the returned content. Every sentence contributes useful information for a complex composite tool.

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 content, and it does: verdict types, reasons and confidence, news block details, and heuristic news_context labels. Given the single required parameter and lack of annotations, this is complete enough 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.

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

Schema coverage is 100% and the single ticker parameter is already documented in the schema with an example. The description reinforces that the call is for one stock perp but adds no further ticker syntax or format details beyond the schema.

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 verb and resource: a rule-based long/short/watch/avoid verdict for one trade.xyz stock perp. It clearly scopes the tool to a single stock perp, but it does not explicitly contrast itself with sibling tools such as get_gaps, get_funding, or get_research_card.

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 implied by 'verdict for one trade.xyz stock perp,' so an agent can infer it is for requesting a synthesized trading verdict on a single ticker. However, there is no explicit when-to-use, when-not-to-use, or alternative-tool guidance.

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 must carry the load: it states the tool is FREE and enumerates returned fields, which is useful disclosure for a read-only catalog. It stops short of stating pagination behavior or whether any auth is required, which is the remaining gap.

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?

Front-loaded with 'FREE.' and compressed into two dense sentences with no filler. Density comes at some cost of readability (perp, xStocks, Ondo GM, trade.xyz assumptions), but every clause carries information.

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 describe returns, and it does: ticker, venue, identifier, type, live, tradable_now. The 2,000+ row warning lives only in the schema, so the description itself doesn't warn about response size or pagination.

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 baseline is 3; the description earns extra by explaining that markets carry a symbol, Lighter market_id, Solana mint, or Ondo contract, which clarifies what identifier-shaped results map to. Minor risk: it mentions 'OKX perps' while the venue parameter enumerates hyperliquid-xyz, aster, lighter, xstocks-solana, ondo-gm, leaving ambiguity for an agent trying to filter by OKX.

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?

Specific verb + resource: a catalog of stock perps and tokenized stocks across named venues, with an explicit per-market field list. It also distinguishes itself from siblings by naming get_quote and get_funding as downstream consumers.

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?

'Use first to see where a ticker trades before get_quote or get_funding' gives an explicit ordering and names the alternatives. Combined with the schema's ticker recommendation, an agent knows exactly when to reach for this tool.

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; it does disclose useful traits such as "FREE", "Live", "empty books filtered", and "Data, not advice". However, it says nothing about pagination, rate limits, auth requirements, or response shape, which matters for a live market-data feed.

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?

Dense and front-loaded: scope, returned fields, filtering behavior, routing hint, and disclaimer all appear without filler. The parenthetical market example is illustrative rather than wasteful, though it slightly lengthens an already packed sentence.

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, but the description compensates by enumerating the returned fields (outcome id, asset, strike, expiry, settlement source, bid, ask, depth) and the empty-book filter. An agent has enough to call it correctly; only operational details like pagination are absent.

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 both optional parameters are documented there, so the baseline is 3. The description's asset examples (BTC, ETH, HYPE, SP500, XYZ100, META) largely restate the schema and it adds no guidance on the `kind` enum values.

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?

States a specific verb and resource (listing live Hyperliquid HIP-4 binary price outcome markets) and enumerates the exact fields returned. It also explicitly names the sibling tools get_pm_implied and get_pm_scan, so an agent can distinguish this discovery tool from the analysis tools without opening a schema.

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?

"Use first to see what get_pm_implied and get_pm_scan cover" gives explicit sequencing and names the alternatives, which is strong routing guidance. It stops short of stating when-not to use it or any prerequisite conditions, so it is clear context rather than a full when/when-not/alternative rule set.

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