Agent Einstein — Crypto & Market Intelligence

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

The annotations already declare read-only, idempotent, and non-destructive behavior, so the description is not required to restate them. It adds genuine behavioral context not in the annotations: the $0.25–$0.85 per-call cost drawn from Einstein credit balance and the existence of free alternatives. It could have added pagination or response-shape notes, but the output schema handles much of that.

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

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

Two compact sentences: the first front-loads the full capability list, and the second delivers the cost and free-alternative caveat. No filler or duplicated schema text. The most decision-relevant information (scope, price, alternative) appears early.

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 an output schema, optional parameters, and non-destructive annotations, the description covers the remaining essential context: cost, credit source, and where to find free alternatives. It does not explicitly tie each domain to a 'kind' value, but the enum and its descriptions are self-explanatory, so nothing critical is missing for selecting and invoking 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?

With 100% schema description coverage, the baseline is strong, and the description adds meaning by expanding the enum values into concrete analysis intents: 'mempool and fee intelligence,' 'bridges comparison,' and 'Babylon staking.' It does not discuss the 'limit' parameter, but the schema already documents it with default and range, so the description does not need to compensate.

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

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

The description names a specific resource ('Bitcoin-native analysis') and enumerates the supported domains: mempool/fee intelligence, network/mining health, BRC-20, Runes, bridges, and staking. This maps cleanly to the 'kind' enum and separates it from the general analyze_wallet and other analyze_* siblings. It loses one point because the description says only 'analysis' and does not state what kind of result the caller gets (e.g., metrics, rankings, comparisons).

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 paid-cost warning and pointer to list_einstein_capabilities for free alternatives is useful routing information and an implied when-not-to-use signal. However, it never explicitly tells the agent when to pick analyze_bitcoin over closely related siblings such as inspect_onchain or get_bitcoin_cycle_position, so usage guidance remains mostly 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description is not burdened with covering basic safety. It adds valuable behavioral context about paid usage and the exact price range from the user's credit balance. This cost disclosure goes beyond what annotations and the schema provide.

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

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

The description is compact, front-loaded with the tool's core function, and includes only the essential cost caveat. The sentence structure efficiently conveys both modes and the paid nature without extraneous 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?

Given the parameter schema fully documents all fields, an output schema exists, and annotations cover read-only/idempotent behavior, the description is complete enough for correct invocation. The cost and mode guidance further round out the context. A minor gap is not explicitly describing what the intel output contains, but the output schema likely covers that.

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 already documented including the enum values, default for limit, and the walletAddress requirement for 'intel'. The description adds little semantic detail beyond what the schema 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 tool as providing either a ranked leaderboard of profitable copy-trading wallets or deeper intelligence on a specific trader's edge, consistency, and risk. It is specific about the resource and output modes, and although it lacks an explicit verb, the meaning is unambiguous. The 'copy trading' focus helps distinguish it from broader whale-tracking or wallet-analysis siblings.

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

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

The description explains the two modes ('leaderboard' for general rankings, 'intel' for a specific trader) and includes a practical cost note. It directs users to list_einstein_capabilities for free alternatives, which is useful decision guidance. It does not name specific sibling tools or conditions for choosing between them, but the mode breakdown effectively tells the agent when to use each variant.

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?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds valuable beyond-annotation context: the per-call cost ($0.50–$1.50) and that it debits from an Einstein credit balance, plus the existence of free alternatives. This is meaningful behavioral transparency beyond the annotations.

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-load the core capabilities and then address cost and alternatives. No wasted words; every sentence serves a distinct 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, combined with a 100%-covered schema and a declared output schema, is nearly complete. It explains all five modes, cost, and points to free alternatives. Minor gaps remain around precise definitions of 'insider-shaped' or 'high-conviction', but these are acceptable given the 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 covers all parameter descriptions at 100%, so the baseline is 3. The description adds semantic meaning by mapping each kind enum value to a concrete action (browse markets, scan insiders, measure spreads, find conviction, fade long shots), which is genuinely useful beyond the schema's simple enum list.

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

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

The description clearly identifies the resource (Polymarket) and enumerates five distinct analysis capabilities that map to the 'kind' parameter. It is specific enough to distinguish from generic analysis tools, though it doesn't explicitly name sibling tools to differentiate itself.

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

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

The description provides clear context about when this tool is appropriate (paid Polymarket analysis) and directs users to list_einstein_capabilities for free alternatives. It lacks explicit when-not-to-use conditions, but the pointer to alternatives provides adequate guidance for an agent.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds valuable behavioral context beyond annotations by disclosing the per-call cost ($0.25 from Einstein credit balance) and flagging free alternatives—traits an agent should know before invoking.

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 packs substantial information in two main sentences plus a bracket note, with front-loaded context about the market and a sequence of concrete use cases. It is not excessively long and the paid/free note is clearly delimited. Slight wordiness in the second sentence prevents a 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?

With a strong annotation stack and 100% schema coverage, the definition only needs to supply operational and pricing context. It does that, plus the board descriptions and the pointer to free paths. The only secondary missing piece is the nuance of 'openWorldHint' and exact response structure, but an output schema exists, keeping the description 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 description coverage is 100%, with detailed board meanings already in the input schema. The tool description restates some board concepts in natural language (e.g., 'float-corner risk', 'stock-paired launches'), but it does not define token or new dimensions, so the schema continues to do the heavy lifting. Baseline 3 is appropriate.

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

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

The description clearly identifies the tool's focus: market intelligence for 'memecoins priced in SHARES' on Base and Robinhood Chain, and names the major analysis categories (float-corner risk, stock-paired launches, early-buyer traces). It distinguishes the tool from broader siblings by its niche, though it does not explicitly name alternatives.

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

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

The description implies when to use the tool through its market definition and notes that 'free alternatives exist for several of these — see list_einstein_capabilities', which points to alternative pathways. However, it stops short of explicit when/when-not guidance relative to sibling tools like analyze_token_security or analyze_wallet.

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 annotations already declare read-only, idempotent, and open-world traits. The description adds cost information ($0.35–$2.00 per call) and notes the existence of free alternatives, which are not covered by the annotations. It does not contradict the annotations.

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, with two sentences that front-load the core purpose and then provide usage and cost context. No unnecessary fluff or redundant phrasing.

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 output schema exists and the parameters are fully described, the description provides sufficient context: purpose, kind selection, and cost. It does not explain return values, but that is not required since an output schema is present. The cost and alternative note add valuable context.

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

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

Schema coverage for parameters is 100%: each parameter has a clear description and enum values for `kind` and `chain` are explained. The description only reinforces the `kind` parameter's role and does not add new semantic details beyond the schema, so it stays at 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 it performs live security analysis of a token contract, listing specific risk types (rug-pull, holder concentration, sniper activity, approvals, full audit) and instructs to choose the analysis via the `kind` parameter. This distinguishes it from sibling tools like bitcoin analysis or copy trading, 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?

