Agent Einstein — Crypto & Market Intelligence

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds valuable pricing context ($0.25–$0.85 per call, charged to Einstein credit balance), which is critical cost information beyond annotation coverage. It does not mention rate limits or response details, but the added context is significant.

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

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

The description is two sentences: the first fronts the main purpose with a concise list of domains, the second covers cost and alternatives. No filler or redundant information; every sentence earns its place.

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

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

Given only two simple parameters and strong annotations, the description covers the essential context: purpose, cost, and alternative tools. It does not explain return value shapes, but with no output schema and a broad multi-domain tool, this is a minor gap rather than a critical deficiency.

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

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

Schema description coverage is 100% for both parameters. The description enriches the enum semantics by linking 'onchain' to 'network and mining health' and 'staking' to 'Babylon staking', which goes beyond the bare enum labels in the schema. This added meaning compensates for the schema's minimal enum 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 the tool provides Bitcoin-native analysis across six specific domains (mempool, onchain, BRC-20, Runes, bridges, staking). This distinguishes it from sibling analyze_* tools like analyze_copy_trading or analyze_token_security, which target different assets or markets.

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

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

The description explicitly points the agent to list_einstein_capabilities for free alternatives, making it clear when to consider an alternative. However, it does not provide a per-domain mapping of which free alternatives apply to which analysis type, so it is not 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 readOnly, idempotent, openWorld, and non-destructive. The description adds critical context: this is a paid tool costing $0.85-$1.00 per call from Einstein credit, and which modes produce what kind of output (leaderboard list vs intel analysis). This goes beyond annotations meaningfully.

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

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

The description is two sentences with no wasted words. The primary purpose is front-loaded, and the pricing/alternative note is neatly bracketed. It efficiently communicates both modes and 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?

The description covers both operational modes, pricing, and free-alternative guidance. With no output schema, it gives a sufficient high-level sense of what is returned (ranked list, intel on edge/consistency/risk), though it does not detail exact fields or ranking criteria.

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

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

Schema coverage is 100%, so the baseline is 3. The description enriches the meaning of the `kind` parameter by specifying that leaderboard returns 'profitable wallets worth following' and intel provides a 'deeper intelligence read' on edge, consistency and risk—details not present in the schema's enum description.

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

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

The description clearly states two distinct functions: a 'ranked leaderboard of profitable wallets worth following' and a 'deeper intelligence read on a specific trader’s edge, consistency and risk'. It uses specific resource terms and distinguishes the tool's scope (copy trading) from siblings.

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

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

The description implies usage scenarios via the two modes (leaderboard vs intel) and mentions 'Free alternatives exist... see list_einstein_capabilities', but it does not explicitly state when to prefer this tool over alternatives or provide exclusions. Context is present but not fully directive.

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, so the safety profile is clear. The description adds valuable behavioral context about cost and payment ('Paid: $0.50–$1.50 per call from your Einstein credit balance') and the availability of free alternatives. It doesn't go into rate limits or response format, but with strong annotations this is sufficient.

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, information-dense sentence that front-loads the primary purpose ('Polymarket analysis') and then lists the five analysis modes. The payment note is bracketed and separate, keeping the main description clean. No redundant wording or fluff.

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

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

The description covers the core functionality, cost, and alternatives, which is strong for a complex tool with no output schema. However, it does not specify what the response looks like (e.g., a summary report, data table, or narrative insights) or any pagination/format details for the results. Given the tool's multiple modes, a brief note on output type would make it fully complete, but the current description is still 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?

The schema provides basic descriptions for 'kind' (enum values listed) and 'limit'/'query' with ranges. However, the tool description enriches the enum semantics by explaining what each kind does (e.g., 'scan for insider-shaped positions' corresponds to 'insiders', 'measure bid/ask spreads' to 'spread'). This adds meaning beyond the bare enum list, compensating for the schema's nominal 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 the tool performs Polymarket analysis and enumerates five specific actions ('browse live markets, scan for insider-shaped positions, measure bid/ask spreads, find high-conviction positioning, or fade over-priced long shots'). These map directly to the 'kind' parameter, distinguishing it from more specialized sibling tools like get_prediction_market_catalysts or get_polymarket_whales by its multi-purpose analysis capability.

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 includes cost and alternative guidance: 'Paid: $0.50–$1.50 per call from your Einstein credit balance. Free alternatives exist for several of these — see list_einstein_capabilities.' This tells the agent when to use this tool (when the user is willing to pay) and directs to a sibling tool for free alternatives. It also implies usage per analysis type, e.g., if the user asks for bid/ask spreads, this is the appropriate tool.

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

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

Annotations already establish the tool as read-only, idempotent, and non-destructive, so the description's main behavioral addition is the paid-call warning and the existence of free alternatives. That is meaningful context beyond the annotations, though the description still omits output shape or pagination behavior.

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

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

