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, 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?

Goes well beyond the readOnly/idempotent/non-destructive annotations by disclosing pricing ($0.05–$0.60 per call, billed to the Einstein credit balance) and a no-charge guarantee when the tier exceeds the video length or the video is unreadable. This cost and refusal behavior is exactly the context annotations cannot 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?

The output inventory is front-loaded in the first clause, followed by length semantics and then cost/refusal terms. It's dense but each element earns its place; the single long opening sentence is the only minor readability cost.

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

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

An output schema exists, so return values needn't be re-explained, yet the description still sketches what comes back and covers cost, tier validation, and refund behavior. 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?

Schema coverage is 100%, so both parameters are already documented; the description's restatement of the length tiers largely duplicates the enum descriptions. It adds a small amount — clarifying that a too-long tier is refused rather than truncated — but stays at the baseline for fully documented parameters.

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

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

States a specific verb ('Analyse') and resource ('one YouTube video from its link') and enumerates the concrete outputs: summary, timestamped key points, market calls with ticker/direction/conviction/horizon, sponsor mentions, and graded channel record. This clearly distinguishes it from siblings like analyze_bitcoin or ask_einstein.

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?

Frames usage around a single video link and points to a concrete alternative path — 'Free alternatives exist for several of these — see list_einstein_capabilities' — routing cost-sensitive callers elsewhere. It doesn't give explicit when-not-to-use conditions beyond the length-tier refusal rule, so not quite 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 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 safety is covered. The description adds the meaningful non-annotation trait: a per-call charge of $0.50–$0.75 drawn from an Einstein credit balance, which the agent must weigh 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?

Two sentences, front-loaded with capability and closed with the cost/routing caveat. No filler, and the pricing note is set off in brackets so it does not obscure the primary 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?

A read-only assessment tool with a full output schema, so return values need no explanation. Purpose, mode selection, cost, and cost-free alternatives are all present; nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100% and the enum values are fully documented in the schema. The description restates the three modes and the wallet dependency for portfolio/migration, but adds no format, syntax, or constraint detail beyond what the schema already carries.

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 ('assess') and a narrowly defined resource ('exposure to cryptographically-relevant quantum computing'), then enumerates the three concrete outputs (PQC readiness, migration plan, wallet address-type risk). An agent can distinguish this from every sibling, including the superficially similar generate_quantum_key.

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

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

Explicitly flags that this is a paid tool and that free alternatives exist for several modes, routing the agent to list_einstein_capabilities. That is genuine selection guidance, though it stops short of spelling out which specific modes have free substitutes or when cost is justified.

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 readOnly, idempotent, non-destructive and openWorld behavior, so the bar is lower. The description adds genuinely new behavioral context the annotations lack: the per-call cost, the credit-balance source, and the shape of the output (score + rationale + recommendation).

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 core purpose is front-loaded, but the single run-on sentence awkwardly welds two unrelated operations together ('...recommendation, or the list of yield vaults...'), and the bracketed payment note is dense. It is compact but not cleanly structured.

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

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

An output schema exists, so return values need not be detailed, and the description nonetheless sketches them. Cost, credit source, and mode routing are covered; only the absence of explicit when-to-use-vs-alternatives guidance keeps it from being fully complete.

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

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

Schema description coverage is 100%, and the enum for `kind` is fully documented in the schema, so the baseline is 3. The description's 'text you supply' and 'vaults Einstein has scanned' restate what the schema already explains rather than adding format, length, or constraint 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 gives a specific verb+resource: AI moderation of supplied text returning a 0-10 score with rationale and recommendation, plus a secondary 'vaults' listing mode. It is clear what the tool does, though the two unrelated modes are squeezed into one sentence and no sibling is named to disambiguate the tool within the crowded analysis toolset.

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 flags that the tool is paid ($0.05–$0.10 per call) and explicitly directs the agent to list_einstein_capabilities for free alternatives, which is real routing guidance. It does not, however, state when to prefer this tool over those alternatives or when each mode applies, leaving that to the schema.

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 safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds real context beyond them: the result is free and served from a cache, implying possible staleness and a cost tradeoff against the paid sibling. It stops short of saying what happens when a contract is not in the cache (error vs empty result), which is the one behavioral detail an agent would still want.

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 identity and data source, then the disambiguation against the alternative. No filler or restated title text.

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?

