Toolbooth

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

No annotations, so the description carries the burden. It usefully discloses the LI.FI dependency and the '$0.01 USDC per call' cost, which an agent must know before invoking. However, it never states that this only returns a quote rather than executing a bridge transaction, nor anything about slippage, route expiry, or failure modes — significant omissions for a paid, unannotated 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?

Four short sentences, front-loaded with purpose then scope then the scan shortcut then price. No filler; the cost disclosure is placed last where it acts as a final precondition check.

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 annotations and no output schema, the description does the heavy lifting well: it names the provider, the comparison outputs, supported assets and chains, the scan mode, and the per-call price. The remaining gap is that an agent cannot tell from the description whether a call performs any on-chain action or what the returned route object looks like.

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 baseline is 3; the description adds value by listing supported tokens (ETH, USDC, custom token addresses) and the supported chain set beyond the schema's 'e.g.' examples, plus reiterating the 'scan' sentinel for toChain. It still says nothing about the 'amount' string format, leaving that entirely to 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 concrete verb+resource ('Find the optimal cross-chain bridge route') plus the data provider (LI.FI) and the comparison dimensions (fees, speed, output). The 'cross-chain ... any chain pair' scoping separates it from the same-chain swap_quote sibling without needing to open either 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?

'Compare fees, speed, and output across bridges' and the toChain='scan' tip give clear when-to-use guidance for route comparison and L2 scanning. It stops short of naming a when-not or an explicit alternative (e.g. swap_quote for same-chain swaps), so it is clear context rather than full routing 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 it does disclose one genuinely useful behavioral fact: a per-call cost of $0.0005 USDC, which matters for agent budgeting. It says nothing about the evaluation engine, precision/rounding, input restrictions (e.g., whether arbitrary code or variables are accepted), or error behavior on malformed expressions.

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 short sentences with zero filler; the core action is front-loaded and the cost note is a compact trailing fact. Every sentence 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?

For a one-parameter tool with full schema coverage and no output schema, the description covers purpose, scope, and cost adequately. The main remaining gap is the return shape (numeric string vs. formatted answer, units handling), which is not conveyed by any structured field.

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

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

Schema description coverage is 100% and the single parameter already carries three illustrative expression formats, so the schema does the semantic work. The description adds only the general capability categories, not syntax, variable, or precision semantics beyond what the schema shows.

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 ('Evaluate') and resource ('mathematical expressions'), then enumerates concrete capability domains (arithmetic, algebra, unit conversions, trigonometry, matrices). No sibling in the provided list performs math evaluation, and the description makes that separation obvious without needing schema inspection.

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 capability list implies when the tool applies, but there is no explicit when-to-use/when-not-to-use framing and no named alternative. Usage is inferable rather than stated, which is the definition of minimum-viable guidance for a tool with no real competitors.

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 a key operational trait — a $0.01 USDC cost per call — plus the shape of the returned data. It never states permission or auth requirements for invoking a paid endpoint, and 'recent' has no defined lookback window.

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 short sentences with zero padding: purpose, return contents, cost. Front-loaded with the action and resource, with the pricing caveat at the end where it belongs.

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 single-parameter, no-output-schema tool, the description compensates by enumerating return fields and stating cost. The remaining gap is the undefined time window behind 'recent swap activity', which the agent would need in order to interpret 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?