The description is information-dense and every clause adds some domain detail, but it is not front-loaded with a clear 'this tool does X' statement and relies on jargon-heavy parentheticals. It is acceptable in length but could be restructured for faster agent comprehension.

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 domain, cost, and several board semantics, and the schema fully documents parameters. However, there is no output schema and the description does not describe what a response looks like, which is a notable gap for a multi-board paid tool.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds interpretive depth to the board enum values: 'whose on-chain stock float is locked in one pool' clarifies float-corner, and 'stock-paired launches with their tax and dividend structure' enriches stock-pairs. It does not explicitly name board or token parameters, but the schema already handles those mechanically.

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

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

The description identifies a concrete domain ('memecoins are priced in SHARES, on Base and Robinhood Chain') and enumerates the specific intelligence categories it covers: float-corner risk, stock-paired launches, early buyers, and trader records. This makes the tool distinguishable from sibling analysis tools by domain, though it lacks an explicit action verb such as 'Analyzes' or 'Returns' and does not directly contrast itself with other analyze_* 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 paid note ('$0.25 per call from your Einstein credit balance') and pointer to free alternatives via list_einstein_capabilities give concrete cost-based usage context. However, it never states specific conditions for choosing this tool over sibling tools like analyze_token_security or when not to use it, leaving selection mostly 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 readOnly, idempotent, and non-destructive behavior. The description adds valuable context: it is a 'live' analysis (results may change) and explicitly discloses the cost range ($0.35–$2.00 per call) from the Einstein credit balance, which is critical for agent decision-making. It also notes that free alternatives exist, adding cost-awareness beyond 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 the core purpose front-loaded and the cost note appended. Every word earns its place, and the structure is clear and scannable. No redundancy.

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

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

The description covers the purpose, analysis types, and cost, but does not indicate what the output looks like (e.g., a risk score, report, or list of findings). Given there is no output schema and the tool is paid, the agent would benefit from knowing what to expect in the response. Overall adequate but with a clear gap in return-value description.

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 parameters especially for `kind` and `chain`. The description only adds the direction to choose the analysis with `kind`, which is already evident from the schema. Since the schema documents parameters thoroughly, the description adds minimal extra meaning, so the baseline 3 is appropriate.

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

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

The description clearly states it performs 'live security analysis of a token contract' and enumerates specific analysis kinds (rug-pull, holders, sniping, approvals, contract audit). This specific verb+resource combination, along with the distinct analysis types, distinguishes it from broader scan tools like check_token_safety.

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

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

It instructs the agent to choose the analysis with `kind` and mentions free alternatives via list_einstein_capabilities, but it does not explicitly specify when to use this tool versus related siblings like check_token_safety or when to avoid it. The usage context 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, openWorldHint, idempotentHint, and destructiveHint=false. The description adds valuable non-obvious behavior: it is a paid call with a price range ($0.25–$1.00) deducted from Einstein credit balance, and that free alternatives exist. This cost-related context is beyond what annotations provide, though it does not detail response format or error 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?

Two sentences: the first front-loads the primary purpose and lists the analysis categories, the second handles cost and alternatives. No filler or redundancy—every word contributes to tool understanding.

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 multi-kind, multi-chain analyzer with no output schema, the description effectively covers purpose, all kind semantics, cost, and pointers to alternatives. It lacks explicit mention of return format or chain-specific limitations, but given the schema richness and annotations, the remaining gaps are minor.

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 enriches the 'kind' parameter by mapping enum values to plain-language meanings (e.g., 'realized/unrealized P&L' for pnl, 'forgotten or dust assets' for forgotten), helping an agent select the correct analysis type. It does not add much for chain or walletAddress, but schema already describes those adequately.

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 'Analyze any wallet address' and enumerates specific analysis types (holdings, P&L, trust score, forgotten assets, airdrops, quantum resistance). This distinguishes it from sibling tools like analyze_bitcoin or analyze_token_security, which target narrower subjects.

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 usage context by noting the cost and pointing to list_einstein_capabilities for free alternatives, which helps an agent decide whether to use this tool or seek cheaper options. However, it does not explicitly name specific sibling tools for when-not-to-use or provide exclusions for particular chain/kind combinations.

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, openWorld, idempotent, and non-destructive hints. The description adds crucial context beyond annotations: the paid nature ($1.00 per call from credit balance) and that results are grounded in live on-chain and market data. 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?

The description is three sentences: statement of purpose, return type, and cost/alternatives. Every sentence earns its place, front-loads the primary purpose, and avoids redundancy with annotations or schema.

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

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

For an open-ended analysis tool with no output schema, the description covers the key aspects: what it does, when to use, what it returns ('written analysis'), and cost. It could have included an example prompt but is otherwise complete for selection and invocation.

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

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

With schema description coverage at 100% and only one parameter (`prompt`) described as 'The question or analysis request, in plain language', the baseline is 3. The description adds usage context but does not enrich the parameter semantics beyond the schema's own description.

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

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

The description clearly states 'Open-ended crypto and DeFi analysis from Einstein's full research stack' with a specific verb (analysis) and resource (research stack). It distinguishes itself from sibling tools by emphasizing 'open-ended' and 'spans several domains', making it a clear fallback for general questions.

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

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