An output schema exists, so return values need no explanation, and purpose, cost, freshness, and routing are all covered. The only gap is failure behavior for uncached contracts, which the sibling's phrasing hints at but this description never states directly.

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

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

Schema description coverage is 100% and both parameters are documented in the schema, including the chain enum and the contract address format. The description adds no parameter-level detail beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb and resource ('honeypot / risk screen for an EVM token contract') plus the data source ('cached GoPlus security dataset'). It explicitly names the sibling it differs from (analyze_token_security), so an agent can separate the two without opening either schema.

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

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

Explicitly frames this as the 'quick screen' and names the alternative ('the paid analyze_token_security tool runs a live, deeper scan'), including the distinguishing condition that the sibling covers contracts not in the cache. When-to-use and when-to-use-something-else are both 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?

Annotations already cover readOnlyHint, destructiveHint=false, idempotentHint and openWorldHint, so the safety profile is set. The description adds value by disclosing the per-call cost and the credit-balance billing source, which is behavioral context absent from the annotations. It does not mention rate limits or return shape, keeping it below a 5.

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

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

Two sentences with the core purpose front-loaded and the billing note bracketed at the end. Every element earns its place with no redundancy.

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

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

With an output schema present, return values need no explanation, and all four parameters are documented. The description adequately covers both operating modes and the billing caveat; only the detection-vs-protection selection nuance is left entirely to the schema.

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

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

Schema description coverage is 100% with 3 enums whose values are documented (kind, chain, timeframe) and a described tokenAddress. The description adds no parameter-level syntax or format detail beyond what the schema already provides, 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 uses a specific verb (detect) with a concrete resource (sandwich attacks and MEV extraction against a token or wallet) and also covers the second mode, protected routing recommendations. It maps cleanly onto the `kind` enum values of detection/protection, letting an agent understand both functions without opening the schema.

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

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

It discloses paid cost ($0.50–$0.60 per call) and points to list_einstein_capabilities for free alternatives, which is genuine when-to-use guidance. It does not explicitly state when to prefer detection vs protection (that is left to the schema enum descriptions), so it stops short of full alternative routing.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds the trait annotations cannot express: per-call cost of $1.00 billed against the Einstein credit balance, plus the existence of cheaper alternatives. No rate limits or result-freshness behavior is described, but the paid-operation disclosure is exactly the kind of context annotations cannot carry.

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, no waste. The capability list is front-loaded and the cost/routing caveat follows immediately after, in the position a reader will actually reach before calling.

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?

An output schema exists, so return-format explanation is not owed. Given a 3-param, zero-required, paid, read-only tool, the description covers what it does, what it costs, and where to find cheaper options. The one gap is the unmapped 'DEX price dislocations' mode that no `kind` value can request.

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 names, enums, defaults, and ranges are already documented, giving a baseline of 3. The description implicitly glosses the three `kind` values (flash-loan routes, cross-chain spreads, prediction-market mispricings), but its mention of 'DEX price dislocations' corresponds to no enum value, which is a mild ambiguity, and `chain`/`limit` get no extra meaning.

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 (scan) and resource (live arbitrage) and enumerates its sub-domains: DEX price dislocations, flash-loan routes, cross-chain spreads, prediction-market mispricings. This is clearly distinguishable from adjacent siblings like find_yield, detect_mev, and scan_market. It stops short of explicitly contrasting itself with those tools, so it is clear but not sibling-differentiating.

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

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