It mentions that free alternatives exist for several kinds and points to list_einstein_capabilities, providing a useful comparison. However, it does not explicitly specify conditions for when to prefer this paid tool over alternatives like check_token_safety or inspect_onchain, so it falls short of fully explicit 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?

Annotations already establish readOnlyHint, idempotentHint, openWorldHint, and non-destructiveness, so the bar for additional behavioral disclosure is lower. The description adds valuable context beyond annotations: it is a paid call costing $0.25–$1.00 from the credit balance, and free alternatives exist for some analyses. This helps an agent decide whether to invoke 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, front-loaded sentence covering the core purpose and analysis modes, followed by a compact paid/alternative note. Every clause carries useful information and there is no filler or repetition of the title.

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

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

With an output schema, detailed enum descriptions, and safety annotations already present, the description does not need to restate return values or side-effect guarantees. It covers purpose, pricing, and alternative routes well. It would be more complete with explicit guidance on supported chains or overlap with sibling tools, but nothing critical is missing for invoking the tool correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds useful semantic gloss over the kind enum: 'current holdings' maps to portfolio, 'realized/unrealized P&L' maps to pnl, 'forgotten or dust assets' maps to forgotten, and 'quantum-resistance of its address type' maps to quantum. It does not add detail for chain or walletAddress, but the schema already documents those.

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 — 'Analyze any wallet address' — and enumerates six concrete analysis outputs (holdings, P&L, trust score, forgotten assets, airdrops, quantum-resistance). It is clearly scoped to wallet-level analysis, but it does not explicitly differentiate itself from siblings like assess_quantum_risk or analyze_bitcoin, so it stops short of a 5.

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

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

The main usage context is clear: use this when the agent needs any of the listed wallet analyses. The description also points to free alternatives via list_einstein_capabilities, which is a useful routing signal. However, it does not state explicit when-not-to-use conditions or name which alternatives cover which sub-analyses.

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?

Annotations already establish this as read-only, idempotent, and non-destructive. The description adds valuable behavioral detail: it costs $1.00 per call from the Einstein credit balance, returns 'a written analysis,' and grounds that analysis in 'live on-chain and market data.' This goes beyond the structured metadata without contradicting 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?

Three compact sentences, each earning its place: what it does, when to use it, and cost with an alternative pointer. The 'use this when' condition is front-loaded right after the main 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?

For a single-parameter, open-ended analysis tool, the description is complete: it covers purpose, when to use it, what the return looks like, data grounding, cost, and where to find cheaper alternatives. No critical operational detail is missing.

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

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

The input schema already fully documents the single 'prompt' parameter with a clear description. The tool description adds only that the prompt is the 'question or analysis request,' which is marginal value since the schema already says 'The question or analysis request, in plain language.'

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 verb and resource: 'Open-ended crypto and DeFi analysis from Einstein's full research stack.' It distinguishes itself from the many specialized sibling tools by saying it is for when 'no more specific tool fits' or the question 'spans several domains.'

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

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

Usage guidance is explicit: use it as the default catch-all when specialized tools don't fit or for multi-domain questions. It also flags the paid nature and points to list_einstein_capabilities for free alternatives, giving clear decision 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds important behavioral context beyond the annotations: the call is paid from Einstein credit balance, pricing ranges from $0.50-$1.00, and the assessment draws on 'current benchmarks.' This helps an agent understand practical implications of invoking 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 one dense, front-loaded sentence followed by a short billing note. Every phrase earns its place: the core purpose is stated first, the four variants are listed compactly, and the cost/alternative guidance is separated in brackets. No wasted words and no structural clutter.

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 two optional parameters, full schema description coverage, an output schema, and read-only/idempotent annotations, this description is complete. It explains what the tool assesses, names all four kinds, notes the cost, and gives an explicit pointer for free alternatives. An agent has everything needed to decide whether and how to call it correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds useful plain-language meaning to the 'kind' enum: 'organizational PQC readiness' maps to readiness, 'a migration plan' to migration, 'portfolio-level quantum risk' to portfolio, and 'how close a CRQC actually is' to crqc_benchmark. It does not explicitly discuss walletAddress, but the schema already covers that sufficiently.

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

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

The description uses a specific verb and resource — 'Assess exposure to cryptographically-relevant quantum computing' — and then enumerates the four concrete assessment types: PQC readiness, migration plan, portfolio-level risk, and CRQC benchmark. This maps cleanly to the tool's purpose and distinguishes it from every sibling tool, none of which addresses quantum risk assessment.

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 signals that this is a paid tool and directs the agent to list_einstein_capabilities for free alternatives, providing meaningful context for when not to use it. It does not give explicit when-to-use/when-not-to-use conditions beyond this, but the cost warning and pointer to alternatives are clear and actionable.

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?

Annotations already mark the tool as read-only, idempotent, and non-destructive, so the safety profile is covered. The description adds real-world cost context (Einstein credit balance, $0.05–$1.00) and a pointer to free alternatives, which is valuable beyond the schema and annotations. No contradiction with annotations.

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 tight sentences; the first front-loads the tool's function and scope, and the second adds cost/alternative context without padding. Every clause earns its place in the 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?

All required information is present or already structured: parameters are fully described in the schema, an output schema exists, annotations cover safety, and the description adds the crucial paid/cost dimension and free-alternative route. An agent has enough to invoke it and interpret results.

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

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

Schema coverage is 100% and the enum values in the schema already explain judge/deep_scan/vaults, so the description does not need to add much. The description loosely echoes the content/vault distinction but adds no new parameter-level meaning beyond the schema.

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

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

States a specific verb ('scanning/judges') and a specific resource class ('user-generated content and yield-vault listings'), and clarifies that it covers content quality plus manipulation scanning. It is clearly distinct from token-focused or market-scan siblings, though it does not explicitly differentiate itself by name.

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?

Mentions that free alternatives exist and points to list_einstein_capabilities, which gives cost-conscious agents a next step. However, it does not specify when to choose this tool over a sibling, which kind to invoke, or any conditions that should route an agent elsewhere.

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 annotations already establish read-only, idempotent, non-destructive behavior. The description adds meaningful context beyond those annotations: the check is free, quick, and backed by a cached GoPlus dataset rather than a live scan. This clarifies the data-freshness tradeoff without contradicting the annotations.

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 tight sentences deliver the core purpose, data source, and the key comparison to the sibling tool. Every phrase earns its place, and the most decision-relevant information is front-loaded.

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

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

For a simple read-only tool with full schema coverage and an output schema, the description covers the intended use, the data source, the limitation relative to the live alternative, and when to choose that alternative. Nothing essential is missing for an agent to call it correctly.

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

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