Explicit usage guidance is provided: 'use this when no more specific tool fits, or when the question spans several domains.' It also points to free alternatives via 'see list_einstein_capabilities', giving clear direction on when not to use this tool.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds meaningful cost information ($0.50–$1.00 per call) and notes that free alternatives exist, which is beyond what annotations provide. This is consistent with the read-only nature and adds useful 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 concise: two sentences plus a bracketed billing note. It is front-loaded with the primary purpose and uses minimal words to convey the scope. Every part earns its place, with no redundant filler.

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

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

Given the tool's complexity (four assessment kinds), the description covers all modes and gives a billing caveat. It lacks explicit output/return details, but since there is no output schema and the annotations cover safety, the description is sufficiently complete for an agent to select and invoke it correctly. A slightly richer note on what each kind returns would push it to 5.

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. However, the description enriches parameter semantics by elaborating on the 'kind' enum values (e.g., 'organizational PQC readiness', 'migration plan', 'portfolio-level quantum risk', 'how close a CRQC actually is'), which the schema only lists as keywords. This adds meaning beyond the schema's terse 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 the tool assesses exposure to cryptographically-relevant quantum computing, listing four specific assessment types (readiness, migration, portfolio, crqc_benchmark). It uses a specific verb 'assess' and distinguishes from siblings like generate_quantum_key by focusing on risk assessment rather than key generation.

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 context on when to use the tool (for PQC readiness, migration, portfolio risk, or CRQC proximity) and explicitly mentions 'Free alternatives exist for several of these — see list_einstein_capabilities.' This gives clear usage context and points to an alternative, though it doesn't detail exact exclusions for each sibling.

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

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

Annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value by disclosing the cost per call and the dual-mode behavior (judge vs deep scan), which are not in the annotations. It also clarifies the scope (user-generated content and yield-vault listings). No contradictions 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?

The description is two sentences, with the core purpose in the first and essential cost/replacement guidance in the second. There is no fluff or redundant restating of the title. It is front-loaded with the action and resource, making it easy for an agent to quickly understand the tool's function.

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

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

The tool has only 2 parameters, both fully described in the schema, and no output schema to explain. Annotations cover side effects. The description fills the remaining gaps by explaining the tool's purpose, cost, and pointing to alternatives. It is complete enough for an agent to select and invoke it correctly, though it could briefly mention return format for each kind, but the schema already hints at that.

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

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

Schema description coverage is 100% — both 'kind' and 'content' are already fully described in the schema (e.g., enum values for 'judge', 'deep_scan', 'vaults' are explained). The tool description does not add significant new semantics beyond what the schema provides. Per the baseline, with high schema coverage, a score of 3 is appropriate.

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

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

The description clearly states the tool's function: 'AI moderation and integrity scanning for user-generated content and yield-vault listings — judges content quality and runs a deep integrity scan for manipulation.' It uses a specific verb ('judges', 'runs'), names the resource ('user-generated content', 'yield-vault listings'), and distinguishes from sibling tools by focusing on content integrity rather than market analysis or token safety.

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 practical usage guidance by noting that it's a paid service ($0.05–$1.00 per call) and that 'free alternatives exist for several of these — see list_einstein_capabilities.' This tells the agent when the tool might be worth using (for advanced integrity checks) and directs to an external list for cheaper alternatives. However, it does not explicitly name a 'use instead' sibling tool, so it's slightly less direct than a top-tier example.

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

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

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

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

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

Two tight sentences deliver the core purpose, data source, and the key comparison to the sibling tool. Every phrase earns its place, and the most decision-relevant information is front-loaded.

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

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

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

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

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

The schema already documents both parameters at 100% coverage, including the chain enum, default, and contract format. The description does not add parameter-specific meaning, so the baseline score of 3 is appropriate; no additional compensation is needed.

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

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

The description names a specific action ('honeypot / risk screen'), a clear resource ('EVM token contract'), and a specific data source ('cached GoPlus security dataset'). It also explicitly separates itself from analyze_token_security, so an agent can distinguish the two tools at a glance.

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

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

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

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context beyond that: it reveals the paid nature ($0.45–$0.60 per call) and the three operational modes. It does not contradict the annotations and provides useful cost/usage awareness.

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

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

Two sentences, front-loaded with the core purpose, followed by the cost note and pointer to alternatives. Every clause earns its place — no fluff, no repetition. The structure is ideal for quick AI parsing.

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

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

For a moderately complex tool with 3 modes, 4 parameters, and no output schema, the description covers the essential usage context: three distinct actions, chain/timeframe defaults via schema, and pricing. It does not describe return values, but the modes imply what the output will be. This is adequate given the schema's completeness.

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

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

Schema coverage is 100%, so the schema already documents all parameters. The description adds a little semantic flavor by explaining what 'mempool' and 'protection' modes do, which maps to the 'kind' parameter. However, it does not introduce any additional parameter-specific details beyond the schema, keeping the baseline at 3.

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

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

