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

With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently reveals that net_spread_pct does NOT subtract pool swap fees, CEX fees, deposit/withdrawal availability, or slippage beyond trade_size_usd, and warns that a spread clearing the threshold may not be profitable after those costs. It also mentions the invalid_input error for missing addresses and the fallback price source logic. This is exemplary transparency.

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 well-structured: purpose, usage, caveats, parameter list, and return format are clearly separated. Each sentence adds value—no filler. The caveats about fee exclusions are essential and not redundant. Despite length, it's warranted given the tool's complexity and lack of schema documentation.

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?

Given six parameters, no output schema, and no annotations, the description covers all necessary aspects: what the tool does, when to use it, parameter semantics, return structure (success/failure), and critical limitations. Nothing an agent needs to decide correctness or call the tool properly is missing.

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 0%, so the description is the sole source of parameter meaning. It provides examples for symbol, explains network's GeckoTerminal id default, clarifies trade_size_usd as hypothetical USD size, min_spread_threshold_pct as the threshold for is_profitable, and distinguishes pool_address (specific pool) from token_address (auto-picks most liquid pool) with the required-one constraint. Every parameter is fully explained beyond its type/name.

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 ('checks whether... diverge enough to be worth trading') on a clear resource (CEX-DEX arbitrage spread) and differentiates from sibling market.kimchi_alert by explicitly noting when to use that alternative instead. The distinction between Coinbase/CoinGecko reference and GeckoTerminal DEX price is precise, leaving no ambiguity about what the tool computes.

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 explicitly says to use this before executing cross-venue arbitrage or for non-Korean kimchi-style checks, and names market.kimchi_alert as the alternative for Upbit-specific cases. It also states the requirement of exactly one of pool_address or token_address, clarifying the input constraint. This gives clear when-to-use and when-not-to-use 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 behavioral burden and succeeds: it reveals the tool is static and pre-loaded for 2026, makes no live API call, cannot fail due to upstream outage, accepts no parameters, and specifies success/error return structures. This gives the agent realistic expectations about freshness and failure modes.

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 well-structured with a summary, usage guidance, exclusions, and return format. It loses a point for minor redundancy between 'takes no parameters' and 'Takes no arguments; calling it with any input is unnecessary,' but every other sentence carries useful 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?

For a zero-parameter, read-only calendar tool, the description is complete: it states the data source, scope, update nature, use case, output fields, and failure format. Even without an output schema, the agent can predict what a successful call returns and how to interpret errors.

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 input schema has no parameters, so the baseline is 4. The description reinforces this by stating twice that the tool takes no arguments and that any input is unnecessary, which removes any temptation to pass arguments.

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 opening line precisely describes the tool's output: a countdown to the nearest FOMC/CPI/NFP event with date/time, impact, and upcoming events. It also disambiguates by limiting coverage to US macro events and naming the exact event types tracked, so an agent won't mistake it for an earnings or non-US calendar.

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 explicitly tells the agent to use this for position sizing or holding risk planning before high-impact macro prints. It also states exclusions: non-US events and earnings are not covered, and only FOMC/CPI/NFP are tracked, making the appropriate use boundary clear.

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 it delivers: it discloses the 15s timeout, 3MB source cap, no cookies/headers sent, static-HTML behavior, and structured error modes with their meanings. It also specifies that failures are returned as structured errors, never raised, which is important invocation behavior.

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 well-organized: purpose first, then use cases, exclusions, failure modes, args, and returns. Every sentence adds actionable information, and the structure makes it easy for an agent to find the relevant detail quickly.

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?