Only one parameter, and schema description coverage is 100%, so the base58 Solana address is fully documented in the schema. The description adds no meaning beyond it, which is the expected baseline when the schema does all the work.

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 ('Analyze a wallet's recent swap activity') plus the intended use case ('for copy trading'), and enumerates what comes back (positions, buy/sell patterns, entry prices, frequency). It does not explicitly distinguish itself from nearby siblings like wallet_pnl, wallet_profile, or top_traders, leaving the agent to 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?

The phrase 'for copy trading' implies the use context, but there is no explicit when-to-use/when-not guidance and no named alternative such as wallet_profile for general wallet stats or wallet_pnl for returns. The agent can infer intent but must guess at the sibling boundary.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the $0.001 USDC per-call cost and names the returned fields, but it omits rate limits, data freshness, authentication requirements, and error behavior for unknown assets.

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 three short sentences and front-loads the core purpose. The second sentence largely duplicates the schema, but the cost sentence earns its place and nothing is bloated.

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

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

For a simple one-parameter read tool with no output schema, the description lists the main returned fields and the accepted query forms, which is enough to call it correctly. The remaining gap is sibling differentiation rather than missing parameter or return-value 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 100%, so the single query parameter is already well documented with examples. The description repeats that name, symbol, and CoinGecko ID are accepted but adds little beyond the schema's own wording.

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: get current price, market cap, volume, and 24h/7d change for any cryptocurrency. It also specifies search by name, symbol, or CoinGecko ID. It is clear, but it does not explicitly distinguish crypto_price from the sibling token_price.

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 does not say when to use this tool instead of token_price, dex_search, or pair_data, and it provides no exclusions or prerequisites. The cost note is useful context, but it is 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: it discloses the return payload, the three underlying sources, the fact that StockGeist is conditionally available only when STOCKGEIST_API_KEY is configured, and a per-call cost of $0.005 USDC. It stops short of rate limits, caching, or failure behavior for unresolvable tokens.

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

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

Three tight sentences: purpose first, then return shape, then sources and cost. Every clause carries information an agent needs and nothing is repeated.

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 single-parameter, annotation-free tool with no output schema, the description supplies everything material: what it returns, where the data comes from, a dependency that degrades coverage, and the price. 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?

Only one parameter and schema coverage is 100%, with the schema already explaining that 'token' accepts a symbol, name, or topic. The description's 'any crypto token or topic' restates rather than extends that, so 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 ('Aggregate social sentiment') plus scope ('any crypto token or topic'), and the enumerated source list separates it from single-source siblings such as fear_greed_index and prediction_market_sentiment.

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 stated output ('bullish score, per-source breakdown'); there is no explicit when-to-use, when-not-to-use, or named alternative to pick instead of fear_greed_index or news_headlines.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the external data sources, returned risk signals, hallucination/typosquat handling, supported ecosystems, a 20-package cap, and a per-call USDC cost, but it does not explicitly state read-only/no-side-effect behavior or payment/auth mechanics.

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 front-loaded with the core purpose, then moves efficiently through data sources, outputs, hallucination semantics, ecosystem support, limits, and cost. Every sentence provides actionable information with no padding.

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 sufficiently explains invocation context, supported inputs, behavioral risks, output fields, limits, and cost. An agent has enough information to decide when and how to call it 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%, so the schema already documents the packages format and ecosystem values. The description adds useful operational meaning by stating the cap of 20 packages per call and confirming supported ecosystems, which is beyond the schema's parameter documentation.

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

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

The description states a specific verb and resource: score security risk of software dependencies, using named external sources OSV.dev and deps.dev. It clearly distinguishes the tool from the crypto/finance siblings by domain and names the exact output dimensions, so an agent can identify its purpose without opening the 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?

It gives a clear usage context: 'before using them,' which tells the agent this is a pre-adoption dependency check. It does not name explicit alternatives or exclusions, but there is no direct sibling dependency-scanning tool in the provided list, so the omission is minor.

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 load and does disclose two non-obvious traits: the exact return contents and a per-call price of $0.002 USDC, which matters for agent budgeting. It omits data freshness/staleness, failure behavior for unknown mints, and whether the call is idempotent, but the cost disclosure is genuine added value.

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 short sentences, front-loaded with purpose, then returns, then cost. Nothing is redundant and no sentence could be cut without losing 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 single-parameter read tool with no output schema, the description adequately covers what comes back and what it costs. Remaining gaps (data source, freshness, cross-chain scope) are modest but real.

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

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

Schema description coverage is 100% and the single parameter documents itself as a base58 Solana mint address. The description adds no format, validation, or edge-case guidance (e.g., whether wrapped or non-Solana mints are accepted), so this is baseline territory.

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 ("Check DEX liquidity depth for a Solana token") and names the returned artifacts (pool info, TVL, rating). It doesn't distinguish itself from near-neighbours like dex_search, pair_data, or solana_tvl, so an agent must infer the boundary itself.

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 — the phrasing suggests pre-trade liquidity vetting, but there is no explicit when-to-use, when-not-to-use, or named alternative. The rating vocabulary (DEEP/MODERATE/SHALLOW/NONE) hints at decision support without stating the decision.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the data source (DEXScreener) and a per-call cost ($0.001 USDC), which are important behavioral traits not in the schema. However, it omits other behavioral details such as rate limits, exact vs. fuzzy matching, or what happens on no results.

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 short sentences, all front-loaded and informative. The cost is stated last but clearly, and 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 simple one-parameter search tool with no output schema, the description covers purpose, return fields, and cost. It could be slightly more complete by hinting at matching behavior or result limits, but it is sufficient for an agent to call it 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 sole parameter is already fully documented in the schema. The description repeats the same semantics ('by name, symbol, or address') without adding extra syntax or format guidance, so the baseline of 3 is appropriate.

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

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

The description states a specific verb ('Search') and resource ('DEXScreener for any token or pair') and clarifies that it returns price, volume, liquidity, and pair info across all DEXes. It distinguishes itself from single-purpose siblings like token_price and dex_liquidity by being a cross-DEX search, though it does not explicitly name alternatives.

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: search for a token or pair by name, symbol, or address to get aggregated data. There is no explicit guidance on when to choose this over siblings such as pair_data, token_metadata, or token_price, and no exclusions are 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 well: it discloses the order type (reduce-only market order), the execution model (best available price), the configuration prerequisite, and a concrete per-call cost of $0.01 USDC. It stops short of describing failure behavior (no position, insufficient gateway balance) or that slippage is possible on a market exit.

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 short sentences, each carrying distinct information, with the primary action stated first and prerequisite/cost details following. 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?

For a two-parameter mutation tool with no annotations or output schema, the description supplies the essential operating context: credentials requirement, execution mechanism, and cost. It could go further on return values and error conditions, but nothing critical to invoking 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 description coverage is 100%, so the schema already explains both 'symbol' (with an example) and 'amountUsdc' (omit to close full position). The description adds no further parameter meaning, which is acceptable at the baseline given complete schema coverage.

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: closing an open Drift BET prediction market position. It also names the mechanism (reduce-only market order through the configured Drift Gateway), which makes it immediately distinguishable from drift_place_bet (opening) and drift_open_positions (listing).

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 the verb 'close' and reinforced by the prerequisite that DRIFT_GATEWAY_URL must be set. However, it never explicitly says when not to use it or points to alternatives such as checking drift_open_positions first, leaving the agent to infer the workflow.

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 a real behavioral trait: a metered cost of $0.002 USDC per call, which matters for agent budgeting and retry loops. It still omits auth requirements and whether the price/fill data is real-time or cached, so it falls 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?

Three tight sentences: purpose first, returned fields second, symbol format third, cost last. No hedging or filler, and the most decision-relevant information is 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?

With no output schema and no annotations, the description compensates well by listing the returned metrics (oracle price, mark price, 24h change, open interest, fees, funding rate, fills) and the cost. Missing only edge-case behavior for invalid or ambiguous symbols.

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 'symbol' parameter, and the schema already supplies both suffixed and unsuffixed examples. The description's symbol guidance largely duplicates that, though it does reinforce that the '-BET' suffix is optional. Baseline 3 applies when the schema does the work.

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 detailed info for a specific Drift BET prediction market') and enumerates the fields returned, so the agent knows exactly what data class it gets. It does not explicitly distinguish itself from close siblings like drift_prediction_markets or drift_market_history, which is the only thing keeping it from a 5.

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: the symbol examples suggest a per-market lookup versus a listing tool, but the description never says when to pick this over drift_prediction_markets or drift_market_history, nor what happens for an unknown symbol. Adequate but leaves the routing decision 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?

No annotations are provided, so the description must carry the behavioral burden. It usefully discloses the return format (OHLCV with implied probability and trend direction) and a per-call cost of $0.003 USDC, but it omits auth/payment requirements, rate limits, and data-range/pagination 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?

Three short sentences, front-loaded with purpose and return data; the cost note earns its place because it affects invocation. There is no boilerplate or repetition.

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-parameter read-only data tool with no output schema, the description supplies the key return-shape and cost context. It could be more complete about history range or pagination, but the essentials for correct selection and invocation are present.

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 symbol and timeframe are already documented in the schema. The description adds no parameter-specific semantics beyond the general purpose, which is acceptable at the baseline for fully documented inputs.

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 historical price/probability data for a Drift BET market') and names the returned data shape. It is clearly historical-market data, but it does not explicitly distinguish itself from sibling drift_market_details or prediction_market_history.

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?

Includes a use case ('charting and analysis') but gives no when-not conditions and does not point to alternatives such as drift_market_details or prediction_market_history. The context is clear enough to infer its role, but routing between siblings is left to the agent.

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

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

With no annotations, the description carries the full burden and does well: it discloses a configuration prerequisite (DRIFT_GATEWAY_URL), a per-call cost ($0.002 USDC), and the exact returned fields including the long=YES/short=NO direction convention. It stops short of stating failure behavior when the gateway is unset or unreachable, which would complete the behavioral picture.

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?

Four short sentences, front-loaded with purpose, then returns, then prerequisites, then cost. Every sentence carries distinct, non-redundant information 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?

No output schema exists, and the description compensates by enumerating the returned fields (entry price, implied probability, unrealized PnL, direction). For a zero-parameter read tool this is nearly complete; only the failure/empty-state behavior is left unstated.

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 tool takes zero parameters, so the baseline is 4. The description correctly adds nothing parameter-related and instead spends its words on return shape and prerequisites.

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 + scope: 'Get open Drift BET prediction market positions,' with 'all active positions' delimiting the set. It is easy to separate from siblings like drift_close_position, drift_place_bet, and drift_market_details without opening any 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?

Usage is implied by 'open ... positions from your configured Drift Gateway' and the prerequisite that DRIFT_GATEWAY_URL be set, but there is no explicit when-to-use statement and no named alternative (e.g., drift_close_position for acting on a position). An agent must infer the call context.

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. It usefully discloses prerequisites and a $0.01 USDC per-call cost, but it does not explain execution behavior such as irreversibility, partial fills, failure modes, or what the tool returns after placing the bet.

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 front-loaded with the action and follows with essential semantics, prerequisites, and cost. Every sentence contributes useful information with no repetition 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?

For a financially consequential mutation tool with no annotations and no output schema, the description covers prerequisites and cost but leaves execution results, failure behavior, and order lifecycle unaddressed. It is adequate for a basic call but not fully complete for safe agent use.

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 the input schema already documents symbol, direction, orderType, amountUsdc, and limitPrice. The description reinforces price-as-probability and long/short semantics, but adds little beyond what the schema already provides.

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: 'Place a bet on a Drift BET prediction market.' It also clarifies the core semantic mapping that long means YES and short means NO, which distinguishes this execution tool from read-only prediction-market siblings.

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 usage context by stating it requires DRIFT_GATEWAY_URL and a funded Drift account, and it discloses the per-call cost. It does not explicitly route agents to alternatives such as drift_prediction_markets for discovery or drift_market_details for inspection, so it stops short of full when-to-use vs 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, the description carries the full burden and does well: it discloses the on-chain perpetual pricing model (0–1 USDC probability shares), the possible status values (active/settlement/delisted), the returned fields, and an explicit per-call cost of $0.002 USDC — a behavioral trait an agent must know before calling.

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

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

Three tight sentences, front-loaded with what it lists, followed by return fields, then the pricing model, then cost — every sentence adds information an agent would otherwise lack.

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 usefully enumerates returned fields and adds the paid-call detail. The one gap is scale behavior: a no-parameter 'list all' tool says nothing about result size limits, pagination, or truncation.

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 tool takes zero parameters, so there is nothing to disambiguate; the baseline applies and the description correctly spends its words elsewhere.

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 ('List all Drift Protocol BET prediction markets on Solana') and scopes it as the full-market enumeration, which separates it from detail/history siblings like drift_market_details and drift_market_history.

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?

'List all' implies the use case is enumeration of the whole market universe, but the description never states when to prefer this over drift_market_details, prediction_markets_trending, or prediction_market_events, and gives no exclusions or prerequisites.

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 well: it discloses what is pinged, the conditional behavior for the Gateway ('if configured'), the return fields (latency, status, verdict), and the cost of $0.001 USDC per call. It stops short of explicitly stating read-only safety or auth/rate-limit behavior, keeping it from 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?

Four short sentences, all front-loaded: purpose first, then mechanism, return values, usage context, and cost. Every sentence earns its place with no repetition.

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 parameters, the description provides everything needed: what is checked, conditional Gateway behavior, return fields, the health verdict scale, usage context, and cost. Nothing an agent needs to call and interpret it 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?

The tool has zero parameters, so the baseline is 4. The description correctly adds no parameter information because none exists, and the empty schema is consistent with the description's no-input nature.

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: 'Check health of Drift Protocol APIs.' It names the exact components pinged (Drift Data API and optionally Drift Gateway), making it clearly distinct from sibling tools like drift_place_bet or drift_open_positions.

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 clear usage context: 'Useful before placing bets or querying positions.' This tells the agent when the tool is relevant. However, it does not explicitly state when not to use it or name alternative health-check tools, which are not present in the sibling list anyway.

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

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

No annotations are provided, so the description carries the full burden, and it does substantial work: it discloses the inputs to the composite, the returned fields (score, classification, 7-day trend, historical comparison, signal summary), and an explicit per-call cost of $0.002 USDC. It does not spell out whether the call is read-only or whether the paid call can fail/retry, but the operational picture is largely there.

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 sentences, each carrying new information, with the core identity front-loaded and cost last where it belongs. Slightly dense, but 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?

There is no output schema, so the description appropriately enumerates the return contents itself, and it adds pricing context. The main remaining gap is the absence of any guidance on how this differs from the adjacent sentiment tools.

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

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

Schema description coverage is 100% and the single optional parameter includeHistory is fully documented in the schema, including its 30-day scope and default. The description adds no parameter-level detail, so 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 resource and verb (composite Fear & Greed index) and names the exact data sources aggregated (Alternative.me plus CoinGecko signals), which pins down the semantics precisely. It stops short of differentiating itself from the sibling crypto_sentiment tool, which an agent would need to choose between.

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 explains what the tool returns but never says when to use it instead of crypto_sentiment or crypto_price, nor does it state prerequisites or exclusions. The agent is left to infer selection from name similarity alone.

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

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

With no annotations, the description carries the burden and does well: it discloses the real-time scan behavior, the 8-hour normalization convention (critical for interpreting spreads across venues), the returned fields, and the $0.01 USDC per-call cost. Missing are rate limits, latency, or behavior when an exchange is unreachable.

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 sentences, front-loaded with what it does, then what it returns, then the usage cue and cost. No filler; every clause adds information an agent would act 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?

With no output schema, the description does describe the return payload (annualized yield, profit estimates, risk notes, long/short direction) and the pricing model. It could say more about ranking order or spread-sign conventions, but an agent has enough to call it 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%, so limit, symbols, and minSpreadBps are already fully documented with defaults and examples. The description adds nothing parameter-specific; the 8-hour normalization note is useful context but is not tied to a parameter. 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 ('Cross-exchange funding rate arbitrage detector'), enumerates the four venues scanned (OKX, Hyperliquid, dYdX, Kraken Futures) and the normalization method. That level of specificity clearly separates it from siblings like perp_market_overview, yield_rates, and lending_rates.

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 for delta-neutral carry trade discovery' gives an explicit use case and the tool's scope (perp funding spreads only). It does not name an alternative tool or state when NOT to use it, so it stops short of a 5.

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 reasonably well: it discloses the concrete return payload, the possible congestion levels, and the per-call cost of $0.0005 USDC, which is an unusual and genuinely useful economic constraint for an agent to know. It stops short of stating data freshness, caching, or whether payment/auth must be set up beforehand.

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 short sentences, each earning its place: identity, return payload, cost. The core purpose is front-loaded and there is 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?

There is no output schema, so the description must describe return values – and it does, naming fee percentiles, congestion levels, and the recommendation. Combined with the cost disclosure and zero-parameter schema, an agent has everything needed to call it 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?

The tool takes zero parameters, so there is no parameter semantics to explain and the baseline is 4. The description correctly implies a no-argument 'just call it' shape rather than suggesting configuration exists.

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 (Solana network congestion) and enumerates what is returned: fee percentiles, a congestion level with its enum values, and a recommendation. It is clearly distinct in domain from most siblings, but never names the close alternatives l2_gas_intelligence or priority_fee, so sibling disambiguation is left to inference.

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 – an agent can infer 'call this when you need current Solana fee/congestion data' from the description. There is no explicit when-to-use statement, no exclusion, and no pointer to the related priority_fee or l2_gas_intelligence tools that cover adjacent ground.

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 load and does: declares 'Read-only: places no order', discloses the exact cost model including what the wallet scan's share costs even when unused, states that failures or unplannable cases return an error with no charge, and surfaces the Hyperliquid US-persons restriction. That is a rich behavioral disclosure beyond anything structured.

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 purpose and pipeline, then cost and error terms — good ordering. It is somewhat dense, and the itemized cost breakdown ($0.005 + $0.001 + $0.001 + $0.01) repeats the total '$0.02 USDC per call', which is mild redundancy.

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 6-param, no-annotation, no-output-schema tool this covers the gaps: what the plan returns (funding, liquidation price and distance, margin, fees), conditional error behavior, pricing, and legal restriction. An agent has everything needed to decide and call.

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 defaults, ranges and default leverage cap are already documented in the schema. The description only adds the contextual link that betaOverride matters when the token has no perp and that walletAddress substitutes for amount — useful framing but marginal 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 ('Plan a Hyperliquid short') and resource (hedge for a Solana token position) and enumerates the internal pipeline (pair_data, wallet_balance, token_security, funding_rate_arbitrage) plus the fallback to SOL-with-beta. An agent can distinguish this composite planner from the individual scan siblings without opening any 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?

Makes clear this bundles the scans rather than requiring separate calls, and specifies the amount-or-walletAddress choice plus the no-perp fallback path. It stops short of naming explicit exclusions (e.g. when to prefer calling funding_rate_arbitrage directly instead of paying for the bundle).

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. It usefully discloses the monetary cost ($0.005 USDC per call) and summarizes the return values. It omits other behavioral context such as what 'recent' means, whether the data is real-time, or any permission requirements.

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

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

Three tight sentences front-load the action and output, then disclose cost. Each sentence earns its place, though the cost sentence could arguably be a separate annotation rather than description 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?

The description explains return values even without an output schema, which is helpful. However, with no annotations and an analysis tool whose time window and sentiment methodology are undefined, it leaves gaps that could affect how an agent interprets or trusts 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 description coverage is 100% and the sole parameter (mintAddress) is fully documented in the schema, so the baseline is 3. The description adds no parameter-level detail beyond the schema, which is acceptable given this high coverage.

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: tracking wallets that are accumulating or dumping a token based on transfer activity. It also names the outputs (top movers, net flow, sentiment). It doesn't explicitly differentiate from close siblings like token_holders or smart_money, but the purpose is clear.

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 'based on recent transfer activity'; there is no explicit when-to-use, when-not-to-use, or alternative tool recommendation. With siblings such as token_holders, smart_money, and copy_trade_signals, the agent gets no routing 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 carries the transparency burden and does well: it discloses that all L2 RPCs are queried in parallel and states a concrete cost of $0.002 USDC per call. It does not cover failure modes, rate limits, or latency expectations, which keeps it from 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 tightly written sentences, front-loaded with the core action and immediately followed by outputs, execution behavior, and cost. Every sentence adds 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?

With no input schema, no output schema, and no annotations, the description must carry the full burden. It does so by explaining the comparison scope, the returned metrics, parallel RPC execution, and per-call pricing.

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 tool has zero input parameters, so the baseline is 4. The description correctly presents this as a no-argument comparison operation and does not suggest any missing inputs.

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: compare gas costs across 8 L2 chains in real time. It also scopes the tool to L2 chains, which distinguishes it from broader gas tools like gas_tracker and priority_fee, and it enumerates the returned fields.

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 comparison use case is clearly implied by 'Compare gas costs across 8 L2 chains,' but the description does not explicitly say when to choose this over siblings such as gas_tracker or priority_fee. There are no exclusions or alternative-routing 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: it discloses the data source (DeFi Llama), the return shape (top pools sorted by APY with TVL, protocol, per-chain summaries), and a per-call cost of $0.005 USDC. It omits freshness/refresh cadence and what happens when a chain has no qualifying pools.

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?

Four tight sentences, front-loaded with purpose and scope, followed by return shape, source, and cost in descending order of importance. Every sentence adds information not available in the schema.

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, but the description compensates by naming the returned fields and the per-chain summary. Combined with fully documented parameters and a stated cost, an agent has enough to call it correctly; only data freshness and failure behavior 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% and each of the three parameters has a description with defaults, so the schema does the heavy lifting. The description adds only that results are APY-sorted, which hints at how minTvl/limit shape output, but no explicit parameter guidance. 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 ('Scan DeFi yields') plus an explicit scope, enumerating the eight L2 chains covered. It distinguishes itself from yield_rates/lst_yields/lending_rates by domain (L2-only) but never names those siblings, so an agent must infer the boundary itself.

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 the L2 enumeration and the APY-sorted-pools framing, but there is no explicit 'use this when / use X instead' guidance despite several adjacent yield siblings. An agent can guess when to call it, but nothing confirms the choice.

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 disclosure burden and does add real behavioral context: it lists the returned fields (supply APY, borrow APY, utilization, reward APY, per-asset best-rate summaries) and discloses a per-call cost of $0.005 USDC. What it omits is the payment mechanics (wallet/auth requirements) and any rate-limit or failure behavior, so it falls short of fully covering a paid, unannotated 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?

Four compact sentences, front-loaded with the comparison scope and protocols, followed by return contents, filtering, and price. No filler or repetition; each sentence contributes 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?

Since there is no output schema, the description must explain return values and it does so explicitly (APY types, utilization, reward APY, per-asset best-rate summary). The remaining gap is payment/auth mechanics for a paid call, which an agent would need to know before invoking.

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%, with both parameters documented including example values and 'omit for all' semantics. The description restates the same asset/protocol examples without adding new syntax, casing rules, or validation detail, so it meets but does not exceed the schema baseline.

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 ('Compare lending and borrowing rates') and enumerates the exact protocols covered (Kamino, MarginFi, Drift, Solend, Save, Mango). This clearly separates it from sibling tools like yield_rates, lst_yields, and l2_yield_scanner, which address different yield surfaces.

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 tells the agent how to narrow results ('Filter by asset ... or protocol'), implying it is the tool to reach for when comparing lending markets. However, it never states when to prefer it over yield_rates or lst_yields, nor any exclusions, so the routing decision is left 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 it does meaningful work: it discloses the return shape (risk levels CRITICAL/HIGH/MEDIUM/LOW, market stress indicator, per-protocol summaries) and the pricing model of $0.005 USDC per call — a real operational constraint the agent can't get elsewhere. It stops short of stating data freshness/refresh cadence or explicitly confirming the call is non-mutating.

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?

Four short sentences, front-loaded with the core purpose, then coverage, then return values, then cost. No filler and nothing an agent must wade through.

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 read-only, zero-required-param monitoring tool with no output schema, the description supplies return value categories and cost, which is most of what's needed. Missing are data freshness/caching behavior and how the filters interact, which matter for a near-real-time risk signal.

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 all three filters (asset, protocol, riskLevel) are already documented in the schema with examples. The description adds nothing about filter behavior — e.g. whether riskLevel is a floor, whether filters combine with AND, or what an unfiltered call returns — so 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 — monitoring Solana lending pools approaching liquidation — and enumerates the six covered protocols (Kamino, MarginFi, Drift, Solend, Save, Mango), which pins down scope. It is clearly a monitoring/risk tool rather than a rates or liquidation-history tool, though it never explicitly contrasts itself with siblings like lending_rates or recent_liquidations.

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 'monitor ... approaching liquidation,' so an agent can infer the scenario. There is no explicit when-to-use/when-not guidance and no alternative named, even though lending_rates and recent_liquidations cover adjacent ground.

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

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

With no annotations, the description carries the full burden and does well: it discloses the return shape (APY, TVL, best yields by TVL tier, ecosystem average), the data source (DeFi Llama), and an explicit price of $0.005 USDC per call. It stops short of stating data freshness/caching or whether APY is spot vs. trailing.

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?

Four short sentences, each doing distinct work — scope, coverage, return values, source, and cost — with the core purpose front-loaded. Nothing is redundant or padded.

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 three-parameter read tool with no output schema and no annotations, the description supplies what matters: what is compared, what comes back, and the data provenance. The only real gap is the absence of freshness/cadence information, which slightly limits an agent deciding whether results are timely.

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 limit, minTvl, and sortBy are already documented; baseline 3 applies. The description adds only the indirect hint of 'best yields by TVL tier' relating to minTvl, with no extra syntax, valid ranges, or guidance on choosing between 'apy' and 'tvl' sorting.

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 — 'Compare Solana Liquid Staking Token (LST) yields' — and enumerates the covered tokens (mSOL, jitoSOL, bSOL, INF, jupSOL) and protocols (Marinade, Jito, Sanctum, BlazeStake). This clearly separates it from generic siblings like yield_rates and from l2_yield_scanner.

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 Solana-LST framing gives clear context for when to reach for this tool, and mentioning DeFi Llama as the source sets expectations. It does not, however, explicitly exclude or name alternatives such as yield_rates or l2_yield_scanner, so the agent must infer the boundary itself.

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 does contribute real value: it discloses the $0.005 USDC per-call cost and enumerates what each mode returns. However, it says nothing about how payment is authorized, whether the call is read-only/safe, rate limits, or what happens if 'transaction' is absent in analyze mode.

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 tightly packed sentences, front-loaded with the core action, then per-mode returns, then cost. Every sentence carries information an agent needs, 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 and no annotations, the description does the necessary work by listing the return contents for both modes and disclosing pricing. The remaining gap is payment/auth mechanics and the failure mode when 'transaction' is omitted, which an agent would need before calling blind.

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 parameters already document their roles, so the description adds little beyond restating mode semantics. It provides no signature format hints or guidance on the default mode behavior beyond what the schema's default value already shows.

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 ('Detect MEV activity on Solana') and then splits that resource into two concrete modes with distinct outputs, which lets an agent distinguish it from the generic transaction_parse or priority_fee siblings. It stops short of naming an explicit alternative, so it is clear but not sibling-differentiated by reference.

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 mode breakdown effectively encodes when to use which path: 'landscape' for a general MEV overview, 'analyze' for a specific transaction. It does not state explicit exclusions or point to any alternative tool when a user wants raw transaction decoding or fee estimates, which is why this is not a 5.

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 load and does disclose the response contents (price, volume, liquidity, age in minutes) and a concrete cost of $0.002 USDC per call, which is meaningful operational context. It omits ordering, result limits, freshness cadence, and whether payment requires a funded wallet.

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?

Four short sentences: what it is, what it returns, who it's for, what it costs. The identity statement is front-loaded and no sentence is 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 zero-parameter tool with no output schema and no annotations, the description covers purpose, payload fields, and pricing — enough to call it correctly. Minor gaps remain around result ordering and volume of results returned, which an agent might want before invoking.

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 tool takes zero parameters and the schema is empty, so there is nothing to disambiguate — baseline 4 applies. The description correctly implies a no-argument, snapshot-style call.

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 ('Get newly created token pairs on Solana') plus the returned fields, so the agent knows exactly what it fetches. It doesn't name how it differs from nearby siblings like trending_tokens, pair_data, or dex_search, which keeps it from a 5.

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?

'Essential for meme coin discovery' hints at the use case, and 'newly created' plus 'age in minutes' implies a recency-focused lookup. But there is no explicit when-to-use vs. when-not, and no alternative tool is named for older or established pairs — usage is only implied.

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 usefully discloses the return fields (titles, sources, links, dates, snippets) and the per-call cost of $0.005 USDC. It does not mention rate limits or authentication, but for a read-only search endpoint it covers the key behavioral facts.

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 short sentences, front-loaded with the core action, then output contents, then cost. No wasted wording.

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

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

For a simple one-parameter news search tool with no output schema, the description gives enough context: purpose, return fields, and cost. It could mention freshness/recency behavior or rate limits, but the essential calling information is present.

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

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

Schema coverage is 100%, so the schema already documents the single query parameter with examples. The description adds only 'on any topic,' which is mild extra meaning beyond the schema baseline.

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: search Google News for current headlines. It distinguishes itself from generic web search by naming Google News and 'current headlines,' though it does not explicitly contrast with the sibling web_search tool.

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 for finding current news on any topic, but gives no explicit when-to-use or when-not-to-use guidance and does not mention the sibling web_search alternative.

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 so well: it discloses venue coverage, hourly sampling, per-window metrics, failure handling, partial-failure behavior, and the fact that failed calls are not charged. It also states the exact cost of $0.003 USDC per call, which is important for agent decision-making.

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: it starts with the core purpose, then adds sampling cadence, accepted symbol formats, error behavior, and cost. Every sentence provides actionable context, and there is no redundant restatement of the tool name or title.

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

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

There is no output schema and no annotations, so the description must explain enough for correct invocation. It covers what is returned, which venues are queried, the time windows, sampling frequency, accepted symbol formats, partial-failure reporting, complete-failure semantics, and pricing. That is sufficient for an agent to understand the tool's behavior and result shape.

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 single symbol parameter is already documented. The description still adds value by clarifying that the tool accepts base assets or pairs in multiple formats, including BTC/USDT and the alternate XBT ticker. That goes beyond the schema examples of BTC, ETH, and SOLUSDT.

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: how one asset's perpetual-futures open interest moved over 1, 4, and 24 hours across OKX, dYdX, and Kraken Futures. It also scopes the data precisely, including current OI, change amounts and percentages, price change, and a combined cross-venue view. Although it does not name sibling tools, its focus on OI change is clearly distinct from broader siblings such as perp_market_overview.

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 makes the tool's use case clear: analyzing short-term open-interest movement and its conventional market interpretation. However, it does not explicitly say when to use this tool versus alternatives such as perp_market_overview or funding_rate_arbitrage. Usage is therefore implied rather than explicitly guided.

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

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

With no annotations, the description carries the full burden and does substantial work: it discloses the data source, the pricing model (Black-76 forward deltas from Deribit mark IVs), the interpolation convention (at each expiry's forward), the coverage gap (no DVOL for SOL), and the commercial behavior (costs $0.005 USDC per call, not charged on failure). It stops short of stating latency, freshness, or rate limits, which for a paid external-data fetch would be the remaining behavioral risks.

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?

Purpose and source are front-loaded in the opening clause, followed by the field enumeration and then short operational sentences on failure and cost. It is dense but every clause adds a distinct fact; the only mild bloat is the long output enumeration, which is justified by the absence of an output schema.

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 compensates by enumerating the returned fields, and it also covers cost, charge-on-failure, and per-asset coverage limits. Given a two-parameter, no-annotation tool with a rich return payload, an agent has everything needed to decide to call it 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 description coverage is 100% and both parameters (currency with its default and allowed values, maxExpiries with range 1-30 and default) are fully documented in the schema, so the baseline is 3. The description adds one useful semantic fact not in the schema — that SOL has no DVOL series — but says nothing extra about how maxExpiries ordering interacts with the returned term structure beyond what the schema already says.

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?

Names a specific instrument (option-implied volatility) and a specific source (Deribit public data) for a specific asset set (BTC, ETH, SOL), then enumerates exactly the quantities produced (term structure, 25-delta IV, risk reversal, butterfly, OI/volume ratios, DVOL). This is clearly distinguishable from siblings like crypto_price, perp_market_overview, open_interest_change or funding_rate_arbitrage because it is explicitly options-implied data rather than spot, perp or aggregate OI.

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: an agent can infer this is the tool for option skew/term-structure questions. There is no explicit when-to-use statement, no exclusions, and no named alternative for cases where spot or perp volatility is wanted instead. The failure condition ('Fails ... if Deribit's option data is unavailable') is a runtime caveat, not selection 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 carries full burden and does so well: it discloses error semantics (failed venues listed under errors, call fails only if none answers), billing ($0.005 USDC per call, not charged on total failure), and a data caveat (depth bands past venue coverage flagged as lower bounds). This is exactly the behavioral context annotations would otherwise supply.

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 core purpose, then layers outputs, symbol formats, caveats, and cost. Dense but every sentence adds distinct information; minor density cost from the long output enumeration, but nothing 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?

With no output schema and no annotations, the description fully compensates — it details the return contents, failure handling, caveats, and cost, so an agent knows what it gets and how it's charged. Nothing needed 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 100%, so baseline is 3, but the description adds real value on the required symbol parameter by listing multiple accepted formats (BTC, BTCUSDT, BTC/USDT, BTC-USDT-SWAP, Kraken's XBT) beyond the schema's brief example. The levels parameter semantics (1–50 default 10) are already in the schema and not elaborated, hence 4 not 5.

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 — aggregated perpetual-futures order books across four named venues, merged and side by side — and enumerates the exact outputs (best bid/ask, spread, depth and imbalance at defined bands, crossed books, top merged levels). An agent can distinguish this from siblings like perp_market_overview or dex_liquidity without opening any 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?

The comparison/merge framing makes the intended use case clear — cross-venue depth and arbitrage-style crossed-book detection — but it never explicitly names when to prefer a sibling (e.g., perp_market_overview) or when-not to use it. Clear context, no exclusions.

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 add real behavior: it discloses that only the highest-volume pair is returned (critical for tokens with multiple pools) and surfaces the $0.001 USDC per-call cost, which is unusual and highly actionable. It stops short of covering error behavior or payment/auth mechanics.

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?

Two dense sentences, front-loaded with the core purpose and field list, then the pair-selection rule and cost. No filler; 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?

For a single-parameter lookup with no output schema, the description is nearly complete: it enumerates return fields, explains pair selection, and notes cost. The only minor gap is absence of any error/edge-case behavior, but nothing essential for calling 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 100% and the single parameter is documented as 'Token mint/contract address.' The description adds no syntax or format detail beyond the schema ('for a token'), so the 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 full DEXScreener stats for a token') and enumerates exactly which fields are returned (price, volumes across timeframes, buy/sell counts, liquidity, market cap, changes). The 'returns the highest-volume pair' detail helps distinguish it from narrower siblings like token_price or dex_liquidity, though it doesn't name an alternative 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: the field list signals 'use this when you want comprehensive DEX stats for a token.' There is no explicit when-to-use vs token_price/dex_liquidity/dex_search guidance and no exclusions or prerequisites stated, so an agent must infer the selection criteria.

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 present, the description carries the full burden and does meaningful work: it discloses partial-failure behavior ('Venues that fail are listed under errors'), billing semantics ('the call fails (and is not charged) only if none answers'), and the exact cost ($0.005 USDC per call). It omits auth requirements, rate limits, and latency expectations, which keeps it from 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?

Two dense sentences, with the resource and venue scope front-loaded and cost/error semantics placed last where they matter least. The field enumeration is long but each item is a distinct returned metric, so it earns its space; a slightly tighter grouping of the funding metrics would improve it.

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 must describe return values — and it does so thoroughly, including per-venue fields, a summary block (total OI/volume, weighted funding, mark-price dispersion), and partial-failure handling. For a single-parameter read tool this covers everything an agent needs to call it and interpret 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 the baseline is 3, but the description adds genuinely new meaning by listing accepted symbol formats ('BTC, BTCUSDT, BTC/USDT or XBT') that the schema's single example does not cover. That directly reduces malformed-input risk for the one required 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 names the specific resource (one asset's perpetual futures across OKX, Hyperliquid, dYdX and Kraken Futures) and enumerates the metrics returned, so an agent can tell it apart from generic price tools like crypto_price or pair_data. It does not explicitly name the nearest overlapping siblings (funding_rate_arbitrage, open_interest_change), so it falls short of a 5.

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: the agent must infer that this is the tool to call when it needs a cross-venue perp snapshot for a single asset. There is no explicit when-to-use statement, no exclusion of alternative tools, and no prerequisites such as authentication or symbol support limits.

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 does so well: it declares read-only behavior ('places no order'), describes the mechanics (resolves market and token, walks the live order book), discloses pricing ($0.005 USDC per call), and warns about the US/regional block. That is a materially richer profile than a bare 'quote' label would provide.

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 purpose and most important constraint, and every sentence adds usable information (what it returns, safety, identifiers, cost, legal restriction). The long first sentence with stacked parentheticals is dense but not wasteful.

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

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

There is no output schema, so the description must explain returns, and it does: fill size, average/worst price, slippage vs best and mid, fee and total cost. Combined with identifier formats, cost per call, and the region restriction, an agent has everything needed to call this 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 description coverage is 100% and each of the six parameters already has its own description, so the baseline is 3. The description restates the identifier forms (slug, Gamma id, URL, polymarket:<id>) already in the schema and doesn't add detail on tick-size handling for limitPrice or the buy/sell amount pairing.

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 ('Quote a Polymarket order before you place it') and immediately enumerates what the quote contains: shares, average and worst price, slippage, platform fee and total cost. This clearly separates it from sibling tools like prediction_market_odds (informational odds) and swap_quote (DEX quoting).

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?

Gives a clear when: before placing an order, to preview fill and cost. It also names the accepted identifier forms, including cross-referencing a 'prediction_market_arbitrage id (polymarket:<id>)', which helps an agent chain tools. It stops short of naming an explicit alternative or when-not-to-use condition beyond the region restriction.

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

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

With no annotations, the description carries the full burden and does well: it discloses parallel fan-out across three venues, volume-based sorting, the returned data fields, and a per-call cost of $0.01 USDC. Missing are error/partial-failure behavior when a venue is unreachable and any rate-limit or auth notes.

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?

Four short sentences, front-loaded with the core purpose, each contributing something (platforms, sorting, arbitrage use, return fields, cost). The second and third sentences overlap slightly on cross-platform matching, keeping it just short of maximal.

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 read-style search tool with no output schema, the description covers return contents (probabilities, volume, liquidity, spreads), ordering, and pricing, which is nearly everything an agent needs. Only failure-mode and pagination behavior 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 description coverage is 100% and both parameters (query, limit) are documented in the schema, establishing the baseline of 3. The description adds no format, syntax, or defaulting detail beyond what the schema already states.

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?

Names a specific verb and resource ('Cross-platform prediction market search') and enumerates the three platforms queried. It is clearly broader than single-venue siblings like polymarket_quote or drift_prediction_markets, but it never names those siblings explicitly, so differentiation is inferred rather than stated.

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 — compare odds, spot arbitrage — but gives no explicit when-to-use/when-not guidance and never names an alternative such as prediction_market_arbitrage or prediction_market_odds, despite many closely overlapping siblings. Usage is inferable, not directed.

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 well: it discloses cost ($0.01 USDC per call), sorting order (biggest spread first), and the actionable threshold (>3% spread). It omits return format details and does not explicitly state read-only behavior, but the core behavioral traits are 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?

Four sentences, front-loaded with the core purpose, followed by key behavioral details. Every sentence earns its place with no redundancy or fluff.

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 moderately simple tool (3 optional parameters, no output schema), the description covers purpose, cost, sorting, and threshold. It lacks detail on the return structure, but given the absence of an output schema, the description is largely complete for an agent to call it 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 description coverage is 100%, so the schema already documents all three parameters. The description mentions a >3% spread flag, which loosely relates to the minSpreadPct parameter but does not add syntax or meaning beyond what the schema provides.

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 ('find') and resource ('prediction market arbitrage opportunities'), naming the three platforms compared. This clearly distinguishes it from sibling tools like prediction_market_odds or prediction_market_aggregator, which focus on quotes or aggregation rather than arbitrage detection.

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?

Provides clear context for when to use: finding arbitrage opportunities with a >3% spread threshold. It does not explicitly state when not to use or name specific alternatives, but the purpose is sufficiently self-contained for an agent to infer appropriate usage.

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. It usefully discloses the $0.005 USDC per-call cost, cross-platform coverage, and mode-dependent outputs, but it omits payment/auth mechanics, rate limits, pagination, and explicit 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 front-loaded and compact: purpose first, then the two modes, then cost. 'Cross-platform coverage' slightly repeats the platform list, but the overall structure is efficient and easy to scan.

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 four-parameter read-style tool with full schema coverage and no output schema, the description covers purpose, modes, platforms, and cost adequately. It could still say more about return shape or data freshness, but the core calling information is present.

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 the input schema already documents mode, limit, query, and timeframeDays. The description reinforces mode semantics by explaining that 'upcoming' returns closing-soon markets with odds and 'resolved' returns settled markets with outcomes, but it does not add meaning for the other parameters.

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: 'Track prediction market events and resolutions' across named platforms. It also identifies two operating modes, but it does not explicitly distinguish this tool from close siblings such as prediction_market_aggregator, prediction_market_history, or prediction_market_odds.

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 clear guidance on choosing between 'upcoming' and 'resolved' modes, including what each returns. However, it gives no guidance on when to use this tool instead of the many sibling prediction-market tools, so usage versus alternatives is only implied.

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, so the description carries the burden. It does the most valuable thing available — disclosing a per-call cost of $0.003 USDC — and sketches the return contents. It says nothing about the data source/venue, rate limits, or whether the price feed is live or sampled.

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?

Four short sentences, front-loaded with the core verb and resource, then returns, then usage, then cost. No padding; the cost sentence is the only unusual placement but is easy to find.

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-parameter read tool with full schema coverage and no output schema, the definition is close to adequate — it hints at return contents and states cost. The unresolved ambiguity about which market venue/source it reads from is the main incompleteness.

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%: the market param (slug/ID/query) and the timeframe enum values are fully documented in the schema. The description adds only the vague phrase "over time," which the timeframe parameter already conveys more precisely. Baseline 3.

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 — probability/price history for a prediction market — and names the returned shape (data points, high/low, trend). It stops short of differentiating itself from the near-identical sibling drift_market_history, leaving the agent to guess which venue each covers.

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 for charting and analysis" implies a use case but names no alternative and no exclusion. Given that drift_market_history, prediction_market_odds, and polymarket_quote all sit in the same neighborhood, the absence of routing guidance is a real gap.

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 does disclose the key non-obvious trait: a $0.005 USDC cost per call, which affects call budgeting. It also frames results as the largest probability shifts within a timeframe. It does not state that the operation is read-only, whether payment is required before results return, or what fields come back.

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 short sentences, front-loaded with the core action and quickly followed by the differentiator and the cost. No repetition or filler; only minor gain would come from cutting the interpretive clause.

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-required-parameter read tool this covers the essentials (what it returns conceptually, cost, timeframe), but with no output schema the description should say more about the shape of each returned market (odds deltas, volume, market id) so an agent can plan downstream use.

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 every parameter (limit, category, direction, timeframe, min_volume) is already documented, including defaults and enum-like values. The description only echoes 'timeframe' and adds no syntax or behavioral detail beyond the schema — 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 (find) and resource (prediction markets) plus the distinguishing criterion — biggest odds/probability changes. This separates it from prediction_market_odds (quotes) and prediction_markets_trending (popularity/volume trends), though it never names those siblings to make the contrast explicit.

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

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

The phrase 'early signal for breaking news or sentiment shifts' implies the use case, so the agent can infer 'use this to detect sudden probability moves.' But there is no explicit when-not-to-use, no mention of competing tools like prediction_markets_trending or prediction_market_arbitrage, and no guidance on choosing a timeframe.

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 a meaningful behavioral trait, the $0.002 USDC per-call cost, plus the fields returned. It omits rate limits, whether lookups are cached, authentication/payment mechanics, and error semantics for unresolvable queries.

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?

Four short sentences, front-loaded with purpose, then input forms, then return contents, then cost. Every sentence adds information the agent needs and none is redundant 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 correctly fills the gap by naming the returned fields (probabilities, volume, liquidity, outcome prices), and it discloses cost. For a one-parameter read tool this is nearly sufficient; the missing piece is differentiation from sibling prediction-market tools.

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 parameter already includes slug/ID/query examples, so the baseline is 3. The description echoes the same examples and adds no new syntax or edge-case detail (e.g., how natural language is resolved, or whether partial slugs match).

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 ('Get current odds for a prediction market') and enumerates the lookup key types. It does not, however, distinguish itself from closely related siblings such as polymarket_quote, prediction_market_aggregator, or drift_prediction_markets, leaving the agent to 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 implied through the three accepted input forms (slug, ID, natural-language query) with examples, so the agent knows how to call it. There is no explicit when-to-use guidance versus the many alternative prediction-market tools, no exclusions, and no note on failure when a market is ambiguous or not found.

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 adds useful context: it names the source (Polymarket), states the return format (0-100 score with bullish/bearish label), and discloses a $0.01 USDC cost per call. However, it omits payment prerequisites, rate limits, and any failure behavior, so transparency is adequate but incomplete.

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

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

Three tight sentences front-load the core action, then the source and output, then the cost. Every sentence adds relevant information with no waste.

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-parameter tool with no output schema, the description explains what is returned (0-100 sentiment score with label) and discloses cost. It is nearly complete, though it could mention aggregation method or time window for full contextual clarity.

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 the topic and limit parameters are already documented in the input schema. The description does not add syntax, constraints, or interpretation beyond what the schema provides, making the baseline 3 appropriate.

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

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

The description uses a specific verb and resource: 'Aggregate sentiment across all prediction markets related to a topic.' It clearly distinguishes from raw odds/event siblings by emphasizing an aggregated 0-100 sentiment score, though it does not explicitly name alternatives like prediction_market_aggregator or crypto_sentiment.

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 for topic-based sentiment analysis but gives no explicit when-to-use or when-not-to-use guidance. It does not contrast with sibling tools such as prediction_market_aggregator, prediction_market_odds, or crypto_sentiment, leaving the agent to infer selection criteria.

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 bears the full burden. It usefully discloses the paywall ('Costs $0.005 USDC per call') and the returned fields, which is genuine value-add. However, it omits auth/payment mechanics, rate limits, and pagination or freshness behavior beyond the schema's max-25 limit.

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 short sentences, front-loaded with the core action, then return values, then cost. Every clause carries information and there is no padding or redundancy.

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-required-parameter read tool with a fully documented schema, the description covers purpose, return fields, filtering, and cost. Without an output schema it reasonably should describe the response shape more, but the enumerated fields are close to sufficient; only freshness/ordering semantics are unstated.

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 three parameters (limit, sort_by, category) are already documented with defaults and allowed values. The description restates the category options without adding anything, and never mentions limit or sort_by at all, so it neither compensates nor detracts.

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 top trending prediction markets from Polymarket) and enumerates the returned fields, so the agent knows exactly what comes back. It does not distinguish itself from near-siblings like prediction_market_movers, prediction_market_odds, or polymarket_quote, which is the only missing piece for a 5.

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 'top trending' and the category filter list, but there is no explicit when-to-use or when-not-to-use guidance. Nothing tells the agent to prefer prediction_market_movers for movers or polymarket_quote for a single market, so disambiguation is left 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 burden, and it discloses the priced nature of the call ($0.0005 USDC per call) plus the response shape — genuinely useful context an agent cannot get from structured fields. It stops short of noting freshness/caching or latency of the estimate.

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 short sentences, front-loaded with what it returns, then when to call, then cost. 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?