The description opens with a specific verb-resource pair ('Detect sandwich attacks and MEV extraction against a token or wallet'), then expands to cover the two additional modes (live mempool watch, protected routing recommendation). This clearly distinguishes it from sibling tools like analyze_token_security or check_token_safety, which focus on different security aspects.

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 when to use the tool for detecting historical MEV, watching the live mempool, or getting routing recommendations. It also points to free alternatives via list_einstein_capabilities, providing a clear exclusionary condition. It could be more explicit about when not to use it, but the context is sufficient.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, making the safety profile clear. The description adds valuable cost information ($0.60–$1.00 per call) and highlights that free alternatives exist, which the annotations do not convey. This extra context about cost and alternatives is useful beyond the structure.

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

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

The description is a single focused sentence followed by a brief cost note. It front-loads the core purpose and then presents important cost information without any fluff. Every word earns its place.

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

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

The tool is simple with 3 optional parameters and no output schema, so explaining return values is not critical. The description covers the main scope and cost. A minor gap is not mentioning the output format, but the name and description strongly imply a list of arbitrage opportunities.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds semantic richness by mapping the enum values to real-world arbitrage categories (DEX price dislocations, flash-loan-fundable routes, cross-chain spreads, prediction-market mispricings), which enhances understanding of the 'kind' parameter beyond the schema's terse enumeration. It does not add syntax details but provides meaningful context.

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

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

The description clearly states the tool scans for live arbitrage and enumerates four specific categories (DEX, flash-loan, cross-chain, prediction-market). This distinct resource and scope differentiate it from siblings like scan_market or find_yield. The verb 'scan' plus the explicit resource 'live arbitrage' is specific and unambiguous.

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

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

The description explicitly notes the tool is paid and directs users to list_einstein_capabilities for free alternatives, providing practical cost-based guidance. It implies usage for arbitrage scanning but does not contrast with specific sibling tools like detect_mev or find_yield, so it falls just short of the highest tier.

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 clear. The description adds valuable context about per-call cost ($0.10–$0.75) and that results are ranked by risk-adjusted return, which is behavioral information 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 with the core purpose front-loaded. The first sentence is a dense enumeration that could be more structured, but it avoids unnecessary words and efficiently conveys the tool's scope.

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 purpose, modes, cost, and ordering behavior, which is sufficient for a read-only tool with a well-defined schema. It does not specify the exact result fields, but no output schema exists, and the description's mention of 'ranked by risk-adjusted return' gives a reasonable hint of result nature.

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

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

The schema covers all three parameters with descriptions, providing a baseline of 3. The description adds semantic meaning to the 'kind' enum values (e.g., 'discover' as 'broad vault discovery sweep'), enriching the bare enum labels in the schema.

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

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

The description clearly states the tool's function with a specific verb ('Find') and resource ('yield'), enumerating four distinct modes: DeFi lending/LP opportunities, Pendle fixed-yield/YT-PT trades, vault discovery, and liquidations. This distinguishes it from siblings like find_arbitrage and 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?

It provides explicit guidance on cost and directs users to list_einstein_capabilities for free alternatives, effectively stating when not to use this tool. The four modes imply specific use cases, but it does not explicitly compare against all related yield 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 establish read-only/idempotent/non-destructive behavior, and the description adds meaningful extras: fresh inference instead of cached results, coverage beyond four assets, experimental status, no-investment-advice risk, and a $0.65 cost from credit balance. 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?

A single dense paragraph that front-loads the core function and then adds differentiators and cost/risk notes. Every clause carries information, though the bracketed payment/alternative note could be cleaner as a separate line or simplified.

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 paid, experimental tool with no output schema, it covers pricing, freshness, scope, risk, and alternatives. The main gap is that it never explicitly states the returned artifact (chart versus data) or output format, leaving the agent to infer from the name and title.

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 high, so the schema already explains chain and interval enums/defaults; the description only adds general 'any token / any supported chain' context. It does not clarify token format (symbol vs. address), but the baseline for high schema coverage is 3 and no extra parameter detail was required.

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

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

The description names a concrete operation—real-time data retrieval and compute bundled with a live price forecast—and specific models and outputs (TimesFM 3.0 + Kronos with quantile bands). It also explicitly contrasts itself with sibling get_price_forecast, so an agent can distinguish the tool 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 says when to choose this tool over the free get_price_forecast ('runs fresh inference and is not limited to four assets'), flags experimental/risk, and points to list_einstein_capabilities for free alternatives. This is explicit routing and exclusion 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?

It adds meaningful context beyond annotations: keys are returned once and never stored, and the cost per call is disclosed. This is valuable since annotations only flag read-only/destructive hints, which are false for this 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 two sentences plus a bracketed cost note, with no wasted words. It front-loads the core purpose and immediately provides key differentiators.

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 tool with no output schema, the description covers purpose, cost, storage behavior, and alternative options. It could specify the return format more precisely, but it is otherwise complete.

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

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

The schema already provides 100% coverage for the single 'kind' parameter, but the description enhances it with 'post-quantum' and 'hardware quantum randomness', giving more context than the schema alone. This adds value beyond the structured data.

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 generates keys using hardware quantum randomness and enumerates four specific key types (wallet, encryption, signing, random). This is a specific verb+resource pairing that distinguishes it from siblings like assess_quantum_risk.

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

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