The schema already documents both parameters at 100% coverage, including the chain enum, default, and contract format. The description does not add parameter-specific meaning, so the baseline score of 3 is appropriate; no additional compensation 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 names a specific action ('honeypot / risk screen'), a clear resource ('EVM token contract'), and a specific data source ('cached GoPlus security dataset'). It also explicitly separates itself from analyze_token_security, so an agent can distinguish the two tools at a glance.

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 states this is the 'quick screen' and contrasts it with the 'paid analyze_token_security tool' that runs a 'live, deeper scan' on contracts 'including ones not in the cache.' This gives an agent clear routing criteria: use this for cached quick checks and the sibling for deeper or non-cached coverage.

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?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds beyond-schema context: a per-call cost range and the existence of free alternatives, which meaningfully affects whether the agent should invoke this tool. No contradiction with annotations.

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

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

Two dense sentences carry all essential information: what the tool does, the three modes, cost, and alternatives. There is no fluff, and the primary action 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?

Given the four parameters, all with 100% schema coverage, the enum descriptions, and the presence of an output schema, the description is sufficient for an agent to invoke the tool. It also adds the non-obvious billing and free-alternative context that would otherwise be missing.

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

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

Schema coverage is 100%, so the parameters are already well documented. The description maps the kind enum to natural-language scenarios, but it mostly restates the schema descriptions for detection, mempool, and protection. It also mentions 'wallet' while the schema only exposes tokenAddress, adding slight ambiguity.

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

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

The description names a specific resource and verb set: detect sandwich attacks/MEV against a token or wallet, watch the live EVM mempool, or get protected routing advice. It is concrete and distinguishes this tool from general onchain/analytics siblings such as inspect_onchain or analyze_wallet.

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 three supported use cases and adds practical selection guidance by flagging the paid nature and pointing to free alternatives via list_einstein_capabilities. It does not explicitly name all exclusion cases, but it gives enough context for an agent to decide whether this tool is appropriate.

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

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

Annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description only needs to add context beyond those. It does so by disclosing the per-call cost ($0.60–$1.00) and the existence of free alternatives, plus 'live' scanning. No contradiction exists, and the added cost/context is valuable.

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

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

The purpose is front-loaded in a single clear sentence, followed by a compact pricing/alternatives note. Every sentence earns its place; there is no redundant repetition of the input schema or annotations.

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

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

For a read-only, idempotent tool with a full input schema and an output schema, the description covers the essential operational context: what it scans, the four kinds, the paid nature, and where to find free alternatives. Nothing critical for an agent to select and invoke the tool correctly is missing.

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

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

Schema coverage is 100%, so the schema already documents `kind`, `chain`, and `limit`. The description adds meaningful semantic gloss by translating each arbitrage category into plain-language concepts (e.g., 'flash-loan-fundable routes' for flashloan), which helps an agent pick the right enum value. It does not add extra semantics for chain or limit, but 100% coverage keeps this strong.

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

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

The description states a specific verb ('Scan for live arbitrage') and enumerates four concrete domains that map directly to the `kind` parameter: DEX price dislocations, flash-loan-fundable routes, cross-chain spreads, and prediction-market mispricings. This clearly differentiates find_arbitrage from nearby siblings like find_yield or scan_market.

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

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

The description makes the tool's domain explicit and adds usage context by noting it is a paid call with free alternatives, directing the agent to list_einstein_capabilities. It does not name specific sibling tools or exclusion conditions, but the first sentence plus the pricing pointer gives sufficient 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?

Annotations already declare readOnly/idempotent/openWorld/non-destructive, so the burden is light, and the description adds genuinely new behavioral context: per-call cost ($0.10–$0.75), that it draws on an Einstein credit balance, and that cheaper/free alternatives exist via list_einstein_capabilities. It does not, however, describe rate limits or result freshness.

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 four modes and trailing with the pricing caveat, so the actionable content comes first. The bracket cost note is dense but earns its place; the enumeration is long but not padded.

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

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

With an output schema present the description needn't explain return values, and the rich annotations cover the safety profile. Cost, alternatives, and the four modes are all covered, leaving only minor gaps around result freshness and per-kind behavior.

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 does more than repeat the schema: it expands each `kind` enum value into a concrete opportunity category, which is meaningful semantic scaffolding for selecting the mode. `chain` and `limit` remain purely schema-documented.

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+resource ('Find yield') and enumerates the four distinct opportunity classes (DeFi lending/LP, Pendle fixed-yield YT/PT, vault discovery sweep, liquidations) that map 1:1 to the `kind` enum, letting an agent separate it from siblings like find_arbitrage or get_prediction_market_yields.

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 four modes are described in the order of the `kind` values, which implicitly tells the agent which kind yields which output, and it flags that free alternatives exist for some modes. However, it never explicitly states when to choose one kind over another or when to prefer this tool over competitor siblings, leaving routing largely to inference.

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

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

Beyond the readOnlyHint and idempotentHint annotations, the description discloses that this is an experimental research feature, not investment advice, and that each call costs $0.65 from the user's Einstein credit balance. It also clarifies the bundled nature of the forecast, adding meaningful 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?

The description is dense but every sentence earns its place: purpose, differentiation, risk warning, and pricing are all covered without filler. Key differentiators are front-loaded early in the 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?

With full schema coverage, an output schema present, and annotations covering safety and idempotency, the description fills the remaining gaps: cost, experimental status, free alternatives, and comparison to a sibling. An agent has enough contextual information to decide whether and how to invoke this 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 schema already documents token, chain, and timeframe with clear descriptions and enums. The description adds 'any token' and 'not limited to four assets,' but does not significantly deepen parameter-level understanding 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 states what the tool does: real-time data retrieval and compute bundled with a live dual-model price forecast for any token on any supported chain. It also explicitly distinguishes itself from the sibling get_price_forecast by noting it runs fresh inference and is not limited to four assets.

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 contrasts this tool with get_price_forecast, telling agents this should be used when fresh inference or coverage beyond four assets is needed. It also points to list_einstein_capabilities for free alternatives and discloses the paid nature of the call, giving clear selection guidance.

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

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

Annotations already provide readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true, covering mutation and side-effect safety. The description adds valuable behavioral context: keys are returned once, never stored, and the call is paid from the Einstein credit balance. This goes meaningfully beyond the annotations, but not to the level of a 4-5 because it doesn't disclose details like whether repeated calls necessarily produce different keys or how the paid-billing failure mode behaves.

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-loads the core capability, enumerates the four key kinds, then adds payment and alternative-tool context. The cost parenthetical is slightly dense but necessary. Not a 5 because the cost range and credit-balance note could be tightened without losing information.

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

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

For a one-parameter tool with 100% schema coverage and an output schema present, the description is nearly complete. It covers what the tool generates, the key kinds, the one-time/no-storage behavior, the cost, and the free-alternative route. The only missing context is around the output schema's shape and any authentication/credit prerequisite, but the output schema check minimizes that burden.

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

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

