Agent Einstein — Autonomous Crypto Intelligence

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It thoroughly describes the read-only snapshot nature and the contents of the returned payload. However, it does not disclose potential limitations such as whether the data is real-time, cached, or affected by the input parameters, and it does not explicitly state that it performs no mutation.

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 tool name and immediate verb, followed by a structured, semicolon-separated enumeration of content categories. It is long but every clause adds substantive detail about what the payload contains; the final sentence reinforces the use case without 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?

The description compensates for the absence of an output schema by enumerating the major return components in detail. However, it never connects the optional input parameters (chain, limit, timeperiod) to how they shape the output, and with no annotations some behavioral caveats are missing. For a complex contextual tool, this leaves a meaningful gap.

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

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

The input schema has 100% description coverage for all three parameters (chain, limit, timeperiod), so the baseline is 3. The tool description does not add any additional meaning to these parameters, nor does it explain how they relate to the 'full synthesised market view' described, leaving their effect on the output unclear.

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 clear verb+resource ('Returns Einstein's full synthesised market view') and enumerates the specific content it provides (BTC cycle phase, regime classification, macro vector, news classification, strategy rotator). It further distinguishes itself from siblings by calling itself 'The most complete what does Einstein think about the market right now payload', making its scope and position among related tools 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?

The description clearly states when to use it: 'ideal for grounding other agents' decisions in a coherent structured view of crypto + macro.' This provides a concrete use context, though it does not explicitly mention when not to use it or name alternative tools such as einstein_meta_strategy or einstein_trade_signals.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the methodology (in-house, from CoinGecko top-50 minus stables and BTC/ETH derivatives), the exact return fields, and even the contrarian sizing rule applied by the self-trade engine. This is exceptionally transparent.

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 sentences long but densely packed with valuable information—methodology, return fields, and usage guidance. Every sentence earns its place, and the key details are front-loaded.

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

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

No output schema exists, so the description must explain return values. It does so comprehensively, listing every returned component (90d/30d indices, delta, regime, top outperformers, underperformers, BTC anchor return, sizing rule). It also covers use cases, making it fully complete for a tool of this complexity.

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 baseline is 3. The description does not add any additional meaning to the parameters (chain, limit, timeperiod) beyond what the schema already provides, which is acceptable.

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

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

The description clearly states the tool computes a real-time Altcoin Season Index, distinguishing it from sibling analytics tools. It specifies the resource (altcoin season index) and the action (computed/returns), making its purpose unambiguous.

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

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

The description explicitly lists use cases: 'Use to time alt rotation, time BTC accumulation, or as a contrarian de-risk gate at index ≥75.' It provides clear context for when to use the tool, though it doesn't mention when not to use it or name alternative tools.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the types of approvals analyzed and the output (risk grading, USD value-at-risk), but it does not state whether the operation is read-only, what side effects exist, or any prerequisites/authentication needs. The parameter mismatch between 'address' in the description and 'tokenAddress' in the schema also undermines trust in behavioral expectations.

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 concise, front-loaded with the tool name, and packs a lot of useful detail into one sentence. The inclusion of 'Body: { params: { address, chain? } }' is slightly redundant and could be omitted, but overall it is efficient and not verbose.

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

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

Given the complexity of the tool and the absence of an output schema, the description should clarify return structures, supported chain details, and required parameters. It mentions some output characteristics (risk grading, USD value-at-risk) but fails to resolve the address/tokenAddress discrepancy, omits limit/timeperiod semantics, and incorrectly lists Solana in the chain enum despite claiming EVM chains only. This leaves the agent with insufficient context for 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?

The description adds meaning by identifying the wallet address parameter as 'address' and 'chain' as optional, which aligns only partially with the schema. However, it omits the 'limit' and 'timeperiod' parameters present in the schema, and it contradicts the schema's required 'tokenAddress' (which is absent from properties). The schema descriptions for chain, limit, and timeperiod are clear, but the description's incomplete and conflicting parameter mapping reduces its value.

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

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

The description clearly states the tool's function: 'Find risky token approvals for a wallet' and enumerates specific approval types (ERC-20, Permit2, ERC-721/1155) with risk grading and USD value-at-risk. It also specifies the scope across 9 EVM chains, distinguishing it from broader tools like security_scan. The verb 'Find' and resource 'risky token approvals' are specific and unambiguous.

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

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

The description implies when to use the tool—when needing to check wallet token approvals—but provides no explicit guidance on when not to use it or which sibling tools (e.g., security_scan, wallet_trust_score) to prefer. It lacks alternatives or exclusions, so the usage context is clear but not fully explicit.

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 merely describes the high-level function without disclosing any behavioral traits such as read-only access, data sources, rate limits, or the need for a token address. It adds no value beyond the tool name.

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

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

The description is a single, front-loaded sentence with no wasted words. It conveys the core purpose efficiently, though it is terse.

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

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

The tool has no annotations, no output schema, and a schema discrepancy around the required tokenAddress. The description provides only a vague label and does not explain expected output, prerequisites, or parameter requirements, making it incomplete for an agent to select and invoke 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?

While the schema includes descriptions for chain, limit, and timeperiod, the required tokenAddress parameter is missing from the properties entirely. The description does not mention tokenAddress or clarify parameter usage, leaving a significant gap in understanding how to invoke the tool.

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 the tool scans for cross-chain and cross-DEX price discrepancies for arbitrage opportunities, which clearly indicates an action (scanning) and a resource (price discrepancies). However, it does not explicitly contrast with sibling tools like cross_chain_arbitrage, which may serve a similar purpose.

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 guidance on when to use this tool versus alternatives such as cross_chain_arbitrage or flashloan_opportunities. The description only labels the tool's purpose without providing context 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?

No annotations are provided, so the description carries the full burden. It explicitly says 'Read-only research; no funds are moved,' a clear safety disclosure, and mentions it returns 'sensible defaults the agent chose' – revealing a key behavior. It does not mention rate limits or data sources, but these are less critical for a backtest.

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

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

The description is a single, dense sentence that efficiently conveys inputs and outputs. It includes both the strategy specification options and the return metrics, with no filler, though it is somewhat lengthy due to the enumerated list.

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 thoroughly lists return values (total return, equity, win rate, Sharpe/Sortino, max drawdown, equity curve) and the read-only nature, which is especially important given no output schema. However, the mismatch between the described strategy inputs and the actual schema parameters leaves a significant gap in understanding how to invoke the tool correctly.

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

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

The schema has 3 parameters (chain, limit, timeperiod) with descriptions, so schema coverage is 100%. However, the tool description talks about strategy parameters like stop-loss and leverage that are not present in the schema, leaving a disconnect. The description does not explain how these schema parameters map to the strategy backtest, so it adds no semantic value beyond the schema and actually introduces confusion.

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 'Custom Strategy Backtest' and explicitly states the tool 'get[s] an event-driven, intrabar backtest' with detailed outputs, distinguishing it from sibling backtest tools by its plain-language strategy input. The verb 'get' and resource 'backtest' are specific, and the description clearly separates it from tools like backtest_strategy or strategy_backtest.

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 instructs users to 'Describe a rule-based breakout strategy in plain language' and notes 'Read-only research; no funds are moved,' which implies the tool is for custom, non-execution backtests. However, it does not explicitly name alternative tools or state when not to use it, leaving some inference to the agent based on sibling names.

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 output metrics, method (candle-replay, walk-forward), and performance ('results come back in seconds'), but it omits any potential side effects, prerequisites, or limitations. It also fails to mention that the schema parameters differ from the described inputs, which is a behavioral transparency gap.

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

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

The description is three sentences, front-loaded with the core purpose, and each sentence adds useful detail (method, outputs, input hints). It is slightly verbose with phrases like 'as a Service' and 'results come back in seconds', but overall it is efficient for a tool of this complexity.

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 complexity of the tool (backtest with multiple adapters and folds) requires a clear explanation of inputs, but the description references parameters not in the schema and fails to explain the actual schema parameters (chain, limit, timeperiod). This vital mismatch makes the description incomplete and potentially harmful for an agent attempting to invoke the tool.

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

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

The description explicitly lists parameters ('adapter id + symbol + timeframe + fold config') that do not exist in the input schema, which instead has 'chain', 'limit', and 'timeperiod'. This is actively misleading and contradicts the schema. Even though the schema has 100% description coverage, the description undermines it by suggesting nonexistent 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 clearly states a specific action ('Run a candle-replay backtest with walk-forward cross-validation') and identifies the resource (Einstein's 4 production-grade strategy adapters). It also distinguishes itself from sibling tools like backtest_custom_strategy by emphasizing the use of pre-built adapters.

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 context: it is for vetting a strategy on out-of-sample data before risking capital. However, it does not explicitly mention alternatives or exclusions (e.g., 'for custom strategies, use backtest_custom_strategy'). No direct sibling comparison is offered.

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. The verbs 'compare,' 'track,' and 'view' imply a read-only analysis tool, which is useful. It also specifies the data sources (wBTC, cbBTC, tBTC, THORChain). However, it does not disclose rate limits, data freshness, or whether any authentication is required.

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

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

The description is a single, well-structured sentence that front-loads the three core functions without any fluff. Every part contributes to understanding the tool's purpose.

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 adequately explains the tool's main outputs (volume comparisons, peg deviations, THORChain stats) and compensates for the lack of an output schema. Combined with the schema, which explains the parameters, an agent can understand what the tool does and what data to expect.

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

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

The input schema has 100% coverage, with each parameter already described (chain, limit, timeperiod). The tool description adds no additional parameter-specific semantics, 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 clearly states the tool's function with specific verbs (Compare, track, view) and resources (Bitcoin bridges, wrapped BTC peg, THORChain BTC pool). It distinguishes itself from sibling tools like arbitrage_scanner or cross_chain_arbitrage by focusing on bridge volumes and peg deviations.

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 context: it is for comparing Bitcoin bridges and monitoring wrapped BTC pegs. However, it does not explicitly mention when to use this tool over alternatives or provide exclusion criteria. The implied usage is clear but not fully elaborated.

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 of behavioral disclosure. It mentions outputs (congestion level, fee tiers, ETA) but fails to disclose that the input schema's 'chain' parameter only accepts non-Bitcoin networks, contradicting the 'Bitcoin Mempool' framing. This significant discrepancy is not addressed, and no limitations or special behaviors are noted.

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

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

The description is a concise two-sentence summary, front-loaded with the tool's purpose and specifics. No unnecessary words or repetition; it earns its length.

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

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

For a tool with no output schema and no annotations, the description should explain return structure, supported chains, and usage scenarios. It lists key outputs but omits the chain discrepancy and gives no usage context relative to sibling tools, leaving the agent with incomplete information.

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

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

The input schema has 100% coverage with descriptions for all three parameters, so the baseline is 3. The description adds no additional parameter-level meaning, and actually creates confusion by implying Bitcoin focus while the 'chain' enum excludes bitcoin. No compensation for this mismatch is offered.

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

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

The description clearly states the tool provides real-time Bitcoin mempool analytics, fee estimation, and transaction tracking, naming specific outputs like congestion level and confirmation ETA. However, it does not distinguish it from the sibling tool 'mempool_watch', which likely overlaps in function.

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 no explicit guidance on when to use this tool versus alternatives like 'mempool_watch' or 'bitcoin_onchain_analytics'. No when-to-use or when-not-to-use conditions are provided, leaving the agent to infer applicability.

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 lists analytics categories but does not disclose whether the tool is read-only, any rate limits, or typical output structure. The schema's chain enum (excluding bitcoin) also conflicts with the described Bitcoin-only scope.

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

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

The description is a single, compact sentence with a colon-separated list of features. It is front-loaded with the primary domain and contains no filler 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?

With no output schema and no annotations, the description should provide more context about return values or limitations. The listed features give a sense of scope but are insufficient for an agent to confidently invoke the tool and interpret results, especially given the unclear chain parameter.

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% for all three parameters, so the baseline is 3. The description adds no parameter-specific details, and the mismatch between the Bitcoin-focused narrative and the chain enum (which lacks a bitcoin option) could mislead parameter selection.

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

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

The description clearly identifies the tool as 'Bitcoin Network & Mining Analytics' and lists specific features like hashrate trends and mining pool distribution, which distinguishes it from siblings like bitcoin_mempool_intelligence. However, the input schema's 'chain' parameter includes non-Bitcoin networks and no 'bitcoin' option, creating ambiguity about the tool's actual scope.

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 guidance on when to use this tool versus alternatives. The description implies Bitcoin-focused analytics but does not state exclusions or name any alternatives, and the chain parameter mismatch further complicates 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 provided, the description carries the burden of behavioral disclosure. It lists the types of data returned (TVL, leaderboards, delegations), which provides some transparency, but it does not explicitly state that the tool is read-only, whether historical data is returned, or any rate limits or prerequisites.

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

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

The description is a single sentence but contains redundancy: 'Babylon Bitcoin Staking Analytics:' is immediately followed by 'Babylon staking analytics', repeating the same topic. It could be more concise and front-loaded by dropping the prefix and starting with the action.

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 that there is no output schema, the description provides a fairly complete overview by listing four main analytics categories. It covers the scope of the tool well, though it could additionally mention how limit and timeperiod affect results, but those are already described in the schema.

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

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

The input schema has 100% coverage with descriptive parameter definitions for chain, limit, and timeperiod. The description does not add any additional meaning to these parameters, such as how they relate to the listed analytics features or expected value formats, so the baseline score of 3 is appropriate.

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

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

The description clearly identifies the tool as 'Babylon Bitcoin Staking Analytics' and enumerates specific data categories: global TVL stats, finality provider leaderboards, staker delegation positions, and individual delegation tracking. This specific verb+resource scope distinguishes it from sibling tools like bitcoin_onchain_analytics or defi_yield_analysis.

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 context by focusing on Babylon staking analytics, but it does not explicitly state when to use this tool versus alternatives or mention exclusions. No guidance is given about scenarios where other analytics tools would be more appropriate.

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

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

With no annotations, the description must carry behavioral disclosure. It mentions 'via UniSat API' but does not explain behavior such as rate limits, return format, or the fact that the chain parameter accepts non-Bitcoin chains despite BRC-20 focus. This is a significant gap.

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

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

One sentence with no filler; it efficiently states the core functionality. However, it is a single fragment-style sentence that could be more structured for readability.

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 and sparse description mean the agent doesn't know what response structure to expect. The list of data types is helpful but insufficient, and the chain parameter's inconsistency is not addressed.

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 covers 100% of parameters with descriptions, so the baseline is 3. The tool description adds no additional meaning to parameters like chain, limit, or timeperiod.

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

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

The description clearly identifies the tool as providing BRC-20 token analytics with specific data types (overview, mint progress, holder distribution, details) via UniSat API. However, it lacks an explicit verb like 'get' or 'fetch' and doesn't distinguish from sibling tools like runes_analytics.

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

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

No guidance is given about when to choose this tool over alternatives. It simply describes what it does; usage is only implied by the domain-specific name.

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. It discloses an important behavioral trait: 'Fails loud if the forecast service is unavailable — no charge,' and it details the return structure (drift %, direction, quantile bands, confidence assessment). This is transparent about error handling and output, though it does not mention rate limits or data sourcing.

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

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

The description is a single dense paragraph, with the core purpose front-loaded. However, it includes extraneous details about alternative REST endpoints and model catalogs that are not necessary for invoking this tool. It could be more concise by trimming the latter half, though the structure is not poorly organized.

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 thoroughly covers the tool's function, return values, input types, and error behavior, which is especially important given there is no output schema. However, it leaves gaps such as what 'multi-horizon' specifically means (which horizons) and the exact relationship between the optional parameters and the forecast, so it is not fully complete.

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

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

Although the schema has 100% description coverage for its three parameters (chain, limit, timeperiod), the description introduces an input not present in the schema: 'Accepts EVM contracts or canonical symbols (BTC, ETH, ADA, BNB, DOT, ...).' This creates confusion, as the agent cannot map this to any actual parameter, and the description adds no value that aligns with the schema.

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

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

The description opens with 'AI Chart Forecast (TimesFM + Kronos): Dual-model ML price forecast,' using a specific verb+resource pair that clearly states what the tool does. It distinguishes itself from sibling tools by naming the specific models (TimesFM, Kronos) and the unique return values (quantile bands, CONSENSUS/DIVERGENCE classifier), making its purpose unmistakable.

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

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

The description implies the tool is for ML-based price forecasting but provides no explicit guidance on when to use it versus alternatives like technical_analysis or einstein_trade_signals. It does not mention any exclusions or prerequisites, so the context is clear but not differentiated.

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 responsibility. It does disclose the default cross-chain scanning behavior and the data source (Merkl), but does not state that the operation is read-only, nor does it describe error behavior, rate limits, or authorization needs. This level of disclosure is partial, so 3.

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 compact, with only three sentences. The first sentence front-loads the purpose and output details, the second adds behavioral nuance about chain scanning, and the third is a redundant body snippet. There is no filler or excessive length, so 5.

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

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

Despite the clear purpose, the description is incomplete due to the missing address in the schema and the lack of any mention of limit/timeperiod in the description. With no output schema, the description should provide more context on return structure and pagination. The discrepancy between the described body and actual schema undermines the description's completeness, so 2.

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

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

The input schema already fully describes the three parameters (chain, limit, timeperiod) with descriptions and enums, giving a baseline of 3. However, the description's 'Body: { params: { address, chain? } }' introduces an 'address' parameter that is absent from the schema, and omits the schema's limit and timeperiod. This active misalignment makes parameter guidance misleading, so 2.

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 'Check' and identifies the exact resource (wallet airdrops via Merkl), and lists output fields (token, amount, USD value, claim link). It distinguishes from siblings by focusing on unclaimed airdrops, a unique niche among the large sibling 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?

The description clearly states the use case: checking a wallet for unclaimed airdrops and reward campaigns. It does not explicitly mention exclusions or alternative tools, but the context is unambiguous. This earns a 4 rather than 5 because no when-not-to-use guidance is given.

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 burden of disclosing behavior. It mentions 'risk-adjusted position sizing,' which implies the tool outputs sizing recommendations, but it does not state whether the tool is read-only, whether it executes trades, or any rate limits or authentication needs. The word 'Analyze' suggests a non-destructive action, but this is implicit.

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

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

The description is a single, front-loaded sentence that uses a colon to introduce the purpose. It contains no redundant words and directly communicates the tool's function without unnecessary elaboration.

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

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

The tool has no output schema, so the description should clarify what results the agent can expect. It does not describe the return format (e.g., wallet addresses, signal scores, position sizes) or any additional behavioral details. Given the tool's simplicity and the rich schema, a bit more explanation of the output would improve completeness, but it is not severely lacking.

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 fully documents chain, limit, and timeperiod. The description does not add any additional meaning about parameter relationships, expected values, or how parameters influence the analysis. Baseline 3 is appropriate since the schema handles 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 clearly states the tool's function: 'Analyze top-performing wallets for copy trading signals with risk-adjusted position sizing.' The verb 'Analyze' is specific, the resource is 'top-performing wallets,' and the purpose (copy trading signals with position sizing) distinguishes it from siblings like copy_trading_leaderboard.

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 copy trading analysis but provides no explicit guidance on when to use this tool versus alternatives, nor does it mention exclusions or specific scenarios. It does not reference sibling tools or differentiate from similar ones such as smart_money or copy_trading_leaderboard.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does not state that the operation is read-only, nor does it mention any side effects or limitations. It only describes the output content, not the behavior of the 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 a single sentence that front-loads the tool's purpose and key output features. It is concise and free of unnecessary detail, making it easy for an agent to parse quickly.

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

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

For a simple leaderboard tool with no output schema, the description gives a reasonable sense of what data is returned (performance, win rates, P&L). However, it lacks detail on the exact response structure. The schema fully documents parameters, so the description is adequate but not exhaustive.

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 for parameters is 100%, with clear descriptions for chain, limit, and timeperiod. The tool description adds no parameter-specific meaning beyond what the schema already provides, 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 clearly identifies the resource (copy trading leaderboard) and specifies what it provides (top wallets with performance data, win rates, and P&L metrics). It does not explicitly differentiate from the sibling tool 'copy_trading_intel', but the leaderboard concept is distinct 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?

No guidance is provided on when to use this tool versus alternatives like copy_trading_intel. There are no explicit exclusions or prerequisites, leaving the agent to infer usage solely from the tool's name and description.

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 burden. The word 'Scanner' suggests a read-only operation, and it discloses that net profit calculations include bridge fees. However, it does not explicitly state that the tool performs no on-chain actions, nor does it mention rate limits, data sources, or potential variability in 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?

The description is a single sentence that front-loads the tool's title and purpose, followed by a concise elaboration. Every word adds value, with no fluff 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?

The tool is a scanner with 3 optional parameters and no output schema. The description mentions net profit calculations, which implies return values, but it does not describe the output structure, sorting, or filtering behavior. Given its moderate complexity, more detail on what results contain would be helpful.

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 all three parameters, each with descriptions and enums. The description adds minimal parameter-specific context beyond what the schema provides, so it meets the baseline for a well-documented schema.

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

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

The description clearly states the tool's function: detecting price discrepancies across chains and DEXes, and calculating net profit after bridge fees. This is specific and distinguishes it from sibling tools like 'arbitrage_scanner' and 'polymarket_arbitrage' by focusing on cross-chain DEX arbitrage.

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

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

No explicit guidance on when to use this tool versus alternatives. The description implies it is for cross-chain arbitrage scanning but does not mention when to use it over 'arbitrage_scanner' or other arbitrage tools, nor does it state any 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, the description carries full responsibility for behavioral disclosure. The description claims the tool runs quantum circuits on IBM hardware, but the schema parameters imply a different behavior (querying blockchain data). This contradiction misleads the agent about the actual operation, and no safety or side-effect information is provided.

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

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

The description is a single sentence and reasonably concise, front-loading the core purpose. However, it relies on acronyms like CRQC and ECDSA without expansion, which may reduce clarity for agents less familiar with these terms.

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

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

The tool has no annotations, no output schema, and a moderate 3-parameter schema. The description fails to explain how the schema relates to the stated purpose, and it does not cover expected output, cost, latency, or data handling. This is completely inadequate for reliable tool selection and 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?

The schema provides descriptions for all three parameters (chain, limit, timeperiod), so baseline is 3, but the description completely ignores these parameters and instead references quantum benchmark circuits. This active misalignment confuses rather than clarifies the parameter meanings, providing no useful semantic addition.

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 activity ('Run standardized benchmark circuits on real IBM quantum hardware') but the input schema clearly expects blockchain network parameters (chain, limit, timeperiod). This mismatch makes the tool's purpose ambiguous, as the agent cannot determine whether the tool performs quantum benchmarking or blockchain data analysis.

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

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

No guidance is provided on when to use this tool or how it compares to the many sibling tools. There is no mention of alternatives, prerequisites, or usage context, leaving the agent without direction.

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 discloses the scan is for finding opportunities (read-only implied) and adds useful context about risk-adjusted returns and gas cost analysis. However, it does not specify the return format, any side effects, or limitations, which would improve transparency.

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

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

The description is a single, front-loaded sentence with no redundant or filler content. It efficiently states the tool's purpose and its two key differentiators (risk-adjusted and gas cost analysis).

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 3 optional parameters and no output schema, the description is adequate for understanding what the tool does but lacks details about the return structure and behavioral specifics. It is sufficient for initial selection but not fully complete for invoking the tool.

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

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

Schema coverage is 100% and each parameter has a clear description. The tool description adds no extra meaning beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb 'Scan' with a clear resource 'DeFi protocols' and specifies the output 'highest risk-adjusted yield opportunities with gas cost analysis.' It clearly differentiates from other yield tools like yield_discover or yield_deposit by emphasizing analysis and gas cost.

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 use when looking for DeFi yield opportunities, but it does not explicitly contrast with sibling tools such as yield_discover, yield_rebalance, or pendle_yield_trading. No when-not or alternative guidance is provided, leaving selection context ambiguous.

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 full transparency burden. It discloses rich behavioral detail: the risk geometry, take-profit anchoring to the forecast frame, and the stop that can widen but never tighten. However, it does not state whether the tool executes trades or only recommends, nor does it mention output format or side effects.

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 the first front-loading purpose and the second providing behavioral detail. It is well-structured but somewhat dense with technical specifics (TimesFM 2.5, Kronos q10–q90) that may be more than needed for invocation, making it slightly longer than optimal.

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 complex with no output schema and no annotations. The description gives strong behavioral context, but leaves gaps: no return value description, no parameter-effect explanation, and no indication if trades are executed. This is incomplete for autonomous invocation, though more than minimal.

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 baseline is 3. The description adds no parameter-specific meaning beyond the schema; it does not explain how chain, limit, or timeperiod affect the meta-strategy. The description is entirely about behavior, not 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 clearly states the tool is an AI-driven meta-strategy that decides what to trade across all asset classes, using a specific verb ('decides what to trade') and resource scope. It distinguishes itself from sibling tools like einstein_trade_signals by focusing on the meta-level strategy rather than individual signals.

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 mentions running on each execution cycle, providing a scheduled context, but does not explicitly state when to prefer this tool over alternatives such as einstein_trade_signals or strategy_gate. The reference to chart-forecast gives some relationship but no clear 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 are provided, so the description carries the burden. It discloses the data content (rank, momentum, regime, news, macro, cycle) and mentions the paid nature and mirroring payload, but does not discuss rate limits, authentication, or potential side effects of mirroring trades. This is useful 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?

The description is three sentences, each adding substantive value: purpose, output detail, and use case. It is front-loaded with the core function and avoids fluff, though it is longer than the minimum viable.

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 or annotations, the description compensates by detailing the returned signal context and the action payload. It provides enough for an agent to understand the tool's purpose and output richness, but misses operational details like authentication and cost structure beyond 'paid'.

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

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

The input schema covers 100% of the parameters with descriptions, so baseline is 3. The description adds no further detail on chain, limit, or timeperiod beyond the schema, focusing instead on the output data and use case.

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

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

The description clearly states the tool 'Streams Einstein's recent autonomous trade signals' with specific resource and action. It distinguishes itself by mentioning 'paid A2A skill' and contrast with public APIs, though it does not explicitly name alternative sibling tools for comparison.

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 provides explicit context: 'Subscribers can mirror trades' and it's 'for agent-to-agent automation pipelines that prefer the unified A2A protocol.' This indicates who should use it and why, though it lacks explicit 'when not to use' alternatives.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context like 'real-time' and 'profit estimation', suggesting a read-only scanner with computed estimates. However, it does not disclose output format, pagination, rate limits, or whether input chains are validated. This is moderate transparency for a scanner.

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

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

The description is a single sentence with a clear title prefix, front-loaded with the tool name and purpose. It contains no redundant words and earns its place efficiently.

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

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

Given the tool has 3 optional parameters, no output schema, and no annotations, the description covers the core purpose but lacks details on return structure and operational constraints. It would be more complete if it mentioned whether results are a list, how the timeperiod affects analysis, or any prerequisites. It is adequate but not comprehensive.

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?

All three parameters (chain, limit, timeperiod) have existing schema descriptions covering enums, defaults, and meaning, so schema coverage is 100%. The description adds no additional parameter-level detail, so the baseline of 3 applies. It does not clarify relationships between parameters or usage examples.

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

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

The description clearly states the tool scans for flashloan opportunities across MEV, liquidation, DEX arbitrage, and cross-chain scenarios with profit estimation. It uses a specific verb (scanner) and resource, and the listed categories help distinguish it from generic arbitrage or MEV tools, though it does not explicitly contrast with similarly named 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?

There is no guidance on when to use this tool over alternatives such as arbitrage_scanner, cross_chain_arbitrage, or mev_detection. The description only implies real-time scanning but does not state preferred use cases, exclusions, or alternatives. This leaves the agent uncertain about tool selection.

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 provided, so description carries the burden. It adds behavioral context by stating assets are priced via DefiLlama and that recovery hints are included. However, it doesn't disclose read-only status, rate limits, or what happens with the limit/timeperiod parameters.

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 relatively short but the appended 'Body: { params: { address, chain? } }' is unnecessary and incorrect, and the single run-on sentence mixes function with parameter details. It lacks clean structure and includes an inaccurate snippet.

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, and the description doesn't explain return format, how limit/timeperiod affect results, or what 'recovery hints' concretely are. The address/tokenAddress mismatch further undermines completeness. Moderate complexity tool deserves more.

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 has 100% description coverage, so baseline should be 3, but the description explicitly states body params { address, chain? } while schema's required param is tokenAddress and also includes limit/timeperiod. This is misleading and contradicts the schema, providing negative value.

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?

Clearly identifies a specific function: finding forgotten/dust ERC-20 balances and locked ETH in legacy contracts, with DefiLlama pricing and recovery hints. It distinguishes from siblings like claimable_airdrops and wallet_pnl. However, 'for a wallet' conflicts with the schema's required tokenAddress, creating ambiguity about the input resource.

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

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

Implied usage: use this when you need to discover forgotten assets for a wallet. No explicit when-not-to-use or alternative tool comparisons are given, but the intended scenario is reasonably inferable from the description.

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?

The description discloses a key behavioral trait: Agent Einstein 'autonomously selects tools,' which is not inferable from the schema or annotations. However, it doesn't specify whether these selections could include side-effectful actions (e.g., trades, deposits) or what the response format will be, leaving some ambiguity about its safety profile.

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 two sentences, front-loaded with the tool's name and core function, and contains no filler. The first sentence defines what the tool does, and the second provides usage guidance, making every word earn 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 high-complexity agent tool with no annotations and no output schema, the description gives a decent high-level overview but omits important details such as the scope of tool selection, potential side effects, and output format. It adequately covers the basics but leaves gaps for an agent that can autonomously invoke other 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?

The schema has 100% coverage for the single 'prompt' parameter, with the description 'The question or analysis request to send to Einstein AI.' The tool description adds no additional parameter semantics beyond what the schema already states, so the baseline of 3 applies.

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

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

The description clearly states the tool's function: 'Send any prompt to Agent Einstein who autonomously selects tools, analyzes data, and provides intelligent responses.' This gives a specific verb (send) and resource (Agent Einstein), and distinguishes it from the long list of specialized sibling tools by positioning it as the general-purpose fallback.

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

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

Explicit usage guidance is provided: 'Use for complex questions requiring reasoning or multi-step analysis.' This tells the agent when this tool is appropriate, though it doesn't explicitly name alternative tools for simpler or more specific queries.

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 discloses the full pipeline (voiceover script, DALL·E stills with ken-burns motion, TTS, captions, mp4 rendering), typical render time (40–90s), the embedded 'Made with AI' disclosure, and the exact response shape. This is exceptional behavioral transparency for a tool with no structured safety hints.

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 with the core purpose, and every sentence adds a distinct fact (pipeline, timing, input format, output shape). It could be better structured to separate input/output details, but it contains no filler.

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

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

For a complex generative tool with no output schema and no annotations, the description covers the return shape and behavior well. However, the disconnect between the documented schema parameters and the prompt-based invocation leaves significant ambiguity about how to actually call the tool, which damages completeness.

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

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

The input schema documents chain, limit, and timeperiod, but the description instructs agents to send a 'prompt' that does not exist in the schema. This mismatch leaves the agent uncertain about which parameters are actually valid and what role the schema fields play, so the description adds only partial, conflicting parameter guidance.

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 ('Generate a short branded vertical (9:16) AI video from a text prompt') and provides unique pipeline details (DALL·E stills, TTS, captions, mp4) that distinguish it from the crypto-analytics sibling tools. The purpose is unmistakable.

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

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

It gives a concrete invocation format ('Send { params: { prompt } } with your brief') and an example brief, making the intended use clear. It doesn't explicitly name alternatives or when-not-to-use, but no sibling offers video generation, so the usage context is sufficient.

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 full burden of behavioral disclosure. It implies a read-only analysis but does not explicitly state whether it is safe, what data it returns, whether it has rate limits, or whether it uses the token address as the primary input. With no output schema, the absence of behavior details is a notable shortfall.

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

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

The description is a single, compact sentence that avoids redundancy and gets straight to the point. However, it is extremely brief, almost to the point of under-specification, which prevents a perfect score. Still, it earns points for being efficient and 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 should clarify what the tool returns (e.g., a list of holders, a risk score, or a breakdown). It does not. The tool also has 4 parameters, including a required token address, but the description does not explain how these inputs relate to the analysis. Overall, the description is incomplete for an analytical 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?

The input schema already has full descriptions for all 4 parameters (100% coverage), including enums and defaults. The description adds minimal extra meaning beyond stating the overall analysis type, which is insufficient to elevate the score above 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 clearly identifies the tool's purpose: analyzing token holder distribution and concentration risk. It uses a descriptive noun phrase plus an explanatory clause, making it clear what kind of analysis is performed. However, it lacks a strong active verb (e.g., 'calculates' or 'analyzes'), which slightly weakens clarity and differentiation from sibling analytics tools.

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

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

The description provides no guidance on when to choose this tool over alternatives. Siblings like whale_tracking and smart_money also deal with holders/investors, but no distinctions or use-case context are given. This is a clear 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 carries the transparency burden. It clarifies this is a read-only intelligence tool and mentions output types, but omits details like data freshness, pagination, or whether the leaderboard is real-time. It does not hide side effects (likely none), but lacks deeper behavioral context.

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 tool name and core capability. Every word adds value, with 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?

The description is reasonably complete for a simple data lookup, but the chain parameter introduces ambiguity (why can you select Base/Ethereum if this is Hyperliquid-specific?). No output schema exists, so the description should clarify return details, but it only gives a high-level summary.

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

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

Schema coverage is 100%, so the baseline is 3. The description does not add parameter-level semantics beyond what the schema already documents. It doesn't connect parameters like 'chain' or 'timeperiod' to the stated features, which could have been useful given the Hyperliquid naming mismatch.

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 (Hyperliquid) and the exact data types (leaderboard, whale positions, consensus signals) with a clear outcome ('bullish or bearish'). It distinguishes itself from generic siblings like 'smart_money' by explicitly scoping to Hyperliquid.

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 Hyperliquid-related smart money data, but provides no explicit guidance on when to choose this over similar siblings (e.g., smart_money, whale_tracking). The chain parameter allows multiple networks, which conflicts with the Hyperliquid-only implication, adding ambiguity.

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 disclose behavioral traits. It does not explicitly state whether the tool is read-only, how it handles data freshness, or any side effects. The word 'Monitor' hints at passive observation but is not explicit.

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

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

The description is a single sentence, front-loaded with the tool's purpose, and contains no wasteful content.

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

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

With no output schema or annotations, the description gives a high-level purpose but does not describe the output format, how the timeperiod parameter affects results, or any edge cases. It is minimally adequate for a simple monitor 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%, so the baseline is 3. The description does not add substantial meaning beyond the schema, although it mentions health factors and bonus estimates which are not directly mapped to the 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 clearly states the tool monitors Aave/Compound positions approaching liquidation, specifying health factors and bonus estimates. This is a specific verb+resource and distinguishes it from sibling tools like defi_yield_analysis or arbitrage_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 description implies usage for monitoring liquidation risk but provides no explicit guidance on when to use this tool versus alternatives. No exclusions or alternative tool mentions are given.

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 must fully disclose behavioral traits, but it only states that the tool detects price action and momentum. It does not explain what 'significant' means, whether the tool is read-only, how results are ranked, or any limitations. This leaves key behavioral context missing.

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

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

The description is a single sentence and immediately states the core action, making it efficient and front-loaded. The recurring 'Market Movers' label is slightly redundant with the tool name but not wasteful enough to lower the score further.

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

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

Given the lack of an output schema and the presence of several closely related sibling tools, the description is too sparse. It does not explain what the returned data looks like, how to interpret results, or how this tool differs from top_gainers and technical_analysis, leaving the agent with significant ambiguity.

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

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

The input schema fully documents all three parameters (chain, limit, timeperiod) with descriptions and enums, so schema coverage is 100%. The description adds no additional parameter-level meaning, but the baseline of 3 is fair since the schema already carries the load.

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

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

The description clearly states the tool's function: 'Detect significant price action and momentum signals across DEXes.' It uses a specific verb and resource, and the DEX scope adds some differentiation. However, it does not distinguish itself from sibling tools like top_gainers or technical_analysis, which likely overlap in purpose.

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 no guidance on when to use this tool versus alternatives. It does not mention use cases, prerequisites, or contrast with related tools, leaving the agent to infer suitability from the name alone.

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

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

No annotations are provided, so the description carries the full burden. It adds useful context such as the short time window, supported chains, and the type of insights returned. However, it fails to explain subscription lifecycle (e.g., one-shot vs streaming), and it mentions an optional address filter that is not present in the schema, creating a behavioral mismatch.

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 sentences, front-loaded with the core purpose and time window, followed by output details and supported chains. Every sentence adds distinct value, with no fluff 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?

The description covers the main outputs and supported chains, but lacks important context for a real-time subscription tool: how results are returned, whether persistent connection is needed, and the significance of the long timeperiod values. The phantom address filter and chain mismatch further reduce completeness, especially with no output schema.

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 introduces an 'optional address filter' not in the schema, and the supported chain list contradicts the schema's inclusion of solana. The description adds no helpful parameter guidance beyond what the schema already provides, and the discrepancies actively mislead.

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

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

The description clearly states the tool performs live mempool subscription for EVM chains and lists specific insights (frontrun candidates, bot detection, gas distribution). However, the mention of a short 30–120s window conflicts with the schema's timeperiod values (1h–30d), and the chain support list excludes solana despite the schema allowing it, which introduces ambiguity.

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 short-term mempool monitoring, specifying supported chains and output types. It provides clear context but does not explicitly mention when not to use it or name alternatives like mev_detection or bitcoin_mempool_intelligence, so it falls short of the highest level.

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 must convey behavioral traits. It only says 'analysis' which implies a read-only operation, but provides no details on output format, permissions, rate limits, or side effects. This is insufficient for a tool with no annotation coverage.

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

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

The description is a single concise sentence that front-loads the core function. It contains zero redundant words and communicates the essential purpose immediately.

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 lacks essential context about expected outputs, default behavior, or how results are presented. Beyond the parameter schema, there is no explanation of what the tool returns or any limitations. For a tool with no output schema and no annotations, this is a notable gap.

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

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

Schema description coverage is 100%, so the schema fully documents the three parameters (chain, limit, timeperiod) with clear descriptions and enums. The tool description adds no additional parameter context, which is acceptable given the schema's completeness.

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

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

The description clearly identifies the tool as MEV detection, listing specific attack types (sandwich, front-running) and toxic flow analysis. It distinguishes from sibling 'mev_protection' by focusing on detection/analysis rather than protection, though it lacks an explicit verb like 'detect'.

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

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

No guidance is provided on when to use this tool versus alternatives like 'arbitrage_scanner' or 'mempool_watch'. The description states only what it does, not when or why to choose it.

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 must disclose behavioral aspects, but it only states high-level actions. It does not mention whether this is analysis-only, if it requires wallet access, if it sends transactions, or how recommendations are generated. The lack of such context is a significant gap.

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

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

The description is a single, focused sentence with a clear structure. It front-loads the tool name and action, contains no filler, and effectively communicates the core purpose within one line.

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

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

The tool has no output schema and no annotations, so the description must explain what the user gets. It mentions 'recommend strategies' but lacks detail on response format, what 'transactions' refers to given no transaction parameter, and how chain/timeperiod/limit shape the analysis. This is inadequate for a 3-param analysis 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 parameters are already documented. The description does not add semantic meaning beyond the schema, such as how 'limit' or 'timeperiod' affect the analysis, but the baseline of 3 is appropriate when the schema fully covers 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 clearly states the tool analyzes transactions for MEV vulnerability and recommends private mempool routing strategies, which differentiates it from the sibling mev_detection. However, 'transactions' is ambiguous—it doesn't specify user transactions vs. general mempool transactions, so it's not fully precise.

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

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

No guidance is provided on when to use this tool versus alternatives like mev_detection. The description does not mention prerequisites, typical scenarios, or exclusions, leaving the agent without context for selection.

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 must disclose behavior; it describes the return value (score 0-10, rationale, approve/reject/flag) which is helpful. However, it does not disclose whether the operation is read-only, how the input parameters (chain, limit, timeperiod) affect judging, or any side effects, leaving a gap.

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

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

The description is two meaningful sentences: one states the purpose and criteria, the other states return value and intended contest types. Every sentence adds value with no fluff; purpose 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?

The description adequately covers purpose and return, but given the lack of output schema and the confusing set of query-like parameters, the description should explain how these parameters factor in (e.g., retrieving submissions from a chain). Without that, the description is not fully complete for an agent to invoke 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 covers 100% of parameters with descriptions, so baseline is 3. The tool description adds no parameter meaning; the parameters (chain, limit, timeperiod) seem disconnected from judging and are not explained in the description, so the tool description neither harms nor helps beyond the schema.

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

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

The description uses the specific verb 'Score' and identifies the resource as 'MindYield contest submission' with three judging criteria (quality, originality, contest-relevance). It also lists specific contest types (AI_JUDGED meme, RATE, RANK, PAIRWISE) and the no-loss platform, making it distinct from sibling tools like mindyield_leaderboard or integrity_deep_scan.

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 'Designed for AI_JUDGED meme, RATE, RANK, and PAIRWISE contests' clearly indicates when this tool is appropriate. It doesn't explicitly state when not to use it or name alternatives, but the contest-type specificity gives adequate usage 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?

No annotations are provided, so the description carries the transparency burden. It discloses the methodology and output but does not state whether the tool is read-only, requires any special credentials, or has side effects. The mention of returning a recommendation (rather than executing it) is a useful implicit disclosure, but more safety/behavioral detail is needed.

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?

At three sentences, the description is compact and front-loaded with the title and scope. Each sentence adds specific information (inputs, analysis methods, outputs), with no filler or redundant restatement.

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 covers the tool's purpose, method, and high-level return values, which is useful for a scan-like tool. However, with no output schema and no annotations, it leaves out the exact structure of the integrity score/recommendation, and the required tokenAddress is unexplained, so an agent may not know how to invoke 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 schema provides descriptions for chain, limit, and timeperiod, but the required tokenAddress parameter is missing from the properties block and the description never mentions it. The description adds no semantic value for the parameters beyond what the schema already gives, and the ambiguity around the required token address is a significant 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 clearly identifies the tool as an off-chain integrity layer for MindYield contests, specifying what it analyzes (LLM content, whale/sybil signals), what it flags (AI submissions, sybil clusters, vote-buying), and what it returns (integrity score, finalize/delay/cancel recommendation). This distinguishes it from sibling tools like mindyield_content_judge or mindyield_leaderboard.

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 context that this tool is for contest integrity assessment and augments the on-chain fraud engine, implying use when deeper off-chain analysis is needed before finalizing a contest. It does not explicitly name alternatives or when-not cases, so it falls short of the top score.

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 transparency burden. It discloses 'Read-only' and 'Free', which are useful behavioral traits. However, it does not mention potential limitations such as data freshness, rate limits, or whether the stats are aggregated across chains or per chain, leaving gaps beyond the schema.

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 two short sentences, front-loaded with the goal and key metrics. It contains no fluff or redundant information, making it highly concise and well-structured.

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 a simple read-only stats endpoint with three optional params and no output schema. The description adequately lists the return data (TVL, total yield, active product counts) and notes it's free. It could be more complete by briefly explaining how the params affect results, but it covers the core purpose well.

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 baseline is 3. The description does not add any extra meaning to the parameters themselves; it only lists the output metrics. The params (chain, limit, timeperiod) are fully described in the schema, so no additional clarity is needed.

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

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

The description clearly states the tool provides 'Read-only platform stats from MindYield: TVL, total yield distributed, active product counts.' This specific verb and resource distinguish it from sibling tools like mindyield_vaults_list or mindyield_yield_vault_deposit, which focus on vault-specific actions.

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 getting overall platform stats, but it does not explicitly state when to use this tool versus alternatives like mindyield_vaults_list. No exclusions or alternative guidance are provided, so the usage context is implied rather than explicit.

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 burden of behavioral disclosure. It goes beyond the schema by explaining the no-loss nature (principal always returned) and clarifying that only active markets are listed while deprecated ones are excluded. This gives the agent useful behavioral expectations.

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 about 50 words, front-loaded with the main action, and each sentence adds value: purpose, return data, product safety, and exclusions. No wasted words.

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 list tool with three optional parameters and no output schema, the description is complete. It lists the exact return fields (TVL, ratio, time-to-resolution, conditionId) and provides product context that helps the agent understand the domain and the tool's scope.

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

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

The input schema already describes all three parameters with 100% coverage. The description adds no additional parameter-specific details, so the baseline of 3 applies.

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

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

The description opens with 'List active MindYield yield prediction markets (ProbabilityVaultV2)', which is a specific verb+resource pairing. It also differentiates from siblings by noting that Mirror Contests are deprecated and not listed, making the tool's scope unambiguous.

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

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

The description provides clear context on what is listed (active yield prediction markets) and explicitly excludes deprecated Mirror Contests, which serves as a when-not guidance. However, it does not explicitly name alternative tools for other needs, so it falls short of full alternative comparison.

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 that the tool creates an unsigned transaction plan (not broadcasting), the vault's auto-rebalancing strategy, the 2% fee on yield only, and that the caller must sign and broadcast. These are important behavioral traits beyond basic functionality.

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 four short sentences with no fluff. Each sentence adds essential info: purpose, vault type, fees, and user action. The purpose is front-loaded, making it easy to scan. No unnecessary details are included.

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 covers the key context: what the tool does, the vault's mechanics, fees, and the need for user broadcast. However, it lacks any explanation of the input parameters (which seem unrelated) and does not describe the output format of the unsigned tx plan. Given no output schema, a bit more detail on return value or parameter usage would improve completeness.

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 description does not mention any of the schema parameters (chain, limit, timeperiod), which appear generic and unrelated to the deposit action. The schema coverage is 100%, but the parameters seem mismatched to the tool's purpose, so the description fails to provide meaningful parameter semantics and may even mislead about how to use the tool.

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

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

The description clearly states the tool's purpose: 'Build an unsigned tx plan to deposit USDC into MindYield AutoYieldVault on Base.' This specific verb+resource combination distinguishes it from sibling tools like yield_rebalance or generic yield_deposit. The ERC4626 and auto-rebalancing details further clarify the unique function.

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 context by specifying the target vault and network, and it notes the caller signs and broadcasts, indicating the tool only builds the plan. However, it does not explicitly mention alternatives or exclusions, such as 'use this instead of yield_deposit for MindYield vaults,' so it lacks explicit when/when-not 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 a heavy burden and mostly delivers: it discloses the search algorithms, validation thresholds, return metrics (OOS Sortino, stability score, worst-fold drawdown), and a trustworthiness claim. However, it omits failure behavior (what happens if validation gates are not met) and prerequisites like adapter registration, leaving minor transparency 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?

The description is four sentences, front-loaded with the core purpose and detailed with validation criteria. It is dense but not bloated; the final 'Trustworthy enough...' sentence adds context but is slightly promotional. Overall well-structured and appropriately sized for the tool's complexity.

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 complex, with no annotations and no output schema, so the description must fully specify behavior. It does explain return values and validation, but critically fails to align with the input schema, omitting the actual parameters. This mismatch renders the description incomplete and unusable for 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?

The description says 'Caller supplies adapter id + parameter search space + symbol/timeframe,' but the input schema only contains chain, limit, and timeperiod. None of the described parameters exist in the schema, and the actual schema parameters are unexplained. This is a severe contradiction that would cause incorrect invocation.

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

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

The description clearly states the tool's purpose: 'Run grid + random + Bayesian-lite parameter search on any registered strategy adapter' with walk-forward cross-validation. It specifies the resource (strategy adapter), the action (optimize parameters), and the key benefit (avoid overfitting), distinguishing it from sibling backtesting tools.

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

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

The description provides clear context for when to use this tool: when you need robust, non-overfit parameters with validation gates (≥0.7 stability, ≥0.8 OOS Sortino). It does not explicitly name alternatives or exclusions, but the walk-forward validation framing implies use over plain backtesting when parameter tuning is the goal.

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. The verbs (analyze, compare, find, view) indicate a read-only analysis tool, which is useful, but it does not disclose limitations, data sources, or whether any actions are taken on-chain. This is adequate but not rich.

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

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

The description is a single sentence that is front-loaded with the purpose and enumerates the key actions. It is reasonably efficient, though the phrase 'Pendle Yield Tokenization Analysis' is somewhat redundant with the rest of the sentence. Overall, it 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?

Given the lack of an output schema, the description does not clarify what the response format will be or what happens when no parameters are provided (all are optional). It covers the core analysis capabilities but leaves gaps about default behavior and output presentation, making it adequate but not complete.

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

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

The schema covers 100% of parameters with descriptions for chain, limit, and timeperiod. The tool description does not add any additional parameter meaning, so the baseline score of 3 is appropriate.

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

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

The description clearly identifies the tool as analyzing Pendle yield markets, comparing fixed vs variable yields, finding PT/YT opportunities across chains, and viewing yield term structures. This is a specific verb+resource+scope that distinguishes it from generic yield tools like defi_yield_analysis.

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 Pendle-specific yield analysis, but it does not explicitly state when to use this tool versus alternatives like yield_discover or defi_yield_analysis. No exclusions or alternative mentions are provided, so guidance is implied rather than explicit.

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 full burden. It discloses the core behavior (finding discrepancies) and mentions confidence scoring, but does not explicitly state that it is read-only, how data is sourced, or any latency/coverage limitations. This leaves some ambiguity about side effects.

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

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

The description is a single, well-structured sentence with a colon prefix that front-loads the tool's purpose. Every word contributes to clarity, with no redundant phrases 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?

The description explains the core functionality but does not mention what the returned data looks like (e.g., a list of opportunities with confidence scores) since there is no output schema. Given the existence of similar sibling tools, more detail on data coverage or use-case fit would improve completeness.

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 all three parameters clearly described in the input schema (chain, limit, timeperiod). The description adds no extra meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

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

The description clearly states a specific action ('Find price discrepancies') and resource ('between Polymarket and Kalshi prediction markets'). It also adds differentiators like 'Cross-Platform' and 'confidence scoring', distinguishing it from sibling tools such as polymarket_spread_analysis (likely single-platform) and arbitrage_scanner (generic).

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 context: it is for arbitrage opportunities between Polymarket and Kalshi. However, it does not explicitly state when not to use it or name alternative tools, so it lacks 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 present, so the description carries the full burden of behavioral disclosure. It states what analysis it performs but does not disclose read-only nature, output format, limitations, or any side effects. This is a significant gap for an analysis tool with zero annotation coverage.

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

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

The description is a single sentence plus a label, with no fluff. It front-loads the tool name and immediately states the purpose and methods, making it efficient.

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 is the only source for expectations. It fails to describe what the scanner returns (e.g., list of opportunities, scores), and it lacks usage guidance to differentiate it from sibling scanners, making the context incomplete.

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?

All three parameters have descriptions in the schema, so the baseline is 3. The description adds no additional meaning about how chain, limit, or timeperiod affect the scanning, nor does it clarify the enum values beyond the schema.

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

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

The description uses a specific verb ('Identify') and resource ('Polymarket high-conviction betting opportunities'), and it names three signal types (model-price divergence, cross-platform comparisons, order flow). However, it does not explicitly distinguish this tool from closely related siblings like polymarket_arbitrage or polymarket_spread_analysis.

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 a use case (scanning for high-conviction bets) but provides no explicit cues on when to prefer it over the many Polymarket siblings, nor any exclusions. It lacks any mention of alternatives or when-not-to-use, which is especially relevant given the dense sibling list.

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 must carry the full burden of behavioral disclosure. It mentions using 18 detection heuristics (wallet clustering, Sybil detection, whale transfers), which gives useful insight into its methodology. However, it does not state whether the tool is read-only, what it returns, or any limitations, so transparency is partial.

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

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

The description is a single, well-structured sentence that front-loads the tool's purpose ('Polymarket Insider Detection') and immediately explains its function. It avoids verbose filler and every clause adds value.

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

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

The tool has moderate complexity (3+ parameters, no output schema). The description accurately communicates the tool's purpose but lacks details about expected output, how to interpret results, or specific input requirements. Since there is no output schema, the description should have at least hinted at return values or usage context, but it does not fully cover these aspects.

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 reported as 100%, so the baseline for parameter semantics is 3. The description adds no parameter-specific meaning beyond what the schema already provides, although the schema itself has a notable inconsistency (tokenAddress is required but missing from properties). The description could clarify what input is expected (e.g., token address) but does not.

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

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

The description clearly states the tool's function: 'Scan Polymarket for insider trading signals' using specific heuristics. This specific verb-resource combination distinguishes it from sibling tools like polymarket_markets or polymarket_arbitrage, which focus on market data or price discrepancies.

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 context that this tool is for insider detection on Polymarket, implying it should be used when investigating suspicious trading behavior. However, it does not explicitly mention alternatives or exclusion criteria, so it earns a 4 rather than 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 disclosure burden. It explains the analytical approach and says it returns 'calibration-adjusted edge estimates,' but does not explicitly state that it is read-only/signal-only, whether it places trades, or any caveats. It adds conceptual context but lacks operational 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?

Two sentences, front-loaded with the tool name and thesis, no wasted words. The first sentence defines the strategy and the second explains the output type.

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 conceptually complex, has no output schema, and zero annotations, yet the description only gives a high-level thesis and vaguely mentions 'calibration-adjusted edge estimates across categories.' It omits output shape, how to interpret results, or guidance on parameter choices (e.g., what categories exist), making it only minimally adequate.

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 all three parameters (chain, limit, timeperiod) described. The description adds no parameter-specific meaning beyond the schema, 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 description has a specific verb ('Scan') and resource ('Polymarket') plus a clear strategy: finding NO-position opportunities where dramatic events are statistically overpriced due to availability bias and the longshot effect. This distinctly separates it from sibling Polymarket tools like arbitrage, conviction, or spread analysis.

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 clearly implies a use case (identifying overpriced dramatic-event longshots) but does not explicitly state when to choose this tool over other Polymarket tools, nor offer exclusions or prerequisites. It gives context but no when-to-use/when-not-to-use guidance.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'AI-powered semantic search' and 'order book data, and analytics,' but the input schema has no search query parameter—the only parameters are chain, limit, and timeperiod. This is misleading. It also doesn't disclose return format, pagination, or default behavior when no parameters are supplied.

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

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

The description is a single sentence, front-loaded with 'Polymarket Market Discovery.' It is concise with no filler. The colon after the title-like prefix is slightly redundant, but the rest is compact. It earns a high score for brevity, though it sacrifices important details.

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, no annotations, and three optional parameters, the description must do more to explain what the agent will receive and when to use it. It doesn't describe return values, sorting, or the nature of the 'analytics.' The complexity is low (only three optional params), but the description is still incomplete for a tool that claims to be a discovery engine.

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 baseline is 3. The description adds no parameter-specific meaning beyond the schema; it does not explain how 'chain', 'limit', or 'timeperiod' affect the search or what the 'AI-powered semantic search' actually queries. However, since the schema already documents each parameter clearly, the description doesn't need to add much. Score at 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?

The description clearly states the tool's function: 'Search and discover active prediction markets on Polymarket' with features like 'AI-powered semantic search, order book data, and analytics.' This is a specific verb+resource pairing. It only partially distinguishes from sibling tools (e.g., polymarket_arbitrage, polymarket_spread_analysis) because it doesn't explicitly say 'for general discovery use this; for specialized analysis use those.'

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

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

No guidance is given on when to use this tool versus the many sibling Polymarket tools. It doesn't provide context like 'use this to explore markets' or 'for arbitrage, use polymarket_arbitrage instead.' The description is purely functional, with no situational or alternative recommendations.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context by mentioning 'real CLOB order book data,' implying live market data, and 'Analyze' suggests a read-only operation. However, it does not explicitly state whether the tool is read-only, has any side effects, requires authentication, or how the data is collected. There is no contradiction, but the behavioral disclosure is 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?

The description is a single, focused sentence that front-loads the key purpose ('Analyze bid-ask spreads...') and includes a concrete example of completeness arbitrage. Every word earns its place, and the length is appropriate for the tool's complexity.

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

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

The tool has no output schema and no annotations, so the description should compensate by explaining what the result looks like. While the description covers the analysis areas, it does not mention return format, whether results are structured data or narrative, or any limitations such as market coverage or data freshness. This leaves notable gaps for an agent deciding whether the output will meet its needs.

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

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

The input schema covers 100% of parameters with descriptions for chain, limit, and timeperiod, so the baseline is 3. The description does not add extra meaning about how these parameters affect the analysis or their supported values beyond what the schema already provides. It does not map the mentioned analyses to specific parameter combinations.

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

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

The description clearly states the tool's function: analyzing bid-ask spreads, completeness arbitrage (YES+NO < $1), and market making opportunities using real CLOB order book data. It uses a specific verb ('Analyze') and resource ('Polymarket') and distinguishes itself from sibling tools like polymarket_markets and polymarket_arbitrage by focusing on spread and market-making analytics.

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 the tool should be used for spread and market-making analysis on Polymarket, but it does not explicitly state when to use it over alternatives or provide exclusion criteria. It lacks direct references to sibling tools or scenarios where other tools would be more appropriate, so the guidance 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 are provided, so the description carries the full burden. It transparently lists output components (base category cap, Kelly multiplier, correlation penalty, drawdown dampener, rationale) and the portfolio-wide drawdown circuit-breaker state. However, it does not explicitly state read-only behavior, though 'query' implies it.

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?

Composed of five sentences, each contributing to understanding the tool's purpose and output. Some minor redundancy (e.g., 'Portfolio Risk Allocation Matrix' vs 'recommended allocation fractions') but the text is front-loaded and efficient. 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 the lack of an output schema, the description compensates by listing all key verdict components and the circuit-breaker state. It also provides usage timing. It does not clarify parameter-output interactions, but the description is sufficiently complete for a downstream agent to select and invoke the tool correctly.

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

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

The input schema already has 100% parameter description coverage (chain, limit, timeperiod). The description does not explain how these parameters affect the allocation results, so it adds no semantic value beyond what the schema provides. 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?

Clearly identifies a specific resource: Einstein's risk allocator, and the verb 'query'. Differentiates itself from sibling tools like strategy_allocation_recommendation by explicitly stating it is the same allocator Einstein's own executors use. The description details the exact output, leaving no ambiguity about the tool's function.

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

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

Explicitly states when to use: 'before sizing a trade'. Adds context that this is the same allocator used by Einstein's executors, reinforcing its authoritative role. Does not explicitly exclude alternatives, but the use case is well-defined.

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 discloses behavioral details such as ranking by 'risk × balance', step-by-step instructions, destination recommendations, and gas cost estimates. However, it does not clarify whether the tool is read-only or how it selects wallet addresses, leaving ambiguity.

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 two sentences and about 36 words, front-loaded with the tool's purpose and immediate details. Every sentence earns its place with no 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?

The description covers the output (ranking, instructions, recommendations, gas costs) but omits how wallet addresses are specified—the schema has no wallet address parameter, creating uncertainty about invocation. With no output schema, the description is the only guide to return values, yet it leaves this gap.

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

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

Schema description coverage is 100%, with all three parameters (chain, limit, timeperiod) already documented. The description adds no extra meaning to these parameters; it does not explain how they influence the migration plan.

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 'Generate' and a clear resource 'prioritized post-quantum migration plan for wallet addresses'. It distinguishes itself from sibling tools like pqc_wallet_scan or pqc_readiness_assessment by emphasizing ranking, instructions, and gas cost estimates.

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 the tool is for generating migration plans but does not explicitly state when to use it over alternatives or provide exclusions/prerequisites. It gives clear context but lacks alternative guidance, so 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 provided, the description carries the full burden of behavioral disclosure. It describes what the report covers but does not state whether the tool is read-only, performs active scanning, requires special access, or has any side effects. For a tool named 'readiness assessment', the lack of any statement about data mutation or external network calls leaves important behavioral traits undisclosed.

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

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

The description is a single sentence that front-loads the purpose and uses a colon to enumerate the report's key components. It is compact and avoids redundancy, though the list of items is dense and could benefit from clearer segmentation. It earns a 4 for efficiency without being a tautology or overly verbose.

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 moderately complex, covering multiple analysis areas, and there is no output schema. The description explains the report's high-level content but does not describe the return format, report structure, or how the optional portfolio exposure analysis is triggered. It lacks details on how parameters like limit affect the report or whether the output is time-series data. Given the lack of an output schema, the description should compensate with more behavioral and output details, but it only partially does, warranting a 3.

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%, as all three parameters (chain, limit, timeperiod) have descriptions in the schema. The description adds context by relating 'chain PQC status' to the chain parameter and 'quantum threat timeline' to timeperiod, but it does not explain parameter syntax, ranges, or how they precisely affect the output. The description mentions 'optional portfolio exposure analysis' with no corresponding parameter, slightly muddying the mapping. Since schema already documents the parameters, a 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 clearly states the tool produces a 'Comprehensive ecosystem-wide quantum readiness report' with specific content coverage (chain PQC status, NIST algorithm comparison, quantum threat timeline, portfolio exposure analysis). This distinguishes it from sibling tools like pqc_wallet_scan (wallet-specific) and pqc_migration_planner (migration planning), making the purpose unambiguous.

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

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

The description implies the tool is for ecosystem-wide quantum readiness assessment, but it does not explicitly state when to use it versus alternatives or provide exclusions. It neither names sibling tools nor says 'use this when you need X', leaving usage context inferred from the scope. This meets the 'implied usage' level, not the explicit guidance of a 4.

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 disclose behavioral traits itself. It does indicate the tool performs analysis (non-destructive) and mentions detection and advisory outputs, but it fails to mention required permissions, data handling, or the notable mismatch between the described wallet address and the schema's tokenAddress parameter. The description reveals the 'what' but not the 'how' or side effects.

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

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

The description is a single, front-loaded sentence that flows from the tool's purpose to specific capabilities. Every phrase adds meaning, but 'Deep analysis' is filler and the sentence is dense with jargon. It earns high marks for being concise, but not flawless.

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

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

For a tool with no annotations and no output schema, the description should explain inputs, expected outputs, and edge cases. It covers the functional scope but leaves out return format, input format (especially the tokenAddress vs wallet discrepancy), and any limitations. The mismatch between the description's wallet focus and the schema's token-centric parameters makes the description incomplete for 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?

The schema descriptions cover chain, limit, and timeperiod, but the required tokenAddress is absent from the schema properties, and the description refers to 'wallet address' while the schema implies token address—an unresolved mismatch. The description adds no clarity about what tokenAddress means or how it relates to the described Bitcoin/Ethereum wallet focus. Schema coverage is misleading because the one required parameter is undocumented.

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

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

The description clearly states the tool's function: 'Deep analysis of any Bitcoin or Ethereum wallet address for quantum resistance' and enumerates concrete capabilities like detecting address types and assessing algorithm vulnerabilities. It distinguishes itself from siblings like pqc_migration_planner by focusing on address-level scanning. However, 'Deep analysis' is somewhat vague as a verb, and the description does not explicitly contrast with similar quantum tools.

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

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

The description provides no guidance on when to use this tool versus alternatives, mentions no exclusions, and does not reference sibling tools such as security_scan or pqc_readiness_assessment. It lacks any 'use this when' or 'instead of' hints, leaving the agent without selection 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 burden of behavioral disclosure. It mentions 'fresh token launches' and 'bonding curve progress' but does not explain how the chain parameter interacts with the 'Solana only' claim, nor does it specify the meaning of 'fresh' or the return format. This leaves the agent uncertain about core 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 a single, front-loaded sentence with no wasted words. It efficiently communicates the resource (Pump.fun launches), the key detail (bonding curve progress), and the scope (Solana only).

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 should provide a fuller picture of the return shape and parameter effects. It only hints at the data content and fails to explain how 'limit' and 'timeperiod' shape results, leaving the agent to guess. The chain contradiction is another gap in completeness.

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 schema descriptions cover all three parameters, but the tool description's 'Solana only' conflicts with the chain enum that includes multiple networks. This contradiction undermines the meaning of the chain parameter, and the description adds no beneficial parameter context 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 clearly identifies the tool as returning fresh token launches on Pump.fun with bonding curve progress, and explicitly scopes it to Solana. This distinguishes it from sibling tools like zora_launches. However, it lacks an explicit verb like 'list' or 'get,' which slightly reduces clarity.

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 no explicit guidance on when to use this tool versus alternatives. The statement 'Solana only' suggests a constraint, but it directly contradicts the schema's chain parameter which accepts six non-Solana networks, making the intended usage confusing and potentially misleading.

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. It discloses the entropy source (ANU) and return formats, which is useful. However, it omits behavioral traits like whether it is safe/read-only, any rate limits or external API dependencies, and does not address the unrelated parameters in the schema. The description adds some value but lacks depth.

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 concise, front-loaded with the core function, and contains no filler. Every word contributes to understanding the tool's purpose and output.

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

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

Despite the simple premise, the description is incomplete because it fails to connect the stated function (key generation) with the actual input schema (blockchain chain, limit, timeperiod). Without output schema or annotation support, an agent cannot determine how to provide required parameters or what to expect beyond the formats. This is a severe gap.

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

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

Although schema coverage is 100%, the description adds no meaning to the parameters. More critically, the parameters (chain, limit, timeperiod) describe blockchain queries that are completely unrelated to generating encryption keys, creating a substantial mismatch that would confuse an agent trying to invoke the tool correctly.

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

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

The description states a specific action ('Generate AES-256 encryption keys'), names the resource/source ('real ANU quantum entropy'), and specifies output formats (hex and base64). This clearly distinguishes it from sibling tools like quantum_signing_key (signing keys) and quantum_hardware_qrng (raw quantum randomness).

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

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

No guidance is provided on when to use this tool versus alternatives such as quantum_signing_key or quantum_wallet_generation. There is no mention of use cases, prerequisites, or exclusions, leaving the agent to infer the intended scenario.

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?

Without annotations, the description carries the burden of behavioral disclosure. It does reveal that each result includes an IBM job ID as proof of quantum origin, which is useful. However, it omits important behaviors like how many numbers are generated, whether results are cached, latency, or any cost implications. The mismatch between the description and the schema parameters (e.g., 'chain' suggests network selection) is a transparency concern.

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 two sentences, each earns its place: the first states the core function and hardware, the second mentions the proof-of-origin feature. It is front-loaded with the action 'Generate' and avoids fluff. A 5 is appropriate.

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

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

Given the tool has no output schema and zero annotations, the description should fully explain usage and return behavior. It only mentions one aspect (job ID), leaving unexplained how parameters like `chain` and `timeperiod` are used, what the output format is, and how many random numbers are returned per call. The disconnect between description and schema makes it incomplete for unfamiliar agents.

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 descriptions cover 100% of parameters, but they describe a blockchain query tool ('Blockchain network to query', 'Time period for analysis'), which conflicts with the stated QRNG purpose. The description adds no additional semantic meaning for how `chain`, `limit`, or `timeperiod` relate to random number generation. This is confusing and degrades the parameter semantics below the 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?

The description clearly states a specific verb ('Generate') and resource ('real IBM quantum hardware'), distinguishing it from sibling quantum tools like quantum_signing_key. However, the input schema parameters (chain, limit, timeperiod) suggest a blockchain query tool, creating ambiguity about the true purpose. The description itself is clear, but the mismatch with the schema prevents 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?

No guidance is provided on when to use this tool versus alternatives. There is no mention of contexts, prerequisites, or when not to use it. The sibling list contains several quantum-related tools, and the description doesn't explain how this QRNG differs from quantum_encryption_key or quantum_signing_key in terms of use 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 provided, the description carries the full burden of disclosing behavior. It mentions high-level actions (aggregates risk scores, identifies value at risk) but fails to explain critical details such as how wallet addresses are supplied, whether the operation is read-only, what the output format looks like, or any side effects. The lack of clarity is a significant gap for an analysis 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 concise, using three sentences to convey the core function and value. The first sentence is front-loaded with the main verb and resource ('Scan multiple wallet addresses across chains for quantum vulnerability'), followed by supporting details. It is not overly verbose, though the second sentence lists capabilities rather efficiently.

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

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

The tool has no output schema and no annotations, yet the description leaves a critical contextual gap: it does not explain how the tool determines which wallet addresses to scan, since the input schema lacks a wallet address parameter. Additionally, there is no mention of return values, risk score ranges, or how the tool integrates with other portfolio tools. Given the complexity, the description is incomplete.

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 baseline is 3. The description adds no additional meaning about the 'chain', 'limit', or 'timeperiod' parameters beyond what the schema already provides. It neither enhances nor contradicts the parameter descriptions, so a score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: scanning multiple wallet addresses across chains for quantum vulnerability and providing portfolio-level risk assessment. It distinguishes itself from siblings like pqc_wallet_scan by emphasizing 'multiple wallet addresses' and 'portfolio-level' aggregation, making it specific and differentiated.

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 context is implied: it's for monitoring quantum risk across a portfolio of wallets. However, no explicit guidance is given on when to use this vs. alternatives like pqc_wallet_scan or pqc_readiness_assessment. There are no exclusions or comparative statements, so the guidance remains at the level of implied 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?

No annotations are present, so the description carries the full burden. It discloses the entropy source and output pair, but does not explain security implications, whether the private key is returned in plaintext, or any rate-limit/API constraints. The parameter descriptions imply a query behavior that conflicts with key generation, further decreasing transparency.

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

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

The description is two sentences, front-loaded with the tool's purpose, and every phrase adds information. There is no filler 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?

The output schema is absent, but the description at least states the return pair. However, the lack of guidance on algorithm selection and parameter usage, combined with the stark mismatch between the description and the input schema, makes it incomplete for 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?

The input schema has full descriptions, but they refer to 'Blockchain network to query', 'Maximum number of results', and 'Time period for analysis'—none of which align with generating a signing keypair. The description adds no parameter guidance, leaving the agent confused about how chain, limit, and timeperiod affect key generation.

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 'Generate' and names exact algorithms (Ed25519/secp256k1) plus a distinctive entropy source (ANU quantum entropy), which clearly identifies the tool's purpose and distinguishes it from generic key/wallet tools. However, it does not explicitly differentiate from sibling tools like quantum_wallet_generation or quantum_encryption_key beyond the signing focus.

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

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

No guidance is provided on when to use this tool versus alternatives. The description does not mention any prerequisites, exclusions, or context in which this tool should be preferred over similar quantum/wallet tools.

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 of behavioral disclosure. It adds valuable context about the entropy source ('real ANU quantum entropy (vacuum fluctuation measurements)') and output format. However, it omits critical security implications for wallet generation, such as whether private keys are returned, if they are stored, or how to handle them safely. This partial disclosure is not sufficient for a sensitive operation.

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 concise and front-loaded with a clear verb+resource structure. The two sentences efficiently convey the tool's purpose and output details without waste. Each word 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?

The description is incomplete for a tool with this complexity. It fails to reconcile the disconnected schema parameters, lacks guidance on word length selection, and omits critical security/usage context. Given no output schema, the agent cannot reliably invoke the tool correctly.

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

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

The schema descriptions are generic ('Blockchain network to query', 'Maximum number of results', 'Time period for analysis') and unrelated to wallet generation, despite 100% coverage. The description does not clarify these parameters, nor does it explain how to select 12 vs 24 words (no such parameter exists). Additionally, the description claims Bitcoin support, but the enum lacks 'bitcoin'. This mismatch leaves the agent without meaningful parameter understanding.

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

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

The description clearly states the tool's core function: 'Generate BIP-39 mnemonic seed phrases from real ANU quantum entropy'. It specifies the output (12/24-word mnemonics, derived addresses for EVM, Solana, Bitcoin), and distinguishes itself from sibling tools like quantum_signing_key or quantum_encryption_key by emphasizing wallet generation and the quantum entropy source.

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

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

No guidance is given about when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or scenarios where another tool (e.g., quantum_signing_key) would be more appropriate. The description simply states the function without contextualizing its use case relative to siblings.

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

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

With no annotations, the description carries the full burden. It does disclose the model's multi-factor, macro-aware nature and lists the exact feature vector components (e.g., 200-SMA trend, realized volatility percentile), which goes beyond a simple output statement. However, it doesn't mention any behavioral traits like data freshness, latency, or limitations, so it's not exceptionally transparent.

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 two sentences with no wasted words. It front-loads the primary output and then provides context and use case. The first sentence is a bit dense due to the long feature list, but every phrase earns its place. It's well-structured for an API description.

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 thoroughly explains the output format (regime label + feature vector) and enumerates the features, which is valuable given the absence of an output schema. However, it doesn't address the parameters at all, and the parameter schema seems mismatched with the BTC focus. This gap means the tool is not fully self-contained for an agent deciding to call 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?

Although the schema covers 100% of parameters, the description completely ignores them, and there's a notable mismatch: the tool is BTC-specific, but the 'chain' parameter includes ethereum, bsc, etc., which is confusing. Since the baseline is 3 due to schema coverage, the description fails to add any clarifying context about how these parameters affect the BTC regime output, and the mismatch actively hurts semantics.

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 'BTC Multi-Factor Regime Classification' and clearly states it 'Returns the multi-factor BTC regime label (bull/bear/ranging/volatile) plus the continuous feature vector that produced it,' naming the exact output and the specific features involved. This distinguishes it from broad analysis tools like technical_analysis or market_movers by being highly specific to regime detection with a defined feature set.

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 a clear use case: 'Ideal for any agent that needs to bias trading decisions by regime.' It also positions itself against older models with 'Replaces 1D funding-only regime models,' implying superiority but without naming specific alternative tools or explicit when-not-to-use conditions. This is clear context but lacks explicit 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 discloses 'Read-only', explains the 24/5 Chainlink feed staleness for equities, and mentions liquidity filtering—valuable behavioral context. It does not mention rate limits, pagination, or error handling, but the disclosed safety profile and data quirks are commendable.

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

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

The description is a single dense paragraph that front-loads the purpose and packs in specific details (ranking metrics, chain ID, reference price behavior). It is longer than ideal, but every sentence contributes unique information, making it efficient and structured.

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

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

The tool has notable complexity (asset classes, sort types, reference price semantics) and no output schema. While the description covers output content (live USD prices, holder counts, liquidity), the param mismatch leaves the agent unable to correctly invoke it: it doesn't mention chain or timeperiod, and suggests nonexistent params. This incomplete and partially inaccurate guidance severely undermines usability.

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 description's 'Params: kind=all|crypto|stock, sort=volume|mcap|liquidity|gainers|losers|premium, limit' directly contradicts the input schema, which defines chain, limit, and timeperiod. The description omits the actual parameters (chain, timeperiod) and invents nonexistent ones (kind, sort). This is misleading and fails to add value to the well-documented schema.

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

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

The description starts with 'Asset leaderboard for Robinhood Chain (EVM 4663)' and specifies exactly what it lists ('every listed token and Robinhood-issued tokenized equity') and the ranking criteria ('24h DEX volume, market cap, liquidity, 24h price change, premium'). This clearly distinguishes it from sibling market tools by chain and scope.

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 establishes a clear context for when to use this tool (Robinhood Chain market data, with stock vs crypto kind, various sort options) and labels it 'Read-only'. However, it does not explicitly name alternatives or exclusion criteria (e.g., 'use top_gainers for broader market'), leaving the comparison to siblings implicit.

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. However, it only lists content categories and does not disclose behavioral traits such as whether the tool performs read-only operations, potential side effects, rate limits, or what the response format is. The word 'Analytics' implies read-only but is not explicit.

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 concise, consisting of two sentences that list the key coverage areas without unnecessary fluff. It is front-loaded with the resource name and immediately specifies the data types included. A slightly stronger verb could improve structure, but it is appropriately sized.

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 provides a reasonable overview of what data the tool covers, but lacks context on how parameters influence results, the output structure, or any limitations. It is adequate for a simple query tool but leaves room for more completeness.

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% for all three parameters (chain, limit, timeperiod). The description does not add any parameter-specific meaning, but the rule establishes a baseline of 3 when schema coverage is high, so this is adequate.

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

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

The description clearly identifies the resource as 'Runes Protocol Analytics' and enumerates the specific data areas covered (overview, mint progress, holder distribution, individual rune details, mintable status, etching data). It implicitly distinguishes itself from sibling tools like brc20_analytics by focusing on the Runes protocol, though it lacks an explicit verb like 'retrieve' or 'analyze'.

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 no guidance on when to use this tool versus alternatives. It does not mention any specific use cases, prerequisites, or exclusions. Given the large set of sibling analytics tools, this is a notable 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?

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It mentions 'rug pull detection' and 'risk scoring' but does not state whether the tool is read-only, what data it accesses, what the output includes, or any potential side effects. This lacks critical behavioral transparency for an agent.

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

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

The description is a single efficient line with no wasted words, front-loading the purpose effectively. It sacrifices depth for brevity but remains appropriately sized for a high-level overview.

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 should explain what the tool returns and how to interpret results. It only provides a high-level summary, omitting details like output format, caveats, and relationship to other security tools, making it incomplete for a potentially complex security analysis 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 descriptions cover 100% of parameters (tokenAddress, chain, limit, timeperiod), including required flags and enum values. The description adds no extra parameter semantics beyond the schema, so the baseline score of 3 applies; it neither repeats nor clarifies further.

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

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

The description clearly states it is a 'Token Security Scanner' with 'Rug pull detection and security analysis with risk scoring', identifying a specific verb (scan/detect) and resource (tokens). It differentiates itself from siblings like approval_security_scan and smart_contract_audit by focusing on rug pulls and risk scoring, though it does not explicitly name these 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?

No guidance is given on when to use this tool versus alternatives. Siblings include approval_security_scan and smart_contract_audit, but the description does not mention them or provide exclusion criteria. Usage context is only implied by the name and brief description.

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 must carry the full burden of disclosing behavioral traits. It mentions 'AI-powered reports and remediation suggestions' but does not explain whether the tool is read-only, what side effects exist, or how the parameters (chain, limit, timeperiod) affect the scan. This is minimal disclosure for a security 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 one sentence and reasonably concise. However, it starts with 'Smart Contract Security Audit:' which redundantly repeats the tool name, and 'Comprehensive smart contract vulnerability scanning' is slightly verbose. Still, it is front-loaded and not overly long.

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 lacks an output schema and annotations, leaving the description to explain context. It fails to specify what input the audit requires (e.g., contract address) or what the output report contains. The parameters (chain, limit, timeperiod) suggest a queryable audit, but their role is unexplained. The description is too brief to fully prepare an agent.

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 baseline is 3. The description itself adds no parameter-specific meaning; it doesn't mention chain, limit, or timeperiod. The schema's descriptions are adequate but generic ('Blockchain network to query', 'Maximum number of results'). There is no additional value from the description.

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

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

The description clearly states the tool performs 'comprehensive smart contract vulnerability scanning across 30+ patterns' and produces 'AI-powered reports and remediation suggestions.' This gives a specific verb (scanning) and resource (smart contracts), though it doesn't explicitly distinguish from sibling tools like 'security_scan' or 'approval_security_scan.'

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 guidance on when to use this tool versus alternatives, no prerequisites, and no mention of what inputs are expected (e.g., contract address). The description is purely a feature list without usage 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, the description carries the burden. It does state the output fields (volume, trade count, top tokens) and the negative (not P&L), which gives some behavioral insight. However, it omits details like data source, definition of 'smart money,' or any side effects, making it a moderate disclosure.

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 two sentences, with the first front-loading the core purpose and the second clarifying return fields and exclusions. Every sentence earns its place with no 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?

The description provides a good high-level summary but lacks depth: no output structure, no definition of 'smart money,' and the walletAddress parameter's purpose is ambiguous. Given no annotations or output schema, this is not fully complete for a 4-parameter tool, but it is adequate.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds no extra meaning to the parameters, leaving ambiguities such as the role of walletAddress (optional filter vs. specific analysis) unresolved.

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

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

The description clearly states the tool ranks top DEX wallets by trading volume and net buy/sell flow, and explicitly lists what it returns and what it does not (not realized P&L or win rate). This makes the purpose specific and distinguishes it from related tools like wallet_pnl.

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 when to use the tool by focusing on smart money analysis for DEX wallets and explicitly excludes P&L/win rate, which signals a when-not. However, it does not name alternative tools or provide explicit when-to-use conditions, so it falls short of a full 5.

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