The description explicitly notes that the tool is paid and directs users to list_einstein_capabilities for free alternatives, providing clear when-to-use guidance. It does not exhaustively explain all exclusions but gives a strong pointer.

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, so the description is not burdened with safety disclosure. It adds meaningful context: the $1.00 per-call cost and the fact that this is the exact briefing the engine reads internally, which helps the agent understand the nature of the response. 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?

The description is two sentences: the first delivers the core purpose with a clarifying analogy, the second efficiently provides pricing and alternative guidance. Every word earns its place, with no unnecessary detail or repetition.

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

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

For a zero-parameter, read-only tool with no output schema and rich annotations, the description fully covers what the tool does, the cost implication, and points to free alternatives. Nothing essential is missing, and the complexity is low.

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 zero parameters, and the baseline for 0 params is 4. The description correctly omits parameter details since none exist, and it does not need to compensate for schema gaps.

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

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

The description clearly states the tool returns 'Einstein's own current market context and operating state,' with the specific framing of 'the same situational briefing its autonomous engine reads.' This is a specific verb+resource combination and distinctly separates it from siblings that retrieve market data or other agent information.

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 notes that 'Free alternatives exist for several of these' and directs users to 'see list_einstein_capabilities,' providing a clear when-not-to-use and pointing to a specific alternative. It could be more explicit about exact scenarios for using this tool, but the context is sufficiently clear.

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

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

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

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

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

Three purposeful sentences front-load the core purpose, then add ranking philosophy and output caveats. No filler or redundancy.

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

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

The tool is simple: one optional parameter, no required fields, an output schema, and strong annotations. The description covers result interpretation, ranking methodology, and a key edge case (too-thin records), making it complete for correct invocation.

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

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

Input schema coverage is 100%: the only parameter, limit, is already documented with default and range. The description adds no parameter-specific detail, so the baseline 3 applies.

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

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

The description states a specific resource—'scored track record of public crypto commentators and influencers'—and a clear evaluation method: calls graded against actual outcomes. It also distinguishes itself from popularity-based tools by saying 'ranked by measured hit-rate, not follower count,' which separates it from sibling social/sentiment tools.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

A single sentence conveys the resource, scope, and ordering without extraneous words. Information is front-loaded and every element earns its place, making it easy for an agent to parse quickly.

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

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

For a simple, one-parameter read-only tool with full schema coverage, a rich annotations block, and an output schema, the description is complete. It communicates the essential result shape and ordering; nothing necessary for correct invocation is missing.

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

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

Schema description coverage is 100%: the single 'limit' parameter is fully documented with type, default, and range. The description does not mention parameters at all, but with complete schema coverage, the baseline of 3 is appropriate. No additional semantic burden is placed on the description.

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

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

The description clearly identifies the resource—recently disclosed stock and asset transactions by US Congress members—and specifies ordering as newest first. It lacks an explicit imperative verb like 'list' or 'retrieve,' but the intent is unmistakable and sufficiently distinguishes it from sibling tools focused on other data domains.

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

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

The description gives no guidance on when to use this tool versus alternatives such as get_government_contracts, get_market_sentiment, or get_trade_signals. There is no mention of use cases, exclusions, or contextual conditions, leaving the agent to infer applicability solely from the tool name and description.

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

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

Beyond the read-only/idempotent annotations, the description adds valuable behavioral context: results are out-of-sample, scored after the horizon elapses, and hit rates come from independent non-overlapping trials. This meaningfully shapes how an agent should interpret the data 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 compact and well-structured: it states what is measured, explains the methodology, and closes with the intended use case. Every sentence adds meaningful information, with the most important facts front-loaded.

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

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

With an output schema, fully documented optional parameters, and rich annotations, nothing essential is missing. The description adds methodology and use-case context, making it complete for an agent selecting and invoking this read-only lookup 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?

Input schema coverage is 100%, so the description is not required to re-explain 'asset' or 'limit.' The description reinforces that results are organized by asset and horizon, but adds no new parameter-level detail beyond what the schema already provides.

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

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

The description clearly identifies the tool as returning measured out-of-sample accuracy metrics for Einstein's forecasts, including MAPE and direction hit-rate per model, asset, and horizon. This makes its purpose concrete and separates it from sibling tools like get_price_forecast or get_analyst_accuracy.

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

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

The description states an explicit use case: 'Use this to decide how much weight to give a forecast.' It provides helpful interpretation guidance about independent trials and coin-flip comparability, but it does not mention alternatives or explicitly state when not to use this tool.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

For a low-complexity tool with one optional parameter and an output schema, the description covers everything needed to invoke it correctly: scope, the meaning of consensus, the NEUTRAL rule, and handling of unread accounts. Return structure can be left to the existing output schema.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The description is tightly structured: the first sentence states what the tool returns, the second covers supported launchpads, and the third gives the usage cue. Every sentence earns its place with no repetition or filler.

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

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

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

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

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