Schema coverage is 100% and the schema includes a clear enum description ('wallet · encryption · signing · random (raw QRNG output)'). The description itself restates the enum values with additional context (post-quantum wallet, encryption key, signing key, raw verified quantum random numbers), adding meaningful product-level meaning beyond the raw schema. The one-parameter design is simple and well-covered.

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

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

The description states a specific verb (Generate) with clear resources (post-quantum wallet, encryption key, signing key, or raw verified quantum random numbers). It also names the sibling list_einstein_capabilities as a pointer for free alternatives, effectively distinguishing the paid quantum generation tool from other key-generation or capability-listing tools in the sibling 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 clearly identifies when to use the tool: when hardware quantum randomness is needed for one of four key types. It also notes paid alternatives exist and points to list_einstein_capabilities, giving the agent an explicit escape hatch for cost-sensitive use. It does not explicitly say 'do not use this for...' or name specific non-quantum sibling alternatives, so a small gap remains.

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?

Annotations already establish readOnlyHint, idempotentHint, and non-destructive behavior. The description adds valuable context: the $1.00 per-call cost, Einstein credit balance, and the fact this is Einstein's internal briefing. No contradiction with annotations.

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 no filler. The core meaning is front-loaded, and the pricing/alternative guidance is compact and relevant.

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

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

For a zero-parameter, read-only tool with an output schema, the description is complete: it states what is returned, adds cost context, and points to alternatives. Nothing needed to call it correctly is missing.

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

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

The tool has zero parameters and schema description coverage is 100%, so there is no parameter burden for the description to carry. Baseline 4 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?