It gives the key cost condition ($1.00 per call from the credit balance) and routes the agent to alternatives: 'Free alternatives exist for several of these — see list_einstein_capabilities.' That is a genuine when-not-to-use signal, though it does not state which specific free sibling maps to which arbitrage kind, leaving the agent to open list_einstein_capabilities.

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?

Goes well beyond annotations: entropy returned once and not stored (ephemeral output), no account created, no wallet connection, no fund movement, plus per-call pricing and where the charge comes from. This is exactly the value-add a description should supply on top of the readOnlyHint=false annotation.

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

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

Front-loads the core action, then output kinds, then ephemerality, then cost and alternative pointer. Four tight sentences, each carrying distinct information with no repetition.

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

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

Covers purpose, output kinds, ephemerality/non-storage, cost, and free alternatives, and an output schema exists so return values needn't be spelled out. 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?

Schema coverage is 100% and the enum is self-documenting, so baseline is 3; the description earns a 4 by explaining what each kind yields (seed phrase entropy, AES-256 key, signing key, raw numbers) and noting the 'returned once' semantics for the generated material.

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 (generate key material from quantum randomness) and enumerates the concrete outputs (BIP-39 seed entropy, AES-256 key, signing key, raw QRNG numbers). No sibling tool does anything similar, so it's unmistakable.

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

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