The input schema has 100% coverage for the single `limit` parameter, which is already described as 'Rows to return (1-15).' The description does not add parameter-level detail, so the baseline of 3 is appropriate.

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

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

The description clearly identifies the resource: tokens that just migrated off a bonding curve onto a DEX, with holder-distribution forensics and wash-trading tags. It distinguishes itself from siblings through its specific focus on migration, bundling forensics, and multi-launchpad coverage, though it lacks an explicit verb like 'list' or 'fetch.'

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The tool has zero parameters, so the schema trivially covers 100% of parameter semantics. Per the baseline for zero-parameter tools, a 4 is appropriate; no description-level parameter documentation is needed.

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

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

The description states a specific verb and resource: it reads multi-source market sentiment, and lists exactly four indices (crypto Fear & Greed, CoinMarketCap’s variant, CNN Fear & Greed, Altcoin Season index). This level of specificity clearly distinguishes it from sentiment-adjacent siblings like get_social_hype or scan_market.

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

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

The description explicitly states when to use the tool: 'Useful for framing any “how is the market feeling” question.' However, it does not name alternatives or state when not to use it, which keeps it just below a 5.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The description identifies a specific resource—large and unusually-early positions on Polymarket prediction markets—and adds provenance from the insider-detection scan, which helps distinguish it from sibling whale-tracking tools by platform. It lacks an explicit retrieval verb like 'list' or 'get,' but the tool name and title make the action clear.

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

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

The description implies usage for Polymarket whale data sourced from insider-detection scanning, but it does not explicitly state when to choose this tool over alternatives such as get_hyperliquid_whales or track_whales. No exclusions or routing conditions are provided.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The description clearly identifies the resource ('upcoming dated events on Polymarket') and the selection criterion ('odds are moving'), so an agent can tell what data the tool returns. It lacks an explicit verb like 'list' or 'return', but the meaning is unambiguous and distinct from sibling tools focused on yields, whales, or broad market analysis.

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

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

The description implies usage when an agent wants near-term, narrative-moving catalysts, but it does not explicitly state when to use this over siblings such as get_prediction_market_yields or analyze_prediction_markets. No exclusions or decision rules are provided.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The description implies this tool is for viewing prediction markets as a cash-like yield surface, so an agent could infer when to call it. However, it does not explicitly state when to prefer this over sibling tools such as analyze_prediction_markets or get_prediction_market_catalysts, nor does it name any exclusions.

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

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

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

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

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

Two tightly written sentences with no filler. The core purpose is first, followed by the model detail and the critical caching caveat. Every sentence contributes distinct value.

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

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

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

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

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

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

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

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

The description names a specific verb (get), resource (price forecast), and the exact assets covered (BTC, ETH, SOL, BNB). It also adds distinguishing content: dual-model ML, agreement between models, and direction/drift projections. This clearly differentiates it from accuracy or chart-related sibling forecast tools.

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

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

The description explains the tool's cached nature but provides no guidance on when to choose this over alternatives like get_forecast_accuracy or forecast_chart. It neither states conditions for use nor points to sibling tools for other purposes.

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

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

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

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

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

Three dense sentences front-load the core purpose and then add only high-value caveats about valuation, exclusions, and swap handling. No filler or redundant restatement.

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

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

With one optional parameter, an output schema, and read-only/idempotent annotations, the description thoroughly covers expected fields and important data-quality behavior. An agent has everything needed to invoke the tool correctly.

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

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

The only parameter, limit, is fully documented in the input schema with 100% coverage. The description adds no parameter-specific semantics, so the baseline of 3 is appropriate.

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

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

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

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

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

The description provides clear context by describing Robinhood Chain-specific data 'that no mainnet whale feed carries', implying when this tool is relevant. It does not explicitly name alternatives or state when-not-to-use it, so it falls just short of a 5.

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

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

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

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

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

The description is one sentence with no filler, and the core concepts of cohort and capital rotation are front-loaded. It is slightly fragmentary, but it is appropriately compact for a simple read-only tool.

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

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

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

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

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

The schema has a single parameter, limit, which is fully described with a default and range. The description does not mention limit, but with 100% schema description coverage, the schema carries the semantic burden, so the baseline 3 applies.

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

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

The description identifies the resource (profitable on-chain wallets in the tracked smart-money cohort) and the action (rotating capital), so an agent can infer this is a read about recent smart-money movement. However, it is phrased as a fragment rather than a clear verb statement, and it does not distinguish 'flow' from the sibling get_smart_money_inflow.

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

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

No guidance is given about when to choose this tool over alternatives such as get_smart_money_inflow or track_whales. The word 'recently' implies temporal context, but there are no explicit use cases, exclusions, or alternative comparisons.

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

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

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

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

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

Three sentences with no fluff: the first states what and how, the second adds an important interpretative caveat, and the third gives usage guidance. Each sentence earns its place and the main purpose is front-loaded.

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

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

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

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

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

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

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

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

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

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

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