Description names a specific resource: Einstein's own current market context and operating state. It also distinguishes itself from the many market-data siblings by explaining it is the same situational briefing Einstein's autonomous engine reads before deciding.

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 this tool (when you need Einstein's internal context/operating state) and explicitly directs users to list_einstein_capabilities for free alternatives. It does not enumerate specific sibling tools to use instead, but the guidance is clear and actionable.

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?

Beyond the readOnly/idempotent/destructive annotations, the description discloses ranking criteria, that it reports both graded and pending-horizon calls, and that it will openly decline to rank thin records. This meaningfully informs the agent about output limitations and behavior.

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

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

Three purposeful sentences front-load the core purpose, then add ranking philosophy and output caveats. 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 tool is simple: one optional parameter, no required fields, an output schema, and strong annotations. The description covers result interpretation, ranking methodology, and a key edge case (too-thin records), making it complete 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?

Input schema coverage is 100%: the only parameter, limit, is already documented with default and range. The description adds no parameter-specific detail, 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 states a specific resource—'scored track record of public crypto commentators and influencers'—and a clear evaluation method: calls graded against actual outcomes. It also distinguishes itself from popularity-based tools by saying 'ranked by measured hit-rate, not follower count,' which separates it from sibling social/sentiment 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?

Usage context is implied: an agent can infer this tool is for influencer accuracy, but the description gives no explicit when-to-use guidance, exclusions, or named alternatives. It is adequate but leaves the selection reasoning to the agent.

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

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

Annotations already cover read-only, idempotent, non-destructive behavior, so the description only needs to add contextual value; it does so by enumerating the indicator families used and clarifying the non-price perspective. No additional side effects or response traits are mentioned, but none are needed for a zero-param read-only tool with an output 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?

Single front-loaded sentence: the object ('where Bitcoin sits in its cycle') comes first, followed by the method. No filler or redundant restatement of annotations.

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 parameterless, read-only, idempotent tool with an output schema, the description is sufficient: it states the core question, the data basis, and the contrast to price analysis. The only mild gap is the absence of explicit sibling routing, which is already reflected in the usage-guidelines score.

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

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

The tool has zero parameters and the schema already covers all of them (100% coverage). The description adds nothing about parameters, but there are no parameters to document, so the baseline 4 applies.

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

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

The description names a specific resource ('Bitcoin's cycle position') and the method ('on-chain measures: realized-profit, holder-behaviour and valuation indicators'), making it clearly distinct from price-only or market-sentiment tools in the sibling list. Although phrased as a noun clause, the inherited verb 'get' makes the operation 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?

It implies usage when an on-chain cycle view is needed and explicitly contrasts itself with price-only analysis ('rather than price alone'). However, it never names a sibling alternative or states explicit when/when-not conditions, so routing decisions are left to inference.

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

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

Annotations already establish readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful ordering behavior ('newest first') and recency framing ('Recently disclosed'), but it does not elaborate on pagination, data freshness limits, or any other operational nuances beyond what annotations and schema already convey.

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

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

A single sentence conveys the resource, scope, and ordering without extraneous words. Information is front-loaded and every element earns its place, 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, one-parameter read-only tool with full schema coverage, a rich annotations block, and an output schema, the description is complete. It communicates the essential result shape and ordering; nothing necessary for correct invocation is missing.

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

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

Schema description coverage is 100%: the single 'limit' parameter is fully documented with type, default, and range. The description does not mention parameters at all, but with complete schema coverage, the baseline of 3 is appropriate. No additional semantic burden is placed on 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 identifies the resource—recently disclosed stock and asset transactions by US Congress members—and specifies ordering as newest first. It lacks an explicit imperative verb like 'list' or 'retrieve,' but the intent is unmistakable and sufficiently distinguishes it from sibling tools focused on other data domains.

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 guidance on when to use this tool versus alternatives such as get_government_contracts, get_market_sentiment, or get_trade_signals. There is no mention of use cases, exclusions, or contextual conditions, leaving the agent to infer applicability solely from the tool 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?

Beyond the readOnlyHint and idempotent annotations, the description adds important behavioral context: results are out-of-sample, scored only after the horizon elapses, and hit rates are computed over independent trials comparable to a 50% coin flip. This prevents an agent from misinterpreting the metric and goes well beyond what annotations already declare.

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 definition, and every sentence contributes either the method, the statistical interpretation, or the intended use. There is no filler or repetition of schema fields.

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

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

For a read-only tool with two optional parameters and an output schema, the description covers what is returned, how it is computed, and how to interpret it. Nothing an agent needs to invoke the tool correctly or judge its results is missing.

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

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

Schema description coverage is 100%, so asset and limit are already fully documented in the input schema. The description adds no additional parameter-level semantics, so the baseline score of 3 applies.

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

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

The description names a specific resource ('Einstein's own price forecasts'), the exact metrics (MAPE and direction hit-rate), and how results are broken down (per model, asset, horizon). The phrase 'Einstein's own' also implicitly distinguishes it from sibling tools like get_analyst_accuracy or get_price_forecast, so an agent can tell them apart.

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

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

'Use this to decide how much weight to give a forecast' provides a clear decision-oriented use case. It does not explicitly name exclusions or alternatives, but for a read-only accuracy lookup the intended context is specific enough to guide 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that results are 'recent notable' awards, but does not disclose update frequency, data source, or whether 'notable' implies filtering or ranking. This is acceptable for a read-only list tool but does not go beyond the annotations meaningfully.

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

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

A single sentence conveys the core data and the most relevant use case with no filler. It is front-loaded with the subject matter and immediately useful to an agent deciding whether to call the tool.

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

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

For a simple, read-only, single-parameter tool with an output schema, the description is largely sufficient. It gives the subject and purpose, and the annotations cover the operational safety hints. A minor gap is that 'notable' is undefined, but this does not prevent a correct call.

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

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

Schema description coverage is 100%: the lone parameter, limit, is fully documented with type, default, and range. The description adds no parameter-specific information, but none is needed because the schema already handles it.

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

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

The description clearly identifies the resource ('US federal contract awards') and the use case ('tracking which public companies are winning government money'), which differentiates it from siblings like get_congress_trades. It lacks an explicit verb such as 'retrieve' or 'list,' but the name and title make the action unambiguous.

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

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

The description gives a clear context for use: tracking notable federal contract wins by public companies. It does not explicitly name alternatives or state when not to use it, but among the siblings, no other tool covers government contract awards directly, so the intended usage is reasonably clear.

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

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

Annotations already indicate read-only, idempotent, and non-destructive behavior, and the description adds valuable non-obvious semantics: coins with fewer than 3 read whales are forced to NEUTRAL, and unread whale accounts are reported rather than treated as flat. This meaningfully goes beyond the annotation safety profile and prevents incorrect interpretation of the data.

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

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

The description is well front-loaded with the main purpose before diving into caveats. The caveat about the 3-whale consensus threshold and unread accounts is dense but necessary; it is slightly heavy in parenthetical detail, preventing a perfect score.

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 low-complexity tool with one optional parameter and an output schema, the description covers everything needed to invoke it correctly: scope, the meaning of consensus, the NEUTRAL rule, and handling of unread accounts. Return structure can be left to the existing 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?

The only parameter, limit, is already fully documented in the input schema with a default and range, so schema coverage is 100%. The description does not add parameter-specific semantics, but with full schema coverage the baseline of 3 is appropriate.

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

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

States a specific resource (largest Hyperliquid perp traders), the data produced (consensus positioning plus funding rates), and the core concept (what big leveraged money is long/short and what it costs to hold). This clearly differentiates it from sibling tools like get_polymarket_whales or track_whales by naming the exchange, asset class, and funding component.

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

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

The context for use is clear: it is for Hyperliquid perpetual positioning and funding rates. However, it does not explicitly state when to choose this tool over alternatives or provide exclusions, such as 'for Polymarket use get_polymarket_whales'. Usage is implied rather than directly guided.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds meaningful context beyond that: it reveals the tool's analytical content, multi-launchpad coverage through 'one feed,' and the specific wallet categories included in the forensics. This is useful behavioral context without contradicting the annotations.

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 tightly structured: the first sentence states what the tool returns, the second covers supported launchpads, and the third gives the usage cue. Every sentence earns its place with no repetition or filler.

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

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

With only one optional parameter fully documented in the schema, an output schema present, and annotations covering safety, the description provides enough context for an agent to select and invoke the tool correctly. Nothing critical is missing.

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

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

The input schema has 100% coverage for the single `limit` parameter, which is already described as 'Rows to return (1-15).' The description does not add parameter-level detail, 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: tokens that just migrated off a bonding curve onto a DEX, with holder-distribution forensics and wash-trading tags. It distinguishes itself from siblings through its specific focus on migration, bundling forensics, and multi-launchpad coverage, though it lacks an explicit verb like 'list' or 'fetch.'

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

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

It explicitly states when to use the tool: 'Use when asked about new launches, fresh memecoins, or whether a launch is bundled.' It does not mention when not to use it or name alternatives like scan_launchpads, so it stops short of full 5-level 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?

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds useful context about the aggregated nature of the data ('in one read' and the source list), but doesn't go into deeper behavioral details like staleness or update frequency. That's acceptable given the annotations carry the 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?

Two sentences with zero waste: the first names exactly what the tool returns, the second states its purpose. Front-loaded and scannable.

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 no-parameter read with an existing output schema and safety annotations, the description is complete. It lists every data source and provides a crisp use case; nothing an agent needs to invoke it correctly is missing.

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

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

The tool has zero parameters, so the schema trivially covers 100% of parameter semantics. Per the baseline for zero-parameter tools, a 4 is appropriate; no description-level parameter documentation 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 states a specific verb and resource: it reads multi-source market sentiment, and lists exactly four indices (crypto Fear & Greed, CoinMarketCap’s variant, CNN Fear & Greed, Altcoin Season index). This level of specificity clearly distinguishes it from sentiment-adjacent siblings like get_social_hype or scan_market.

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 states when to use the tool: 'Useful for framing any “how is the market feeling” question.' However, it does not name alternatives or state when not to use it, which keeps it just below 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?

The annotations already disclose read-only, idempotent, and non-destructive behavior. The description adds meaningful context about selection criteria ('large and unusually-early positions') and provenance ('insider-detection scan'), which clarifies what data will be returned. It does not define thresholds or ordering, but that is not essential given the output 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?

A single dense sentence delivers the core resource, qualifiers, and data source without filler. Every phrase earns its place, and the most identifying information is front-loaded.

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

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

Annotations, input schema, and output schema collectively cover safety, parameters, and return structure. The description supplies the market and data-source context needed to disambiguate from similar whale tools, though it could be slightly stronger with an explicit alternative or exclusion note.

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 only parameter, limit, is fully documented in the schema with a default and range (1-25), so the schema carries the semantic burden. The description adds no parameter-specific information, which is acceptable at 100% schema description coverage.

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

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

The description identifies a specific resource—large and unusually-early positions on Polymarket prediction markets—and adds provenance from the insider-detection scan, which helps distinguish it from sibling whale-tracking tools by platform. It lacks an explicit retrieval verb like 'list' or 'get,' but the tool name and title make the action 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 implies usage for Polymarket whale data sourced from insider-detection scanning, but it does not explicitly state when to choose this tool over alternatives such as get_hyperliquid_whales or track_whales. No exclusions or routing conditions are provided.

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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful selection behavior — upcoming dated events and moving odds — but does not detail sorting, time horizon, or data staleness. This is acceptable for a simple read operation but only moderately 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?

One sentence front-loads the resource and filter, then states the tool's purpose. Every word earns its place with no redundant filler or repetition of schema or annotation information.

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

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

For a read-only, one-parameter endpoint with an output schema and full annotation coverage, the description provides enough context to invoke the tool correctly. The only notable gap is the lack of explicit differentiation from closely related prediction-market sibling tools, but this is not critical for basic 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?

Schema description coverage is 100% for the single limit parameter, including default and range, so the schema carries the parameter semantics. The description adds no parameter-specific detail, which is fine under the baseline-3 rule.

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 ('upcoming dated events on Polymarket') and the selection criterion ('odds are moving'), so an agent can tell what data the tool returns. It lacks an explicit verb like 'list' or 'return', but the meaning is unambiguous and distinct from sibling tools focused on yields, whales, or broad market 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 when an agent wants near-term, narrative-moving catalysts, but it does not explicitly state when to use this over siblings such as get_prediction_market_yields or analyze_prediction_markets. No exclusions or decision rules are provided.

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?

Annotations already convey read-only, idempotent, non-destructive behavior, so the bar is lower here. The description adds genuinely useful behavior beyond those annotations: it filters to near-certain outcomes and ranks by annualized return to resolution, which is the tool's core selection logic.

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

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

A single dense sentence that front-loads the key selection and ranking criteria. Every phrase earns its place, and there is no redundant restatement of the title or annotations.

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 low parameter count, rich annotations, and presence of an output schema, the description is sufficient for correct invocation. The only minor gap is not specifying the ranking direction explicitly, but 'ranked by annualized return to resolution' strongly implies descending yield.

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

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

There is only one parameter, limit, and the input schema provides full documentation with default and range (1-25). Per the baseline for high schema coverage, the description does not need to add parameter-level detail.

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

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

The description names a specific resource (Polymarket outcomes), a specific filter (near-certain), and a specific ordering (annualized return to resolution). The 'cash-like yield' framing clearly separates it from siblings like get_prediction_market_catalysts or analyze_prediction_markets.

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 this tool is for viewing prediction markets as a cash-like yield surface, so an agent could infer when to call it. However, it does not explicitly state when to prefer this over sibling tools such as analyze_prediction_markets or get_prediction_market_catalysts, nor does it name any 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?

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds valuable behavioral detail: the forecast is pre-computed every 4 hours and returns a cached run rather than triggering new inference. This goes beyond the annotations and meaningfully shapes agent 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?

Two tightly written sentences with no filler. The core purpose is first, followed by the model detail and the critical caching caveat. Every sentence contributes distinct 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?

With an output schema present, return-value documentation is already handled. The description states scope, asset universe, model composition, output characteristics, freshness cadence, and the no-new-inference behavior. An agent has everything needed to invoke this tool correctly.

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

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

Schema description coverage is 100%, and each parameter has a useful description, including the lookahead horizon per interval. The description adds asset names but no extra parameter-level semantics. Baseline 3 is appropriate because the schema carries the full parameter burden.

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

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

The description names a specific verb (get), resource (price forecast), and the exact assets covered (BTC, ETH, SOL, BNB). It also adds distinguishing content: dual-model ML, agreement between models, and direction/drift projections. This clearly differentiates it from accuracy or chart-related sibling forecast 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 explains the tool's cached nature but provides no guidance on when to choose this over alternatives like get_forecast_accuracy or forecast_chart. It neither states conditions for use nor points to sibling tools for other purposes.

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?

Annotations already mark the tool read-only, idempotent, and non-destructive. The description adds substantial behavioral context beyond annotations: cross-checked USDG/ETH valuation, exclusion of mispriced freshly-created-pool trades, and separate counting of WETH/USDG FX swaps.

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

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

Three dense sentences front-load the core purpose and then add only high-value caveats about valuation, exclusions, and swap handling. 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?

With one optional parameter, an output schema, and read-only/idempotent annotations, the description thoroughly covers expected fields and important data-quality behavior. An agent has everything needed 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 only parameter, limit, is fully documented in the input schema with 100% coverage. The description adds no 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?

States a specific verb and resource: retrieving individual large DEX trades on Robinhood Chain (EVM 4663), with concrete assets and per-print fields. This clearly distinguishes it from sibling tools like get_hyperliquid_whales, get_polymarket_whales, and track_whales.

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 by describing Robinhood Chain-specific data 'that no mainnet whale feed carries', implying when this tool is relevant. It does not explicitly name alternatives or state when-not-to-use it, so it falls just short of a 5.

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

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

Annotations already establish that this is read-only, idempotent, and non-destructive. The description adds useful context: data comes from a tracked smart-money cohort of profitable wallets and reflects recent capital rotation. It does not disclose details like time window or inclusion criteria, but the output schema covers the return shape.

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 with no filler, and the core concepts of cohort and capital rotation are front-loaded. It is slightly fragmentary, but it is appropriately compact for a simple read-only tool.

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

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

For a one-parameter read-only tool with an output schema and clear annotations, the description is largely sufficient. The main gaps are the lack of a defined time window and the absence of any clarification on how this tool differs from the similar get_smart_money_inflow sibling.

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 a single parameter, limit, which is fully described with a default and range. The description does not mention limit, but with 100% schema description coverage, the schema carries the semantic burden, 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 identifies the resource (profitable on-chain wallets in the tracked smart-money cohort) and the action (rotating capital), so an agent can infer this is a read about recent smart-money movement. However, it is phrased as a fragment rather than a clear verb statement, and it does not distinguish 'flow' from the sibling get_smart_money_inflow.

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 such as get_smart_money_inflow or track_whales. The word 'recently' implies temporal context, but there are no explicit use cases, exclusions, or alternative comparisons.

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?

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds valuable interpretive context: it reports distinct wallet counts and warns that a large single-wallet inflow is 'a position, not a consensus,' plus it specifies the chain (BSC) and timeframe. This goes beyond annotations without contradicting them.

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

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

Three sentences with no fluff: the first states what and how, the second adds an important interpretative caveat, and the third gives usage guidance. Each sentence earns its place and the main 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?

For a simple one-parameter read-only tool with an output schema present, the description covers the key context: metric, timeframe, data source, chain, interpretation, and when to use. There is no missing information an agent would need to call it correctly.

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

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

The only parameter, limit, is fully documented in the schema with description 'Rows to return (1-15).' Schema coverage is 100%, so the description does not need to add parameter details. The description adds no extra meaning beyond the schema, meeting the baseline but not exceeding it.

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

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

The description clearly states a specific verb ('ranked'), resource ('tokens'), metric ('NET smart-money inflow in US dollars'), and timeframe ('last 24 hours'). It distinguishes implicitly from the similar sibling get_smart_money_flow by emphasizing 'NET' and 'BSC', but does not explicitly name the sibling or state the exact differentiation.

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

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

The description includes an explicit usage trigger: 'Use when asked what smart money is buying or where informed flow is going.' This gives clear context for when the tool applies. It does not mention when-not-to-use or name alternatives, 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.

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds valuable behavioral context: the time window (24 hours), the data composition (sentiment, KOL count, summary), and the network (BSC). It does not contradict annotations and provides meaningful additional detail.

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 well-structured, front-loading the core function (ranking by social buzz) before detailing output and usage. No wasted words; every clause serves a purpose, 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?

The description covers the tool's purpose, output details, network, and usage guidance. Since an output schema exists, the absence of explicit return format details is acceptable. It is complete enough for an agent to call correctly, with only minor gaps like pagination or edge cases that are typically not required.

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

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

Schema coverage is 100%, so both parameters are already described in the schema. The tool description reinforces the sentiment parameter by mentioning sentiment classification, but does not add new semantic meaning 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?

The description clearly states the tool's function: it ranks tokens by social buzz over the last 24 hours, specifying the output fields (sentiment, KOL count, summary) and the network (BSC). It distinguishes itself from siblings like get_market_sentiment by focusing on social buzz and KOL discussions, making it easily identifiable.

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 directions are given: 'Use when asked what is being talked about, what is trending socially, or how sentiment sits on a token.' It does not name alternatives or state when not to use it, but the conditions are clear and the BSC scope further narrows applicability, making it a strong, though not exhaustive, guideline.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the trait 'refreshed market snapshot,' which signals that results are time-sensitive and drawn from a current data state. There is no contradiction with the annotations.

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

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

A single sentence that front-loads the core result ('largest 24h movers'), then adds scope and freshness. Every phrase earns its place, with no redundant filler or restatement of the title.

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

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

For a low-complexity, read-only retrieval tool with only two optional parameters and a full output schema, this description is nearly complete. It conveys the universe, timeframe, direction options, and freshness. Minor ambiguities remain, such as whether 'movers' means percentage change or absolute change and what 'major-cap' includes, but they are not blocking.

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%: both 'side' and 'limit' are documented in the schema with their defaults and constraints. The description does not need to add parameter meaning, and it mostly restates the 'gainers or losers' concept already captured by the enum.

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 identifies a specific resource: the largest 24h movers in the major-cap crypto universe, explicitly including gainers or losers. It lacks an imperative verb like 'list' or 'return', but the noun phrase and title make the tool's function clear. It is distinguishable from many siblings because it pinpoints a 24-hour movers board rather than sentiment, flows, or scans.

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 usage context is implied: an agent should call this when it needs the top 24h gainers or losers across major-cap crypto. However, there is no explicit guidance about when to prefer this over alternatives such as scan_market or get_market_sentiment, and no exclusions are stated.

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

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

Beyond the readOnly/idempotent annotations, the description discloses a per-call cost ($0.50) and notes that free alternatives exist. It does not mention any side effects or errors, but the cost and alternative availability are valuable behavioral details not present in annotations.

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, with the core purpose stated first, followed by cost and alternative guidance. It is well-structured and free of fluff, 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?

The description gives sufficient context about the returned data (levels and reasoning) and the current live nature of signals. It lacks details on output format or pagination, but for a simple read-only tool with one parameter, it provides enough to decide when and how to use it.

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

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

The only parameter 'limit' is already fully described in the schema with its default and range. The tool description adds no extra meaning about the parameter, so it matches the baseline score for high schema coverage.

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

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

The description clearly states that this tool provides Einstein's current live trade signals, including entry, stop, target levels, and reasoning. It specifies the unique source ('autonomous engine') and distinguishes it from sibling tools that offer other market data.

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 indicates the tool is paid and points to free alternatives via list_einstein_capabilities, giving the agent a clear choice. However, it does not explicitly state 'use this when you need Einstein's own signals' or contrast with a specific sibling, so guidance is slightly less 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?

Annotations already provide the read-only and non-destructive profile, and the description adds substantial behavioral context: proxy resolution order, implementation-vs-stub behavior, exact gas arithmetic including OP-stack L1 fees, and graph edges carrying real transaction hashes. The claim of '18 EVM chains' conflicts with the schema's seven enum values and includes Solana, which is not EVM, so the behavioral disclosure is slightly overconfident.

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 organized: a one-line overview, then mode-by-mode behavioral details, then safety and cost/alternatives in a compact final sentence. Every sentence earns its place, and backticked mode names make the structure scannable for an agent.

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 invocation modes, required inputs, output characteristics, read-only safety, pricing, and where to find alternatives, and an output schema exists to document return shapes. However, the inconsistency between '18 EVM chains' and the schema's seven-value enum (which includes non-EVM Solana) leaves a real completeness gap that could confuse an agent about supported networks.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful parameter-level semantics by explaining what each `kind` produces and what inputs are needed. It clarifies the `flow` mode's graph output and the `transaction` mode's decoded-method and revert-reason details, which go beyond the schema's brief field descriptions.

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 and resource: 'Block-explorer intelligence on 18 EVM chains' with three concrete modes — `contract` reviews, `transaction` explains, and `flow` follows money. This strongly differentiates it from the sibling analytics tools and leaves no doubt about the tool's core 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?

Each mode names the input it requires (`contract` needs `address`, `transaction` needs `txHash`, `flow` starts from a transaction or wallet), giving the agent clear selection criteria. It also explicitly points to `list_einstein_capabilities` for free alternatives, which is useful cost-aware guidance, though it does not name specific sibling tools that should be preferred.

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?

Annotations already cover the read-only, idempotent, non-destructive nature of the tool. The description adds valuable behavioral context by disclosing that it returns a categorized catalog with pricing and billing details, which is beyond what the annotations provide.

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

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

Two sentences, front-loaded with the tool's purpose and followed by clear usage guidance. Every sentence earns its place 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?

For a zero-parameter, read-only discovery tool with an output schema and strong annotations, the description is fully adequate. It explains what the output includes and when to invoke it, leaving no critical gap for an agent to call it correctly.

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

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

This tool has zero parameters, so the baseline of 4 applies. There is nothing for the description to clarify in terms of parameter meaning, and it rightly does not invent any.

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 ('list') and a clear resource ('Einstein capabilities through this connector'), and further specifies the output is split into free and paid tools with prices and billing info. This clearly differentiates it from the many analysis/get sibling tools.

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

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

It explicitly states when to call: when unsure which tool fits or before telling the user something isn't available. It does not equally explicitly state when not to use it or name alternative tools, but the guidance is clear enough for an agent to route to it appropriately.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context beyond that: the call costs $0.50–$1.00 from the Einstein credit balance, free alternatives may exist, and the tool performs evaluative judgments such as passing Einstein's strategy gate or providing a meta-strategy read. No contradiction with the annotations was found.

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 and front-loaded. The first sentence states the core purpose and enumerates the specific use cases; the second adds essential cost and alternative guidance. Every sentence earns its place with 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 read-only tool with only two parameters, a clear enum, and an output schema, the description is largely complete. It covers the main use cases, cost, and the existence of free alternatives. The only notable gap is that it does not explain when each kind should be preferred over another, but the schema and output schema mitigate that 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 already documents both parameters. The description adds meaningful semantics to the enum values by explaining that portfolio_risk relates to portfolio risk allocation, strategy_split to splitting capital across strategies, gate_check to Einstein's strategy gate, and meta_strategy to a whole-market read. The context parameter is less enriched, but the overall parameter understanding is well supported.

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 what the tool provides: risk-aware allocation guidance, with four concrete outputs (portfolio risk allocation, strategy split, Einstein's strategy gate check, and meta-strategy read). This makes it easy to distinguish from the many sibling analysis and data-retrieval tools, especially by naming list_einstein_capabilities as the place to find free 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?

The description implies when to use the tool: whenever a user needs allocation guidance or strategy gate/meta-strategy insight. It also warns that free alternatives exist for several of these use cases and directs users to list_einstein_capabilities. However, it does not explicitly specify which use cases have free alternatives or name the alternative tools, so the guidance remains somewhat vague.

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?

Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds the meaningful cost disclosure ('$0.75–$2.00 per call from your Einstein credit balance') and clarifies that it runs on historical data, which is useful behavioral context 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 a single well-structured sentence that front-loads the core purpose, then efficiently lists supported modes and adds cost/alternative guidance. No filler or redundant repetition of the title.

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

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

With an output schema present and annotations covering safety, the description is nearly complete: it explains the main invocation modes, mentions cost, and points to alternatives. The only minor gap is that it does not explain the 'engine' kind, but the schema already documents that enum value.

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 partially reinforces the meaning of 'strategy' and the 'kind' modes, but it does not add significant new meaning for parameters like 'asset' or the 'engine' kind 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 states a specific verb ('Backtest') and resource ('a trading strategy on real historical data'), and explicitly enumerates the main modes: custom plain-language rules, standard template, and parameter optimization. This clearly distinguishes it from sibling analysis and forecasting 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 gives clear context on what the tool does and notes that 'free alternatives exist for several of these', pointing to list_einstein_capabilities. It does not provide exhaustive when-not-to-use guidance, but it does alert the agent to cost and 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering the main behavioral aspects. The description adds the paid nature and existence of free alternatives, which is useful context but does not significantly extend beyond the annotations regarding execution 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, clear sentence that conveys the core purpose and includes the paid note and free alternatives. It is well-structured and free of unnecessary verbosity.

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 mentions the target venues, the paid nature, and alternatives, while the output schema presumably details the return format. It does not cover edge cases like rate limits or error handling, but for a tool of this simplicity, the provided information is adequate for a user to decide when to invoke it.

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

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

Schema descriptions cover all three parameters (limit, venue, timeframe) with clear meanings and enum values for venue and timeframe. The description does not add extra semantics, but the schema itself is sufficiently informative, warranting a score above 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 as scanning for new and trending token launches, specifies the supported venues (Pump.fun, Zora, Robinhood Chain), and distinguishes it from other launch-related tools by focusing on 'new and trending' rather than radar or market scans. The verb 'scan' and resource 'launchpads' are explicit.

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

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

The description mentions that the tool is paid and that free alternatives exist via list_einstein_capabilities, which provides some context. However, it does not explicitly state when to use this tool over sibling tools like get_launchpad_radar or scan_market, leaving the choice somewhat 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?

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the read-only/unmutating profile is established. The description adds valuable behavioral context beyond annotations: live data, a per-call cost from the Einstein credit balance, and the existence of free alternatives.

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 compact sentence front-loads the tool's purpose and then lists the variants, with a parenthetical cost note appended. No wasted words and the structure is scannable.

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?

Between the annotated safety profile, the 100%-covered schema, and the output schema, the description covers what the tool does, its cost, and that free alternatives exist. It does not explain default chain/limit behavior, but those are in the schema, so nothing essential is missing for selecting and invoking it.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description does not meaningfully expand on parameters—it merely restates scan kinds that match the kind enum, with the technicals requirement already covered in the schema. Baseline 3 applies.

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

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

The description opens with a specific verb and resource ('Live market scans') and enumerates six distinct scan kinds, making the tool's scope concrete. It doesn't explicitly differentiate from overlapping siblings like get_top_movers or get_market_sentiment, so it stops short of a 5.

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

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

It states the tool is paid and points to free alternatives via list_einstein_capabilities, giving a cost-based reason to choose an alternative. However, it doesn't specify which alternative applies to which scan kind or provide conditional usage rules, so guidance remains incomplete.

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?

Annotations confirm it's a read-only, idempotent, open-world operation. The description adds valuable context: permissions are decoded from the hook address (capability, not intent), most delta-taking hooks are ordinary launchpads, and a large share of liquidity is uncatalogued. It also mentions the paid cost. It doesn't disclose rate limits or exact output format, but output schema exists.

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

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

The description is front-loaded with the core purpose and scope, then adds crucial caveats (capability vs. intent) and pricing. It is somewhat lengthy but every sentence earns its place by adding interpretative context. No unnecessary repetition.

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

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

Given the complexity of the tool (on-chain census with permission decoding and registry gaps), the description provides sufficient context about what is analyzed, the chains involved, the nature of the data, and the cost. It complements the existing output schema and annotations without redundancy.

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

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

Schema description coverage is 100%, so the single parameter 'chainId' is fully documented in the schema, including enum meanings and omission behavior. The description doesn't add parameter-level semantics beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description uses a specific verb ('Census') and resource ('the Uniswap v4 hook layer') with clear scope (Robinhood Chain 4663 and Base). It differentiates from siblings like scan_launchpads and get_launchpad_radar by focusing on hook contracts, permissions, and registry coverage rather than general launchpads.

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 notes the paid nature and points to 'list_einstein_capabilities' for free alternatives, providing some cost-based guidance. However, it does not explicitly state when to use this tool versus other on-chain analysis tools like scan_launchpads or inspect_onchain, leaving some 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?

Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses the cost per call and notes that free alternatives exist for some functionalities. This adds transparency about the tool's commercial nature without contradicting annotations.

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, two sentences, and well-structured. It presents the core functionality and then adds cost and alternative information in a bracketed note, keeping the main purpose prominent without unnecessary 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?

Given the output schema exists and is not described, the description adequately covers what the tool does, its cost, and alternatives. It provides enough context for an agent to decide when and how to use it, without missing critical 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?

All four parameters have schema descriptions, and the enum values for 'venue' and 'timeframe' are explained clearly. While the descriptions are concise, they are sufficient for understanding the expected inputs. The tool description itself does not add extra parameter details, but the schema coverage is complete.

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: providing live intelligence on whale activity across on-chain transfers, Hyperliquid perps, and smart-money cohorts. It is specific and distinguishes the tool's 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?

The description explicitly mentions paid pricing and points to free alternatives via list_einstein_capabilities, giving clear guidance on when to use this tool versus cheaper options. It also implies a real-time intelligence use case.

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