Gives clear usage context including a cost figure and points the agent to list_einstein_capabilities for free alternatives. It doesn't explicitly say when NOT to pick a given kind, but the paid-vs-free routing is concrete 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 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 declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered. The description adds only scope colour (which indicator families feed the result) and nothing about refresh cadence, data recency, or rate limits. With annotations doing the heavy lifting, a 3 is appropriate.

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 well-formed sentence with the purpose front-loaded and the differentiating clause attached via a dash. No filler, though the dash clause packs three concept families into one breath.

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 behavior, the description only needs to convey scope of purpose, which it does. The remaining gap is routing guidance versus the many analysis siblings, which is a minor omission for a no-parameter read tool.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. There is no input surface for the description to clarify.

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 subject (Bitcoin's cycle position) and the measurement basis (on-chain measures: realized-profit, holder-behaviour, valuation), which tells an agent this is distinct from price-based tools like get_market_sentiment or get_top_movers. It is clear, though it never explicitly names a sibling to contrast against.

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

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

The phrase 'rather than price alone' implicitly signals the condition for choosing this tool over price-only siblings, but there is no explicit when-to-use, when-not-to-use, or named alternative. Usage is implied rather than stated.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety and idempotency profile is covered without the description. The description adds a useful ordering guarantee ('newest first') and the disclosure-based nature of the data, but says nothing about disclosure lag, pagination limits beyond the schema, or data source, so with annotations carrying most of the load a 3 is appropriate.

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

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

A single front-loaded sentence with zero filler; the resource and its ordering constraint appear immediately. Nothing is repeated or redundant.

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

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

An output schema exists, so return values need not be described, and annotations cover the safety profile, making this sufficient for a zero-required-parameter read tool. The one remaining gap is the meaning of 'recently disclosed' (how far back the data reaches or how large the disclosure lag is), which the agent may want in order to interpret results.

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

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

Schema description coverage is 100% and the single 'limit' parameter is fully documented with its default and 1-25 range. The description adds no parameter detail beyond the schema, which matches the baseline of 3 when the schema does the heavy lifting.

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

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

The description names a specific resource (recently disclosed stock and asset transactions by US Congress members) and its ordering (newest first), which no sibling tool covers. It lacks an explicit action verb like 'list' or 'get', but the resource and scope are unambiguous enough to distinguish it from siblings like get_government_contracts or 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?

There is no statement of when to use this tool versus alternatives, no prerequisites, and no exclusions. 'Recently disclosed' implies a recency window but leaves the definition of 'recent' to inference, and nothing routes the agent between this and the 40+ other analytics tools.

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

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

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, idempotentHint, non-destructive, and closed-world semantics, so the safety profile is covered. The description adds scoping context ('recent notable'), but leaves undefined what makes an award 'notable' or how results are ordered.

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 efficient sentence that front-loads the resource and its scope before the use case. No wasted words, though it is brief enough to leave some behavioral questions open.

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 values need not be explained, and the single parameter is fully covered. Annotations carry the safety profile, so the description is nearly complete, only missing a note on what 'notable' and ordering mean.

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

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

Schema coverage is 100% and the single limit parameter is fully documented in the schema, so the description need not compensate. It adds no additional meaning beyond the schema, which is the baseline expectation at full coverage.

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

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

The description states a specific verb and resource ('US federal contract awards') with a clear qualifier ('recent notable'), and clarifies the practical use case of tracking public companies winning government money. It is distinguishable from financial siblings, though it doesn't explicitly contrast with the nearest sibling, get_congress_trades.

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

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

Usage is implied through 'useful for tracking which public companies are winning government money,' giving a clear context, but there is no explicit when-to-use/when-not guidance or named alternatives among the many sibling tools.

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

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

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 declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds a genuinely useful behavioral fact: this is a single aggregate read that consolidates four separate sources ("multi-source ... in one read"), telling the agent it need not make four calls. Missing only freshness/coverage caveats.

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 substance (what is aggregated), then the use case. No filler, no restating of the tool name or title.

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

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

An output schema exists, so return-value shape need not be explained, and the zero-param schema is trivially complete. The description covers scope and use case; only the data's source frequency/staleness is unaddressed, which is minor for a sentiment read.

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

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

The tool takes zero parameters, so there is nothing to document; baseline 4 applies. No misleading parameter hints are present.

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 (market sentiment) and enumerates exactly which indices are aggregated: crypto Fear & Greed, CoinMarketCap's variant, CNN traditional-market Fear & Greed, and Altcoin Season. That enumeration distinguishes it cleanly from data-pull siblings like get_social_hype or scan_market without the agent needing to open a schema.

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

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

Gives a concrete triggering situation — "how is the market feeling" questions — which is clear usage context. It stops short of naming an alternative tool or stating exclusions, so it is context without explicit routing.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true and a closed-world scope, so safety behavior is covered. The description adds useful context that rows come from the insider-detection scan and defines the whale criterion as large AND unusually early, but says nothing about pagination, caching, or result recency.

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 compact sentence with no filler, and the key qualifiers (large, unusually early, Polymarket, insider-detection source) are front-loaded rather than buried.

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

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

An output schema exists, so return values need not be explained. The description covers source, scope and selection criterion for a simple one-parameter read tool; only the routing to sibling prediction-market tools is under-specified.

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

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

Schema description coverage is 100% and the single `limit` parameter is fully documented in the schema with its range and default. The description adds no parameter meaning beyond that, so the baseline 3 applies.

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

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

The description states a specific resource (large and unusually-early positions on Polymarket prediction markets) and scopes it to the insider-detection scan, which separates it from venue siblings like get_hyperliquid_whales and get_robinhood_whale_prints. It lacks an explicit verb, reading as a noun phrase rather than 'returns X', so it is clear but not maximally crisp.

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 venue (Polymarket) and the signal type (whale/early positions) imply when to reach for this tool, but there is no explicit when-to-use versus analyze_prediction_markets, get_prediction_market_catalysts, or track_whales, and no stated prerequisites or exclusions.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), so the description does not need to restate them. It adds useful sourcing and filtering context (Polymarket, dated/upcoming, odds-moving) but says nothing about ordering, freshness, or how 'moving' is quantified.

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

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

A single front-loaded sentence that conveys resource, source, and selection criterion with zero waste. Nothing to trim.

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?