The description includes an explicit usage trigger: 'Use when asked what smart money is buying or where informed flow is going.' This gives clear context for when the tool applies. It does not mention when-not-to-use or name alternatives, so it falls short of a full 5.

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

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

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

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

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

The description is concise and well-structured, front-loading the core function (ranking by social buzz) before detailing output and usage. No wasted words; every clause serves a purpose, making it easy for an agent to parse quickly.

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

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

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

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

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

Schema coverage is 100%, so both parameters are already described in the schema. The tool description reinforces the sentiment parameter by mentioning sentiment classification, but does not add new semantic meaning beyond what the schema provides. Baseline of 3 is appropriate.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Schema description coverage is 100%: both 'side' and 'limit' are documented in the schema with their defaults and constraints. The description does not need to add parameter meaning, and it mostly restates the 'gainers or losers' concept already captured by the enum.

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

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

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

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

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

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

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

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

Annotations already cover readOnly, idempotent, and non-destructive behavior. The description adds important traits beyond annotations: it is a paid call ($0.50 from credit balance) and returns current autonomous engine signals, which is useful cost and freshness 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 a single, information-dense sentence followed by a brief cost/alternatives note. It is front-loaded with the core purpose and contains no filler.

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

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

For a simple read-only tool with one optional parameter, comprehensive annotations, and no output schema, the description provides sufficient context: what the signals are, what they include, and the cost. No gaps in usage context.

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

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

Schema description coverage is 100%, including the 'limit' parameter with bounds (1-100). The tool description adds no additional meaning about the parameter, so the baseline of 3 is appropriate.

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

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

The description clearly states what the tool returns: Einstein's current live trade signals, including entry, stop, target levels, and reasoning. It also distinguishes from siblings by noting these are 'the setups its own autonomous engine is acting on' and references list_einstein_capabilities for free alternatives.

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

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

The tool is positioned as providing live, paid signals, with an explicit note that free alternatives exist and pointing to list_einstein_capabilities. This gives context on when to use it (paid, real-time) versus checking alternatives, though it doesn't name specific 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 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 establish read-only, idempotent, and non-destructive behavior. The description adds significant extra context: the paid nature ($0.50–$1.00 per call) and the existence of free alternatives. This goes beyond structured fields, though it does not reveal other behavioral details like response format or latency.

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

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

Two sentences, front-loaded with the core purpose, followed by specific sub-uses and pricing caveat. No fluff; every clause adds value.

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

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

The tool has a small parameter surface (2 params, no output schema). The description covers the tool's scope, cost, and relationship to alternatives. A minor gap is not explaining what the 'context' parameter should contain, but the default kind and open-ended context are adequately implied for an advisory tool.

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

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

Schema coverage is 100%, so baseline is 3. The description enriches the enum values by paraphrasing each kind ('portfolio risk allocation', 'how to split capital', 'strategy gate', 'meta-strategy read'), adding meaning beyond the bare schema listing. The context parameter remains vague, but the description compensates sufficiently.

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

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

The description clearly states the tool provides 'risk-aware allocation guidance' and enumerates specific use cases: portfolio risk allocation, capital splitting across strategies, strategy gate checks, and meta-strategy read. This distinguishes it from sibling analysis tools by focusing on allocation advice rather than raw 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?

Description gives concrete scenarios where the tool applies (gate check, meta-strategy, etc.) and explicitly notes that 'free alternatives exist for several of these' while directing to list_einstein_capabilities. This is clearer than most, but it does not provide case-by-case when-not guidance for each alternative.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable context beyond annotations: the paid per-call cost ($0.75–$2.00) and the fact that it runs on 'real historical data', which informs the user about data semantics. 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, first is packed with the core purpose and modes, second is a concise pricing/alternative note. Every word earns its place, no fluff or redundancy.

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

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

The description covers the main modes and pricing but omits two important contextual elements: there is no output schema, and the description does not mention what the backtest returns (e.g., performance metrics, equity curve). It also silently drops the 'engine' mode listed in the schema enum. For a paid, multi-mode tool, this leaves meaningful gaps.

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 meaning above the schema by explaining that 'strategy' can be a plain-language description or a template name, and by mapping the 'kind' values to the described modes (custom, standard, optimize). This enriches parameter understanding without duplicating schema text.

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 'Backtest a trading strategy on real historical data', a specific verb+resource pair that clearly distinguishes this tool from the analysis/forecast siblings. It further clarifies three distinct modes (plain-language custom backtest, standard template, parameter optimization), leaving no ambiguity about what the tool does.

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 tells users when to use the tool ('describe rules in plain language', 'run a standard strategy template', 'optimize parameters') and when not to ('Free alternatives exist for several of these — see list_einstein_capabilities'). This provides both inclusion and exclusion criteria, plus a pointer to alternative tools.

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

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

Annotations already cover read-only, idempotent, and non-destructive traits. The description adds valuable cost context ($0.25–$0.40 per call) and notes free alternatives, but doesn't disclose return format or pagination behavior. This adds some context beyond annotations but not rich 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 two concise sentences. The first front-loads the purpose, and the second adds a critical cost caveat. No wasted words.

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

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