The tool has no output schema and minimal parameter schema, so the description must carry the full contract. It does: it documents the success return shape, the failure return shape, the error types, the URL format, the timeout, and the content cap. Nothing essential is missing for an agent to invoke and interpret the result.

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 0%, but the description fully compensates for the single url parameter. It specifies that the value must be a full absolute URL including scheme, gives an example, and explicitly states that relative paths are not accepted.

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 starts with a specific verb and resource: 'Convert a webpage URL into clean, AI-friendly markdown' via a live HTTP GET, then explains the transformation (stripping ads, navigation, scripts). It also explicitly differentiates this tool from its siblings, saying no other tool here does markdown conversion and that get_token_dump_risk is unrelated.

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 gives clear when-to-use guidance: read a webpage's content, avoid wasting tokens on HTML/ads/navigation, and call it before summarizing or answering questions about arbitrary public URLs. It also lists explicit exclusions: authenticated URLs, non-HTML resources, and JavaScript-rendered SPAs, and names the sibling tool it is not.

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 behavioral burden, and it delivers: it discloses this is a 'pure calculation layer' with 'no extra upstream call' (implying fast, non-mutating), lists excluded cost/risk factors, and warns that breakeven_days is 'a rough estimate, not a guaranteed profit timeline.' The only minor gap is a slight ambiguity in 'on top of get_funding_rate - no extra upstream call' that never fully clarifies whether the rate is fetched internally.

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 structure is well front-loaded: purpose first, routing second, limitations third, then Args/Returns. Nearly every sentence earns its place, but there is minor redundancy — 'evaluates a spot+perpetual cash-and-carry trade' (paragraph 1) and 'Use this to evaluate a spot+perpetual carry trade' (paragraph 3) restate the same idea.

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?

Given there is no output schema and no annotations, the description covers all bases: purpose, sibling routing, limitations, parameter semantics, and an explicit success/failure return contract ('apr_pct', 'collects_funding_side', 'breakeven_days' vs. 'error': {'type', 'message'}). Nothing an agent needs to call this tool correctly is missing.

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 0%, so the description fully compensates. symbol gets concrete format examples ('BTC', 'ETH', 'BTCUSDT'), and assumed_round_trip_cost_pct gets a precise definition ('combined entry+exit trading fee % across both legs') plus actionable guidance to 'pass your own fee tier for accuracy.' An agent can determine correct values for both parameters without opening 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 opens with a specific verb+resource: 'Annualize a perpetual funding rate into APR + carry-trade breakeven days,' and concretely states what it computes (which side collects funding, how many days recoup round-trip costs). It also differentiates from the sibling derivatives.funding_rate by positioning itself as the APR/breakeven view rather than the raw-rate view.

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?

Explicit guidance is given: 'prefer this over get_funding_rate whenever you need the APR/breakeven view rather than the raw rate,' and it names the exact use case ('Use this to evaluate a spot+perpetual carry trade'). It also states what the tool does NOT cover (margin borrow cost, basis risk, liquidation risk), giving the agent clear when-not-to-trust 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 behavioral burden and does so thoroughly: it discloses the Bybit-first/Binance-fallback data_source behavior, explains that predicted_rate equals funding_rate is not a bug, and documents when open_interest_usd is always null. These are exactly the behavioral quirks an agent needs before trusting the result.

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 purpose and usage guidance are front-loaded, and each subsequent sentence adds a distinct piece of behavior or return-field context. The Args and Returns sections organize technical detail cleanly, with no filler.

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 enumerates the success fields, the failure structure, per-data-source field availability, and the key fallback caveat. For a one-parameter read tool with complex sourcing behavior, this is a complete invocation contract.

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 0%, but the description fully compensates for the sole symbol parameter by giving concrete examples ('BTC', 'ETH', 'BTCUSDT') and the normalization rule for non-USDT symbols. This leaves no ambiguity about what to pass.

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 opens with a specific verb and resource: 'Get perpetual futures funding rate', names the primary and fallback sources, and gives an intended use case. It also explicitly differentiates this tool from get_funding_apr_matrix, so an agent can distinguish them immediately.

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 states exactly when to use this tool ('when asked about funding rate levels or funding-rate arbitrage/carry trade opportunities') and names the alternative with an explicit exclusion: use get_funding_apr_matrix instead when APR/breakeven is needed, since calling both is redundant.

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 it provides meaningful caveats: max_leverage and return_on_equity_pct are Hyperliquid-reported fields, risk_flags are fixed numeric thresholds, and the tool cannot identify addresses. It also documents success/failure return shapes, though it does not explicitly state read-only behavior.

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 slightly long but well organized: purpose, usage boundaries, caveats, args, and returns are separated. Every section adds operational value, and the core purpose is front-loaded in the first 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?