No output schema exists, and the description compensates by naming the returned tiers, units, and cost — enough for an agent to call this zero-param read correctly and know the price of doing so.

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 tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate, and it correctly implies no inputs are required.

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 current Solana priority fee estimates') and enumerates the returned tiers (low/medium/high/very_high) with units (microLamports, SOL). The 'Solana' qualifier plus the priority-fee resource cleanly separates it from gas_tracker and l2_gas_intelligence.

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?

'Call before every transaction' gives explicit, actionable timing guidance. It does not name a when-not condition or point to an alternative, but the usage context is 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, the description carries the full burden and does well: it discloses venue limitations, realized-vs-estimated data, feed-coverage reporting, failure behavior, and per-call cost. It does not mention rate limits, auth requirements, or data freshness, which keeps it from 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?

The description is front-loaded with the core purpose and then adds only essential distinctions: realized vs estimated, feed coverage, failure semantics, and cost. The long first sentence is dense but 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?

There is no output schema or annotations, so the description must explain return content and behavior, which it does thoroughly: long/short counts, size, USD value, largest liquidations, hourly breakdown, price-band clearing, coverage, failure, and cost. An agent has enough to call it 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%, so the schema already documents symbol, hours, and bucketPct. The description reinforces the meaning of the adjustable percentage bands and time window, but adds little parameter detail beyond what the schema provides.

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: recent forced liquidations for one asset's USDT perpetual on OKX. It explicitly distinguishes realized liquidations from estimated liquidation levels, which separates it from sibling tools like liquidation_risk.

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 clear context for when this tool applies (recent realized liquidations on OKX USDT perpetuals) and implicitly routes agents away from estimated-liquidation tools. It does not explicitly name the alternative or state when not to use it, but the scope is sufficiently 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, the description does real work: it discloses the return shape (redacted previews, severity levels, rotation recommendations), the implementation model (pure regex, no external API), and the exact cost ($0.005 USDC per call). It stops short of discussing false-positive/negative characteristics of regex matching or any 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?