Complexity is low with 3 optional params and no output schema. The description covers the core function and cost, and annotations cover safety. It could mention what a result contains but is complete enough for a simple scanner 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 covers 100% of parameters, providing a baseline of 3. The description enriches the venue parameter by mapping Pump.fun to Solana, Zora to Base, and mentioning the Robinhood Chain catalog, adding meaning not present in the schema.

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

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

The description clearly states the tool scans for new and trending token launches on specific venues (Pump.fun, Zora, Robinhood Chain). It specifies the resource and action but doesn't explicitly differentiate from siblings like scan_market, though the venue list provides implicit distinction.

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

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

The description provides no explicit when-to-use guidance or exclusions. It mentions free alternatives for some venues but doesn't clarify when to prefer this tool over siblings. Usage is only implied by the tool name and venue list.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, but the description adds valuable behavioral insights: the per-call cost range ($0.25–$0.60) and the existence of free alternatives. These go beyond the structured annotations, though the description doesn't detail return formats or error behaviors, which is acceptable given the strong annotation coverage.

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

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

The description is two concise sentences: the first lists all capabilities, the second provides cost and alternative guidance. It is front-loaded, zero-waste, and every piece of information earns its place.

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

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

Given the tool's complexity (five optional parameters, six modes, no output schema) and strong annotations, the description sufficiently covers purpose, cost, and alternatives. It does not describe return shapes, but that is acceptable since the schema and sibling tool context already provide adequate guidance for a user to invoke the tool correctly.

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

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

Schema description coverage is 100%, with each parameter well-documented in the schema itself. The description adds no new parameter-level semantics beyond relabeling alpha_ranked as 'alpha-ranked gainers with quality filters' and clarifying regime, but the schema already covers these meanings. Baseline 3 is appropriate because 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 clearly identifies the tool as a scanner for live market data and enumerates six distinct scan types (top gainers, movers, alpha-ranked gainers, altseason, technicals, regime). This specificity distinguishes it from sibling tools like get_top_movers by covering multiple use cases in one call.

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

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

The description tells users this is a paid tool and points them to list_einstein_capabilities for free alternatives, offering context on when to avoid this tool. It does not explicitly name which alternatives correspond to which scan types, leaving a slight gap in direct comparisons, but still provides clear cost-related 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?

Beyond the readOnly/idempotent annotations, the description discloses the cost model ($0.25 per call from Einstein credit balance) and provides an important interpretive caveat: permissions are decoded from the address and describe capability, not intent, with most delta-taking hooks being ordinary launchpads. This materially prevents misuse or misinterpretation 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 dense but every sentence earns its place: scope and outputs, interpretation guidance, market context, and cost/alternatives. The action verb is front-loaded, and the prose avoids fluff while conveying substantial detail.

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

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

With no output schema, the description usefully summarizes what the tool returns: pool-creating hooks, permission capabilities, proxy status, and catalog coverage. It also covers chain selection, cost, and the caveat about permission semantics; minor details like pagination or result limits are not addressed, but nothing essential for selecting and invoking the tool 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 schema already provides 100% coverage for the single optional chainId parameter, including enums and an 'Omit for both' note. The description adds no new parameter-level meaning beyond naming the chains, so a baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('Census') and names an exact resource (Uniswap v4 hook layer on Robinhood Chain and Base), while enumerating concrete output categories: pool creation, hook permissions, upgradeable proxies, and uncatalogued hooks. This clearly distinguishes the tool from broad siblings like scan_launchpads or get_launchpad_radar.

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 identifies a clear use case: a paid census of Uniswap v4 hooks with permission decoding, and explicitly directs the agent to list_einstein_capabilities for free alternatives. However, it stops short of specifying precise conditions for when the paid tool should be preferred over those alternatives, making the guidance strong but not fully exclusionary.

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 false. The description adds valuable behavioral context by disclosing the cost per call ($0.45–$0.50) and mentioning that free alternatives exist, which is beyond what 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 total, with the paid notice in brackets. It is front-loaded with the core offering and includes a practical pointer to free alternatives. No filler or redundant 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?

Given the read-only annotations and fully documented schema, the description provides sufficient context about the three data types and the paid nature. It doesn't describe the return format, but for a list-oriented data tool with no output schema, this is not a major gap and is adequately covered by the setting.

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

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

The schema covers 100% of parameter descriptions with enums fully documented, so the baseline is 3. The description adds some semantic flavor (e.g., 'accumulation', 'profitable-wallet cohort') but doesn't significantly go beyond the schema's own enum explanations.

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 function: providing live intelligence on large capital across three specific venues (on-chain transfers/accumulation, Hyperliquid perp positioning, smart-money cohort). It uses specific resource nouns and distinguishes itself from sibling tools by naming its three data categories and pointing to free alternatives.

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

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

The description gives clear context on when to use this tool (when live, paid intelligence is needed) and explicitly directs users to list_einstein_capabilities for free alternatives. However, it doesn't name specific sibling tools or state when not to use it beyond the free-alternative suggestion.

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