For a one-parameter tool with no output schema, the description is complete: it lists all position fields, return success/failure shapes, risk-flag semantics, and the address-selection context. Nothing an agent needs to call it correctly is missing.

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 0% for the single required parameter, but the description compensates by defining it as a 'Hyperliquid/EVM wallet address to audit (0x...)' and adding source context (explorer, screenshot, on-chain sleuthing). This is sufficient for a single simple parameter, though no address validation rules are given.

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 uses a specific verb and resource ('Audit a Hyperliquid wallet's open perpetual futures positions') and enumerates the exact fields returned. It also explicitly distinguishes what the tool is not for ('Do NOT use it to discover or rank smart-money wallets'), preventing confusion with sibling analysis 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?

It gives an explicit precondition ('Use this only when you already have a specific Hyperliquid/EVM wallet address') and an explicit exclusion ('Do NOT use it to discover or rank smart money wallets'). This lets an agent decide between this and address-discovery/screening siblings without 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 provided, the description carries the full burden and does so thoroughly. It discloses the constant-product 50:50 assumption, the extra-hop limitation when quote_token_is_stablecoin is false/null, that pool_fee_pct is not subtracted, that gas cost is a flat per-network estimate, and that passing neither address triggers an 'invalid_input' error.

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 long but every section earns its place: the core function, data-source assumptions, caveats, parameter semantics, and return shapes. It is front-loaded and logically organized, with no filler.

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 tool with no output schema and no annotations, the description is remarkably complete. It documents both success and failure return shapes, all caveats about approximation, the dual addressing modes, and the meaning of each returned field. An agent can invoke this tool correctly and interpret its results without further context.

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 0%, so the description must compensate, and it does. The Args section explains trade_size_usd as a hypothetical USD size, network with examples and default, pool_address as a specific contract, and token_address as auto-picking the most liquid pool. It also clarifies the exactly-one-of requirement.

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 opens with a specific verb and resource: 'Estimate DEX pool liquidity and trade slippage (GeckoTerminal)' and enumerates the concrete outputs. It is clearly distinct from all sibling tools, which target different domains like token risk, derivatives, arbitrage, or macro events.

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 gives explicit guidance: 'Use this before sizing a trade or comparing pools for a given token, to check depth before swapping.' It also states what not to do: 'Do NOT treat estimated_slippage_pct or slippage_tiers as an exact on-chain quote... always re-verify with a live quote before executing.'

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 of behavioral disclosure. It comprehensively discloses that the default on-chain Sablier source does not classify holders, does not provide exact unlock timing (days_until_unlock stays null), and explains the interpretation of null as 'unknown' not 'no risk'. It also details additional fields (vesting_deposit_amount, vesting_withdrawn_amount, vesting_progress_pct) and their null behavior, as well as the free/read-only nature. This far exceeds typical behavioral transparency.

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 long but every sentence earns its place. It is front-loaded with the purpose, then logically structured into usage guidance, caveats, args, and returns. Despite its length, there is no redundancy; all details are necessary given the lack of annotations and output schema. The structure aids scanning, and the critical caveats are clearly highlighted.

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?

Given the tool's complexity (multiple return shapes, data source limitations, null handling) and the absence of an output schema and annotations, the description is exceptionally complete. It covers success with data, success but unavailable, and failure cases, explains edge cases (null days_until_unlock, vesting_progress_pct null), and provides enough context for an agent to correctly interpret results. Nothing essential is missing.

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 0%, so the description must compensate. It does so effectively with a dedicated Args section: 'symbol: Token ticker symbol (e.g. "ATH", "AO", "CPOOL"). Case-insensitive.' This adds meaning beyond the raw schema (type: string) by providing examples and case-insensitivity, fully covering the only parameter.

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 clearly states the tool's specific function: calculating vesting/unlock D-Day, unlock ratio, and sell-pressure score against volume. It uses precise verbs and resources, and explicitly differentiates from siblings by referencing dex.liquidity_slippage as the alternative for intra-day slippage, making its unique purpose unmistakable.

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 explicitly states when to use the tool (evaluating token unlock/vesting supply overhang risk before mid-to-long term positions) and when not to use it (not for intra-day slippage or real-time simulation), pointing to the specific alternative tool. It also clarifies the default data source limitations and the meaning of null values, leaving no ambiguity about appropriate contexts.

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 disclosure burden and handles it thoroughly. It reveals that the tool is a 'live snapshot only', that binance_price_usdt is a legacy name actually backed by Coinbase/CoinGecko and 'NOT a live Binance orderbook', and discloses the exact thresholds for the crash-risk and surge flags. It also documents the success/failure return shapes, including the error structure.

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 organized into clear sections: what it does, when to use/not use, args, and returns. Every sentence carries necessary information, including the critical caveat about the legacy field name and the fallback reference source. There is no fluff or repeated schema content.

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 fully documents the return payload by listing success fields (including the honest cex_reference_price_usdt alias), the failure error structure, and the alert thresholds. Combined with the single well-explained parameter, nothing an agent needs to invoke it correctly or interpret results is missing.

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 0%, so the description must compensate, and it does: 'symbol: Ticker symbol, e.g. BTC, ETH, SOL (default BTC)'. This adds semantic meaning beyond the raw schema field and gives concrete examples. The single parameter is fully explained for an agent.

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 opens with a specific verb and resource: 'Detect Korea-vs-global crypto price arbitrage (the kimchi premium)' and explains the Upbit-vs-global-reference comparison, including the two flags. It explicitly names arb.spread_matrix as the tool for non-Korean comparisons, distinguishing itself from the sibling set. This is purpose clarity at the highest level.

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 states 'Use this when asked about cross-exchange arbitrage opportunities in Korean crypto markets' and gives explicit when-not-to-use cases: 'do NOT use it for historical/backtesting data, or for non-Korean-exchange comparisons'. It names the alternative tool (arb.spread_matrix) for the general CEX-DEX spread check. This is fully explicit when/when-not/alternatives 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 provided, the description carries the full burden of behavioral disclosure and does so thoroughly. It states this is a live point-in-time snapshot, not historical/average liquidity, explains returned metadata like book_snapshot_time and tick_size, and documents the success/failure response envelope. It also notes that missing book fields return null, setting expectations for edge cases.

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 longer than average but stays tightly organized with a purpose summary, usage guidance, parameter list, and return-shape note. Every sentence carries necessary information, and the most decision-relevant constraints (live snapshot, single outcome, exact slug) are front-loaded.

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 tool with moderate complexity, no annotations, and no output schema, the description is complete. It covers what the tool does, when to use it, what each argument means, and what success and failure look like, including the key computed fields. An agent has enough information to call it correctly and interpret the result.

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 input schema provides type/default/required info only, with 0% semantic coverage, so the description must explain each parameter. It does: position_size_shares must be positive, token_id and market_slug are alternatives, outcome defaults to 'yes' and is ignored when token_id is provided, and side maps sell to bid and buy to ask. This fully compensates for the schema gaps.

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 opens with a specific verb ('Walk') and resource ('a single Polymarket outcome's live order book') and clearly states the computed outputs: executable size, average price, price impact. It also distinguishes itself from prediction.neg_risk_arbitrage by explicitly scoping to a single leg rather than multi-outcome basket arbitrage.

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 guidance is explicit: validate one leg of an opportunity from prediction.neg_risk_arbitrage, or whenever real executable liquidity is needed. It also gives a clear exclusion: do NOT use for multi-outcome basket arbitrage, directing the agent to prediction.neg_risk_arbitrage instead. The exact-slug warning further clarifies when it is appropriate to use 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 provided, the description carries the full burden of behavioral disclosure and meets it thoroughly. It explains the core mechanism (basket settles to $1), the capacity computation tied to max_slippage_pct, the caveat that notional capacity is optimistic while VWAP capacity is realistic, and the staleness field. It even documents the success and failure return shapes, so the agent knows what to expect.

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?

Although the description is longer than average, every sentence adds operational value: core concept, capacity caveat, staleness explanation, usage boundaries, parameter semantics, and return format. The structure is front-loaded with the main purpose, followed by caveats and usage, then args and returns. No filler or redundant restatement of the tool name exists.

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?

Given no output schema, no annotations, and 0% schema description coverage, this description is unusually complete. It covers what the tool computes, the key output fields, failure behavior, platform restrictions, and parameter meanings. The only minor omission is potential authentication or rate-limit considerations, but these are not essential for a read-only detection tool and are not expected from sibling context.

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 0%, so the description must fully compensate, and it does. Each parameter gets a meaningful explanation: event_slug is sourced from the Polymarket URL, assumed_round_trip_cost_pct is defined as a percentage of $1 basket notional, max_slippage_pct controls how far to walk the book, and min_net_edge_pct gates arbitrage_viable. This goes well beyond the bare schema property names.

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 opens with a specific verb and resource: 'Detect basket arbitrage in a Polymarket neg-risk event.' It clearly distinguishes itself from siblings by naming what it is not for (binary markets, Kalshi) and by referencing the companion tool prediction.exit_capacity_audit. An agent can immediately understand exactly what this tool does and how it differs from related prediction and arbitrage 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?

Explicit when-to-use guidance is present: 'Use this to scan a specific multi-outcome event you already know the slug for.' It also gives concrete exclusions ('Do NOT use for binary Yes/No markets... or for Kalshi') and even provides a workflow recommendation to pair with prediction.exit_capacity_audit before sizing a position. This leaves no ambiguity about when to select 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 provided, the description carries full responsibility for behavioral disclosure. It openly states the data source (GoPlus), the limitation of no fallback, that only GoPlus's numbers are included, and the exact success/failure return shapes. This provides strong transparency about real-world behavior and failure modes.

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?

Every sentence earns its place. The description front-loads the core purpose, then provides usage guidance, exclusions, and parameter/return details in a logical structure. Despite being longer than average, there is no fluff or repetition that dilutes value.

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?

Given two required parameters, no output schema, and no annotations, the description covers everything needed to invoke correctly: what the tool does, when to use it, what it cannot do, and the exact request/response contract. Thresholds for the liquidity_health categories are not specified, but they are not necessary for selecting or calling the 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 0%, so the description must fully document parameters, and it does. chain_id is explained as an EVM chain id with a concrete example (8453 for Base), and contract_address is specified as a token contract address with the 0x... format. This adds real meaning well beyond the bare property titles.

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 ('Audit') and resource ('LP lock/burn status for a token contract (GoPlus)'), names the exact outputs (lp_locked_pct, lp_burned_pct, liquidity_health categories), and explicitly differentiates from get_token_risk. This is unambiguous and distinct from sibling 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?

Explicitly tells when to use the tool ('before trusting it'), what it complements ('get_token_risk (honeypot/tax/mint checks)'), and what it deliberately omits (qualitative suspicious-transaction judgment). It also explains the no-fallback behavior and why Honeypot.is cannot substitute, leaving no doubt about when this is appropriate.

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 fully carries the behavioral context: it explains parallel execution, one upstream round trip, deduped union of risk_flags, unchanged field copying, and gives a precise success/failure return structure. This is thorough and leaves no major behavioral surprise undisclosed.

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 well-structured: purpose and usage are front-loaded, followed by args and returns in clear labeled sections. Every sentence contributes meaningful information, and there is no redundancy or filler.

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?

Despite no annotations and no output schema, the description covers the tool's composition, limitations, usage boundaries, parameter semantics, and return format. An agent has enough context to decide whether to use this tool and to understand what will happen.

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 0%, so the description must compensate. It does so by providing a type, example, and format for chain_id ('EVM chain id, e.g. 8453 for Base') and contract_address ('Token contract address (0x...)'). This is sufficient for these two straightforward parameters, though slightly more detail could be 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?

The description states a specific action ('Bundles get_token_risk + get_contract_health_audit into one combined diagnostic report') and explicitly names the underlying tools, distinguishing this from its siblings. It also clarifies what it does not do (no composite score/grade), making the tool's role unambiguous.

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 gives explicit when-to-use guidance ('Use this right before buying or swapping an unfamiliar token'), when-not-to-use guidance ('Do NOT use it if you only need one of the two'), and names the exact alternative tools to call instead. It even routes vesting risk to get_token_dump_risk separately.

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 so thoroughly: it discloses the GoPlus/Honeypot.is fallback, explains that fallback-only fields are null, warns not to treat null as safe, and identifies which fields are informational vs risk-flagged. It also documents the success/failure return envelope.

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 long because the tool has many output fields, but information is front-loaded and organized into purpose, data source, usage guidance, args, and returns. A few clauses could be tightened, but none are filler.

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?

Given no output schema and no annotations, the description covers everything an agent needs: purpose, when to use, how to interpret nulls, data source fallbacks, limitations/alternatives, argument semantics, and the success/failure return shape. There are no obvious gaps for calling this 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 0%, so the Args section must explain the parameters. It correctly describes chain_id as an EVM chain id with a concrete Base/8453 example and contract_address as a 0x... token address. This is sufficient for correct invocation, though it does not go into broader constraints such as supported chain lists or address canonicalization.

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 action ('check a token contract for honeypot/scam risk') on a concrete resource and immediately lists what it evaluates. It also distinguishes itself from adjacent siblings like security.contract_health_audit and security.token_diagnostic by naming what they cover instead.

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?

Explicitly says when to use the tool: 'right before entering a position on an unfamiliar or newly-listed token.' It also gives a clear negative condition, noting LP lock/burn status is not covered and directing the agent to get_contract_health_audit or get_token_diagnostic instead.

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