An output schema exists, so return-shape details are not needed in the description, and read-only annotations carry the safety profile. The description is sufficient for a simple one-param read tool, missing only explicit sibling routing.

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 single 'limit' parameter is fully documented in the schema (100% coverage), so the schema does the heavy lifting. The description adds no meaning about the parameter or default behavior, so the baseline 3 for high-coverage schemas 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?

Names the resource and scope precisely — 'upcoming dated events on Polymarket whose odds are moving' — so an agent knows it returns moving-odds catalyst events rather than raw market lists or yields. It is clear but does not explicitly distinguish itself from close siblings like analyze_prediction_markets 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 phrase 'most likely to move crypto or macro narratives next' implies when the tool is useful (narrative/theme radar), which is helpful framing. However, it offers no explicit when-to-use vs when-not or named alternatives, leaving selection between the three prediction-market siblings 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 declare readOnlyHint/idempotentHint/destructiveHint=false and a closed-world scope, so the safety profile is covered. The description still adds real behavioral context beyond that: 4-hour pre-computation cadence, cache-only return semantics (no new inference), and the fact that the response reports model agreement plus direction/drift per model.

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

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

Two dense sentences with no filler: the first front-loads what the tool produces and for which assets, the second immediately follows with the caching/freshness constraint. Nothing is repeated or padded.

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

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

An output schema exists, so return-value structure need not be explained, and annotations cover the safety/idempotency profile. What remains — which assets, which models, freshness cadence, and cache-only behavior — is all present, leaving no gap an agent would need to guess at.

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

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

Schema coverage is 100%, with enums and per-parameter descriptions already specifying the asset universe, the free-tier restriction, and the look-ahead horizon for each interval. The description only restates the asset list, adding no syntax or format meaning beyond the schema, so the baseline 3 applies.

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

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

States a specific verb+resource (dual-model ML price forecast) and names the exact asset universe (BTC, ETH, SOL, BNB) plus the models used (TimesFM 3.0 + Kronos). This clearly separates it from siblings like forecast_chart and get_forecast_accuracy, which address chart rendering and historical accuracy rather than the forecast 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 informs the agent that results are pre-computed every 4 hours and that the call returns the cached run rather than triggering new inference, which implicitly frames when it is cheap/safe to call. However, it never explicitly says when to prefer this over forecast_chart, get_forecast_accuracy, or ask_einstein, so the routing decision is left to inference.

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

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

Annotations already cover the safety profile (read-only, idempotent, non-destructive), and the description adds substantive context beyond them: each print is valued via its USDG or ETH leg and cross-checked, trades priced off freshly-created pools are excluded, and WETH/USDG FX swaps are counted separately instead of dominating the tape. This tells the agent exactly why the numbers are trustworthy and what is filtered out.

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 resource definition followed by the valuation/filtering rules. Every clause adds information; 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 and full annotations present, the description carries only what structured fields can't: the instrument universe and the valuation methodology. It omits the observation window (over what period 'prints' are collected) and whether rows are ranked by USD value, which an agent would want before calling.

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

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

The single parameter (limit, 1-25, default 10) is fully documented in the schema at 100% coverage, so the baseline is 3. The description adds nothing about the limit or about the ordering of rows, so it does not improve on the schema.

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

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

States a specific verb+resource — individual large DEX trades on Robinhood Chain (EVM 4663) — and names the exact asset classes covered (NVDA/SPY/HIMS tokenized equities, Pons memecoins). The chain ID and asset scope make it immediately separable from siblings 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?

Usage is only implied: an agent can infer you call this when you want whale flow on Robinhood Chain, but the description never says when to choose it over track_whales or get_hyperliquid_whales, nor any precondition. The data-quality exclusions describe output composition, not when-to-use.

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, openWorldHint=false, and destructiveHint=false, so safety and mutability are covered. The description adds useful scope by specifying the tracked cohort and recency, but it does not explain return behavior, pagination, or freshness beyond what the output schema and 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?

The description is a single front-loaded sentence with no filler. It quickly communicates the core data scope and then names the source cohort, making efficient use of limited space.

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?