Four short sentences, front-loaded with the action and detection coverage, then output, then implementation and cost. Every sentence carries distinct information and none repeats the schema.

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 tool with no annotations and no output schema, the description is nearly complete: it explains what is returned, how detection works, and what it costs. Minor gap: it does not state input size limits or that filename only affects contextual labeling.

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 parameters are documented in-schema, so the description baseline is 3. It adds no extra parameter meaning beyond what the schema says — for example, nothing about how large 'code' may be or how filename influences severity assignment.

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 — 'Scan code for leaked secrets, API keys, tokens, and credentials' — and enumerates the detected categories. No sibling in the list performs secret scanning (token_security and transaction_parse cover different ground), so an agent can route to it unambiguously.

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 the resource (scanning source code or config strings), but there is no explicit when-to-use/when-not or comparison against any alternative tool. The note that filename is used 'for context' hints at typical inputs without stating prerequisites or exclusions.

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. It discloses the cost ($0.05 USDC per call) and the return format (per-token stats, PnL, best/worst trades, label), which are key behavioral traits. It omits explicit confirmation that the operation is read-only and does not mention rate limits or authentication requirements.

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 front-loaded with the core purpose and scoring details, followed by return values, use cases, and cost. Each sentence contributes useful information, though the return-value details and use cases could be slightly more compact.

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 scoring tool with no output schema and no annotations, the description adequately covers what is returned (per-token stats, PnL, best/worst trades, label) and how the score is computed. It misses some completeness elements like error behavior or wallet eligibility criteria, but overall it provides enough context for an agent to decide to use it.

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 parameter (walletAddress) is well-described in the schema. The description adds no additional parameter semantics beyond what the schema provides, which is acceptable given the baseline of 3 for fully covered parameters.

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 ('Analyze') and resource ('Solana wallet's trading intelligence') and details the scoring mechanism. It is clear what the tool does, but it does not explicitly differentiate itself from siblings like wallet_pnl or top_traders, which also analyze wallet performance.

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 provides clear use-case contexts: 'evaluate copy-trade targets, track whale wallets, or assess counterparty skill.' However, it does not specify when to use this tool versus similar siblings such as wallet_pnl or wallet_profile, nor does it list exclusions.

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

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

With no annotations, the description carries the full burden and does well: it names the upstream source (DeFi Llama) and discloses a concrete per-call cost of $0.005 USDC, which is important operational context. It stops short of stating data refresh cadence, rate limits, or whether payment requires a funded wallet.

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 sentences, front-loaded with the data source and payload contents before the filtering hint and the cost. Every clause carries information; nothing 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?

There is no output schema, so the description must describe return values, and it enumerates the full payload (totals, rankings, categories, trend, dominance) plus cost and data source. Remaining gap is freshness/cadence and error behavior, which is minor for an analytics read 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 100%, so all three parameters are already documented, and the description only adds the category-filtering rationale. It never explains the 'limit' control and the stated '7-day trend' does not map cleanly to the includeHistory parameter, which produces 30-day daily history.

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 ('Solana ecosystem TVL analytics via DeFi Llama') and enumerates exactly what comes back: total TVL, ranked protocols, category breakdown, 7-day trend, and dominance share. No sibling covers Solana-wide TVL aggregation, so it is easy to distinguish from tools like dex_liquidity or lending_rates.

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 only usage guidance is 'Filter by category for focused analysis,' which implies when to narrow scope but never contrasts with alternatives (e.g., using category='Dexes' here vs. dex_liquidity). There are no explicit when-not-to-use conditions or prerequisites beyond the implicit paid call.

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

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

With no annotations provided, the description carries the full burden and does so: it discloses a $2.00 USDC charge per call, an irreversible on-chain identity write, and the security tradeoff of generateKeys (secrets passing through the conversation, marked "discouraged"). That is exactly the kind of cost, side-effect, and security context annotations would otherwise supply.

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 actual capability is front-loaded before the signing mechanics, and every sentence adds operational value (signature template, key generation alternative, cost). It is one dense block, though, and the embedded signing template is hard to scan compared to a bulleted structure.

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 10-parameter mutation tool with no annotations and no output schema, the description covers the essentials: what is created, what it costs if keys are generated, and what is returned. It omits failure behavior (duplicate name, insufficient USDC) and does not preview the non-key portion of the response, which an agent with no output schema would benefit from.

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 50%, and the description compensates substantially: it defines the roles of solanaAddress, evmAddress, apiKeyHash (hex SHA-256 of a fresh tb_live_ key), solanaSig, and evmSig, including exact encoding formats the schema omits. The issuedAt parameter is only implied through the "issued:<ISO-8601 now>" signing template and is never explicitly mapped as an input, leaving a small gap.

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, "Onboard a new AI agent in one step," and enumerates exactly what the call produces: wallets, $1.00 credit, ERC-8004 identity on Base, ENS name, and MCP config. No sibling tool in the list does anything similar, so an agent can distinguish it 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?

It presents two explicit paths: supply your own addresses, key hash, and signatures, or set generateKeys=true and receive keys in the result. It also explains how to construct each signature (Ed25519 base64 for Solana, EIP-191 personal_sign hex for EVM) so the caller knows the required prerequisites. It does not state when the tool should not be used or address name-collision cases.

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 well: it names the independent sources, explains the median/deviation/severity logic, discloses source-disagreement and error handling, and states the failure and billing behavior. This is unusually transparent for a read-only data 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?

The description is dense but front-loaded: it begins with the tool's identity, then compresses sources, outputs, severity thresholds, errors, and cost into a single purposeful paragraph. Every clause adds useful information and there is 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?

Given no output schema and no annotations, the description supplies the output fields, severity taxonomy, error behavior, and pricing model needed to invoke and interpret the tool. Nothing essential for a one-optional-parameter peg monitor 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?

The sole parameter is fully documented in the schema, and the description repeats the supported coin list rather than adding new semantics such as normalization rules or invalid-input behavior. With 100% schema coverage, the baseline of 3 is appropriate.

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

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

The description states a specific verb and resource: checking USD stablecoin pegs against $1 across named sources. It also names the exact coins and the peg-specific outputs, which clearly distinguishes it from generic price or pair-data siblings.

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 context strongly implies that this tool is for stablecoin depeg monitoring, but the description never explicitly says when to use it instead of siblings like crypto_price, token_price, or pair_data. 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 burden and does well: it discloses the per-call cost ($0.001 USDC) and enumerates return fields, both non-schema information. It omits quote expiry/validity window and whether the quote is a reusable executable payload, which matter for a swap quote.

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

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

Three short sentences, front-loaded with purpose, then returns, then usage imperative, then cost. No filler and nothing buried.

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 compensates by naming the returned fields (amount out, price impact, route, fees). Remaining gaps are quote lifetime and whether an execute-swap tool exists as a next step; minor but real for a trading-adjacent 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 description coverage is 100%, with units, base58 formatting, and the slippage default all documented in the schema. The description adds no parameter-level meaning beyond that, so the 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?

Specific verb and resource: 'Get a Jupiter swap quote for any Solana token pair,' plus an explicit list of what the response contains. Jupiter/Solana pair quoting is clearly distinguishable from the many price, liquidity, and prediction-market siblings.

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?

'Essential before executing any trade' gives a clear call condition and sequencing hint. It stops short of naming alternatives (e.g. order_book_aggregator, dex_liquidity) or stating when a quote is unnecessary, so it is clear context without exclusions.

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 disclosure burden; it does well to state the paid cost ($0.005 USDC per call) and to describe what is returned, which a raw schema would not reveal. However, it says nothing about read-only/safe semantics, whether 'full' truly means all holders or is capped by `limit`, or pagination behavior, so it is helpful but incomplete.

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 short sentences, front-loaded with the core purpose, then the return shape, then the cost. 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?

For a two-parameter read tool with no output schema, the description sufficiently explains purpose, return contents, and pricing. It would be complete at 5 if it clarified how `limit` interacts with 'full' holder list and how it differs from holder_changes.

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 `mintAddress` (base58) and `limit` (default 25) are already fully documented. The description amplifies the return fields rather than adding syntax or edge-case guidance for the parameters, so the 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?

The definition opens with a specific verb and resource ('Get full holder list for a Solana token') and enumerates the return payload (top holders, balances, % of supply, distribution metrics), so the agent knows exactly what it does. It does not explicitly distinguish itself from the close sibling holder_changes, which is the main gap keeping this at a 4.

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 'with concentration analysis' hints at a use case but never states when to choose this over holder_changes, token_risk_score, or top_traders, nor any exclusions or prerequisites. Like the MID calibration example, this leaves the agent to infer the decision rule.

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 delivers: it labels the call 'lightweight', implies read-only via 'Get', and discloses a per-call cost of $0.001 USDC, which is the kind of behavioral detail an agent needs for budgeting. It omits rate limits and error behavior, 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?

Two compact sentences: first what it returns, then when to use it plus cost. Nothing is redundant and the highest-value information is 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?

With no output schema and no annotations, the description usefully enumerates the returned fields and the price, which is enough for an agent to decide and call. It could go further on return value formats (e.g., whether image is a URL) and failure modes, but it is adequate for a one-parameter read 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?

There is a single parameter (mintAddress) and schema coverage is 100%, with the schema already stating 'Solana token mint address (base58)'. The description adds no syntax, format, or validation detail beyond that, so the schema does all the work — baseline 3.

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?

Opens with a specific verb+resource ('Get token metadata') and enumerates the exact fields returned (name, symbol, decimals, supply, authorities, mutability, image), which implicitly separates it from token_price/token_holders/token_security siblings. It never names those siblings explicitly, so differentiation relies on inference from the field list.

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?

'Lightweight call — use before any new token interaction' gives a clear trigger condition for when to reach for this tool. It stops short of naming alternatives or stating when-not-to-use (e.g., if you only need price, use token_price), so it is strong context without exclusions.

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

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

No annotations are provided, so the description carries the full burden. It does add genuinely useful behavioral context: the returns (price, symbol, supply) and the per-call cost of $0.0005 USDC, which matters for agent budgeting. However, it omits error behavior for invalid mints, rate limits, and freshness/latency of the price.

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 short sentences, front-loaded with the core action and return values, ending with the cost constraint. Nothing is wasted and nothing important is buried.

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 single-parameter lookup with no output schema, the description covers what it returns and what it costs, which is enough to call it correctly. The one gap is price freshness/latency for a financial data tool, which an agent would reasonably want to know.

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% with a single required mintAddress param already documented as base58. The description's 'by mint address' phrasing adds no syntax or format detail beyond the schema, so the baseline 3 is appropriate.

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

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

States a specific verb and resource ('Get current USD price') and scopes it precisely to 'any Solana token by mint address', which distinguishes it from the generic crypto_price sibling. It stops short of naming the sibling directly, but the Solana/mint-address scoping makes the boundary clear enough.

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 the scoping ('Solana token by mint address'), but there is no explicit when-to-use/when-not guidance and no reference to alternatives such as crypto_price or pair_data. An agent can infer the fit but gets no routing help.

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

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

No annotations are provided, so the description carries the full burden. It does disclose two valuable behavioral facts the schema cannot express: the output is a 0-100 risk score and each call costs $0.005 USDC. It omits how payment/auth works, rate limits, cache behavior, and error handling for invalid mints.

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?

Two sentences, zero waste, with the deliverable (a 0-100 score) and its inputs front-loaded before the cost note. Everything 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?

For a single-parameter read tool with no output schema, this is nearly complete: it says what goes in, what comes out, how the score is derived, and what it costs. The remaining gap is the payment/auth mechanism for a paid endpoint, which an agent would need to know before calling.

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% with a single documented mintAddress parameter, so the schema does the heavy lifting. The description adds no syntax, format, or validity guidance beyond what the schema already says.

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 (analyze a Solana token's risk profile) and even names the components of the score: holder concentration, liquidity, distribution. It does not, however, differentiate itself from near-neighbors in the toolset such as token_security or dependency_risk_score, 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?

There is no when-to-use / when-not guidance and no alternative tool is named, despite several sibling risk tools existing. Usage is only implied by the tool's purpose sentence.

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 adds meaningful context: it discloses a pay-per-call cost ($0.005 USDC) and enumerates what the response contains. It doesn't cover permissions, rate limits, or failure modes, but the pricing and output disclosure is substantive beyond any structured field.

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?

Two tightly packed sentences: purpose first, output enumeration second, cost third. Zero filler, front-loaded, and 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?

For a read-only informational tool with no output schema, the description enumerates the key return fields and discloses cost, which is sufficient to call it correctly. It stops short of describing the risk-score scale or the exact response shape, but the core is covered.

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?

Only one parameter exists and schema coverage is 100%, so the schema already documents the base58 mint address. The description adds no format or validation detail beyond the schema, which is the expected baseline for a fully-documented single 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?

States a specific verb and resource ('Check if a Solana token is safe to trade') and enumerates the checks it performs (rug pull, honeypot, freeze/mint authority, insider networks, transfer fees, risk score). Clear purpose, though it does not explicitly distinguish itself from sibling token_risk_score.

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 'safe to trade' and the return fields; there is no explicit when-to-use versus alternatives like token_risk_score, token_holders, or token_metadata, and no exclusions or prerequisites beyond the single required input.

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

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

No annotations are provided, so the description carries the full burden. It does add genuinely useful non-schema context — the per-call cost of $0.01 USDC and the shape of the return payload — but it omits how many traders are returned, what 'most active and profitable' ranking means, and any rate or auth constraints.

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 short sentences, front-loaded with the action and resource, then the return payload, then the pricing caveat. No filler or repetition; every sentence carries information the agent needs.

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 the description compensates by summarizing the returned fields, including units (PnL in SOL) and cost. Minor gaps remain around result count and ranking methodology, but nothing blocks a correct invocation.

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?

Single parameter with 100% schema description coverage ('Solana token mint address (base58)'), so the schema already fully documents it. The description adds only the indirect phrase 'of a specific token', which does not go 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 and resource: 'Find the most active and profitable traders of a specific token', and enumerates what it returns (wallet addresses, volumes, PnL, trader type). This distinguishes it reasonably from holder-listing siblings like token_holders or wallet_pnl, though no sibling is named.

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 'traders of a specific token' — an agent can infer it is for per-token trader analysis. However, there is no explicit when-to-use vs. when-not, and no naming of alternatives such as smart_money, token_holders, or wallet_pnl that could serve overlapping needs.

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. It does add real value by disclosing the returned fields (type, transfers, swaps, fees, plain-English description) and a concrete price of $0.002 USDC per call, which is exactly the kind of cost signal an agent needs before invoking a paid endpoint. However, it says nothing about failure behavior for invalid or unknown signatures, rate limits, or latency.

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 sentences, each carrying distinct information: what it does, what it returns, and what it costs. Front-loaded with the action and free of 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 simple single-parameter read tool with no output schema, the description covers the essentials: the transformation performed, the shape of the result, and the per-call cost. The only meaningful gap is what happens when the signature is invalid, pending, or not found.

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?

Only one parameter, and it is fully documented in the schema ('Solana transaction signature (base58)', coverage 100%). The description adds no format or encoding detail beyond that, so the baseline 3 is appropriate — the schema does the work.

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 ('Parse a Solana transaction') plus the transformation goal ('into human-readable format'). No sibling in the list performs transaction decoding, so there is no ambiguity about which tool handles this job.

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 required signature parameter — an agent can infer 'use this when you have a signature and want a decoded view.' There is no explicit when-to-use, when-not-to-use, or named alternative, and no note about prerequisites such as the transaction needing to be on-chain or confirmed.

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

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

No annotations are provided, so the description carries the burden. It usefully discloses a paid cost ('$0.002 USDC per call'), which an agent needs for invocation decisions, but omits return format, result count, or ordering behavior beyond 'top trending'.

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 short sentences, front-loaded with purpose, then value, then cost. No sentence is wasted and the pricing caveat sits at the end where it belongs.

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 is simple (one optional parameter, no annotations, no output schema), so the description is nearly sufficient. It stops short of describing what a returned trending token entry contains or how many results to expect, which would help an agent interpret output.

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% with a single optional parameter already documented in the schema. The description reinforces that the chain filter is optional with an example set of values, adding mild scoping clarity 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+resource ('Get top trending/boosted tokens') and the source ('on DEXScreener'), so an agent can identify the function immediately. It does not explicitly contrast with near-siblings like new_pairs or dex_search, so it falls short of full sibling differentiation.

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

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

'Shows what's getting the most attention right now' implies a use case (attention/trend monitoring), and 'optionally filter by chain' clarifies scoping. However, it never says when to prefer this over alternatives such as new_pairs, top_traders, or dex_search, leaving selection 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 still discloses the two behaviors an agent most needs: the detection heuristic (1h vs 24h volume ratio) and the $0.002 USDC cost per call — a real spend consideration. It does not cover result ordering, caps, or pagination, so it stops short of full 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?

Three short sentences, front-loaded with what it returns, then the detection logic, then cost. No filler and no restatement of the title.

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 tool with no output schema, the description conveys enough to call it correctly and to judge cost. It could say more about the shape of the returned token list (fields, count, sorting), which the absent output schema leaves uncovered.

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 tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline of 4 applies; no parameter-level detail is missing.

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?

Names a specific verb and resource ('Find Solana tokens') and pins the exact condition ('recent 1h volume is disproportionately high vs 24h average'). This is clearly distinct from siblings like trending_tokens or new_pairs, which rank differently.

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?

'right now' and 'early signal for pumps' imply a real-time signal-hunting use case, but the description never says when to prefer this over trending_tokens, new_pairs, or whale_alert. 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 meaningful work: it discloses the $0.001 USDC per-call cost (critical for an agent's budget decisions) and signals a read-only, non-mutating operation via "get" and "lightweight check." It does not mention rate limits or whether the wallet must exist / what happens on an invalid address, leaving minor gaps.

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 short sentences, front-loaded with the capability, then the use case, then the cost. Nothing is redundant and each sentence contributes 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?

For a one-parameter read tool with no output schema, the description conveys what is returned (SOL plus all token balances), when to call it, and its cost — enough for correct invocation. Missing only edge-case behavior such as empty wallets or invalid addresses.

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 walletAddress parameter is fully documented as a base58 Solana address, so the schema does the heavy lifting. The description adds no format or validation detail beyond implying a single wallet scope; 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+resource+scope: SOL balance plus all token balances for a single Solana wallet. It is distinguishable from nearby siblings like wallet_pnl or wallet_profile by being a raw balance read, though it never names those siblings explicitly to draw the line.

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 before transactions to verify sufficient funds" gives a concrete trigger context. It stops short of stating when not to use it or naming an alternative (e.g., wallet_profile for historical holdings), so it is clear but not fully routing.

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. It usefully discloses cost ($0.05 USDC per call), data basis (swap history), output currency (SOL), and PnL types, but omits read-only status, permissions, time-window coverage, rate limits, and failure 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 three short sentences and front-loads the purpose before method and cost. Every sentence adds useful information: what it calculates, how it derives it, and the paid-call cost.

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 analytical tool with no annotations and no output schema, the description gives a reasonable high-level view of the result (realized/unrealized PnL per token in SOL) and the cost. However, it leaves out important context such as the time window analyzed, how unrealized PnL is valued, and what the response shape looks like.

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 walletAddress is fully documented in the schema as a base58 Solana wallet address. The description implies a wallet address is needed but adds no syntax, constraints, or validation details beyond the schema, matching the baseline of 3.

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 ('Calculate') and resource ('realized and unrealized PnL') scoped to a Solana wallet's token trades. It clearly differs from siblings like wallet_balance or wallet_profile, but does not explicitly name alternatives, so it falls short of a 5.

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

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

There is no explicit when-to-use or when-not-to-use guidance, nor routing to alternatives such as wallet_balance, transaction_parse, or token_price. Usage is only implied by the stated purpose, and the cost note does not substitute for selection 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 carries the full behavioral burden. It usefully discloses the per-call cost and returned fields, and “Get” implies a read operation, but it does not state permissions, rate limits, or other operational constraints.

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?

Two sentences, front-loaded with the core purpose and followed by the cost. Every sentence adds useful information without waste.

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

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

For a simple one-parameter read tool without annotations or an output schema, the description adequately explains the returned profile contents and the per-call cost. It could be more complete by clarifying when to prefer it over sibling wallet tools, but the core call context is present.

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?

There is one required parameter, walletAddress, and schema description coverage is 100%; the schema already documents it as a Solana base58 address. The description adds no additional parameter meaning beyond the schema baseline.

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 (“Get a complete wallet profile”) and enumerates the returned data: SOL balance, token holdings with USD values, NFT count, and top holdings. It does not distinguish this from close siblings like wallet_balance or wallet_pnl, so sibling differentiation is missing.

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 explains what is returned and notes the $0.005 USDC cost, but gives no guidance on when to use this tool instead of wallet_balance, wallet_pnl, or related wallet tools. The agent must infer the appropriate use case.

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 meaningful cost signal ('$0.001 USDC per call') plus the returned fields. It omits payment/auth mechanics, rate limits, data freshness, and unit conventions, which matter for an unpriced-looking paid endpoint.

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?

Two sentences with zero filler: purpose and output first, cost last. Every clause carries information the agent uses.

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?