Because an output schema exists and the input schema is fully documented, return values and parameter usage do not need to be explained. However, for tool selection among a large sibling set, the description is incomplete: it does not differentiate from get_smart_money_inflow or clarify when this flow-oriented view should be chosen over related whale and inflow tools.

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

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

There is one optional parameter, limit, with 100% schema description coverage already documenting its 1-25 range and default. The description adds no further meaning about the parameter, so the baseline of 3 applies.

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

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

The description clearly identifies the data resource: recent capital rotation by profitable on-chain wallets from a tracked smart-money cohort. It is more specific than a tautology, but it never states an action verb and does not distinguish this tool from the very similarly named 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?

There is no explicit guidance on when to use this tool versus alternatives. The description gives no conditions, prerequisites, or exclusions, and it does not route the agent between this tool and get_smart_money_inflow or other whale-tracking tools.

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

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

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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds two useful behavioral facts beyond the annotations: the universe is limited to major-cap assets and the data comes from a refreshed snapshot. It still says nothing about ranking methodology or pagination/ordering, so this is only modest added value.

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

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

A single front-loaded sentence with no filler or repetition of the title. It is efficient, though the trailing appositive 'gainers or losers, from a refreshed market snapshot' reads slightly loose rather than crisply structured.

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

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

With an output schema present, the description need not explain return values, and annotations carry the safety profile. Universe scope, time window, and snapshot freshness are covered; only the definition of 'major-cap' and the ranking basis are left implicit, which is a minor gap for a two-parameter read tool.

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

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

Schema description coverage is 100% with both `side` and `limit` documented inline, including the 1-25 range, so the schema does the heavy lifting. The description's 'gainers or losers' merely restates the `side` enum without adding format or edge-case meaning, which is the expected baseline when 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 names a specific resource and scope: 'the largest 24h movers across the major-cap crypto universe', with the gainers/losers dimension stated explicitly. It is clear what the tool returns, but it does not distinguish itself from sibling ranking tools such as scan_market or get_market_sentiment, so an agent must infer the boundary.

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

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

There is no explicit when-to-use guidance, no exclusions, and no named alternative among the many sibling analysis tools. The phrase 'from a refreshed market snapshot' hints at a cached-snapshot context but does not tell the agent when this tool is the right choice over scan_market or the analyze_* family.

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 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 already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description's job is to add context — and it does: it discloses that permissions are decoded from the hook address and therefore describe capability, not intent, and warns that most delta-taking hooks are ordinary launchpads. It also surfaces the paid nature ($0.25/call). It does not detail rate limits or provenance freshness, keeping it at 4.

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

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

Front-loaded with the verb and scope, then layered with interpretive caveats and pricing. Most sentences earn their place, though the parenthetical about Robinhood Chain's volume share is more promotional context than operational guidance and slightly dilutes the density.

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. It covers scope, chain coverage, the interpretive caveat around decoded permissions, cost, and where free alternatives live — everything an agent needs to decide and invoke correctly.

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

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

There is one optional parameter at 100% schema description coverage, with the enum-to-chain mapping already documented in the schema. The description restates the chain IDs and the 'omit for all four' default, adding essentially no syntax or constraint detail beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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

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

The verb 'Census' plus the specific resource 'Uniswap v4 hook layer' on four named chains is unambiguous, and the description enumerates the concrete dimensions returned (top pool-creating hooks, decoded permissions, proxy upgradeability, uncatalogued hooks). An agent can distinguish this from siblings like scan_launchpads or inspect_onchain without opening a schema.

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

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

It gives clear context for when the tool is relevant (hook-level analysis on those four chains) and explicitly names an alternative path for free coverage via list_einstein_capabilities. It stops short of stating explicit when-not-to-use conditions or contrasting with the nearest siblings (scan_launchpads, get_launchpad_radar), so it lands at 4 rather than 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?

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.