Crank Protocol

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

Annotations (destructiveHint: true, readOnlyHint: false) are expanded with details: funds are locked into escrow, instructions are returned as unsigned transactions, claim codes and transaction indices are provided, and anti-abuse limits apply. The description adds value beyond annotations without contradiction.

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-structured with paragraphs and inline code formatting. It front-loads the main purpose and uses bullet-like lists. Some redundancy exists (e.g., 'ENG-bfeacb2c' and 'ENG-ac7961aa' prefixes), but overall it's informative and organized.

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

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

Given the tool's complexity (7 params, batch operations, transactions), the description covers key aspects: behavior, idempotency, anti-abuse, and output details. The output schema exists, so return values are presumably documented. Missing explanation for 'referral' and 'caller_id' slightly reduces completeness.

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

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

The input schema has 0% coverage, so the description must compensate. It explains 'recipients' (list of dicts with fields), 'token' (mint), 'sender_wallet', and 'idempotency_key' with format hints. However, 'referral' and 'caller_id' are not explained, leaving gaps. Baseline 3 is appropriate given partial 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's purpose: 'Distribute one token to many X handles in one call (non-custodial)'. It specifies the verb (distribute), resource (token to X handles), and scope (batch). This distinguishes it from sibling tools like send_token_social or perp-related 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 indicates when to use: for distributing one token to multiple recipients in a single call. It explains batching of unsigned transactions, idempotency for retries, and anti-abuse gating. While it doesn't explicitly mention alternatives, the context of siblings like send_token_social implies single-send use cases.

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

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

Annotations already declare readOnly, idempotent, non-destructive. Description adds 'Never exposes the claim-code secret' and details return fields. The 'FREE read' note is extra but not behavioral.

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?

Very concise: two sentences and a list of return fields. Front-loaded with purpose. Every sentence 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?

Given the output schema exists and annotations are rich, the description covers the main lookup and return aspects. Missing explanation for caller_id is the only gap.

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

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

Description explains claim_id, recipient, and sender_wallet semantics beyond the schema, but completely omits caller_id. With 0% schema coverage, the gap for one parameter is notable.

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

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

Clearly states 'Sender-facing claim status of a social send' with specific verb and resource. Distinguishes lookup by claim_id or recipient, which differentiates from sibling 'claim_status' that may be more generic.

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

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

Provides guidance on when to use each parameter (look up by claim_id OR recipient, optionally scope by sender_wallet). However, lacks explicit 'when not to use' or alternatives among siblings.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds that the tool returns specific fields, but does not disclose additional behavioral traits 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?

The description is a single sentence that directly states the tool's purpose. It is concise and front-loaded, but could be expanded to include parameter guidance without becoming verbose.

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

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

Although an output schema exists, the description omits parameter semantics, which is a significant gap given the 0% schema coverage. The tool is read-only, but incomplete documentation hinders 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?

With 0% schema description coverage, the description should explain parameters. It mentions output fields but does not describe the 'code' or 'caller_id' parameters, leaving their meaning and usage opaque.

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 retrieves public status of a crank.ing claim code, listing specific fields (status, amount, claimable, expiry). However, it does not differentiate from the sibling tool 'check_claim_status', which likely serves a similar purpose.

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

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

No guidance is provided on when to use this tool versus alternatives. The mention of 'public status' implies usage but no exclusions or comparisons with siblings such as 'check_claim_status'.

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

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

The description adds significant context beyond annotations: it records attribution, mentions a 15% fee share for the template author, and notes cloning is free. These side effects are not covered by annotations, providing transparency for the agent.

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

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

The description is brief (3 sentences) and front-loaded with the main action. Structure is logical but could be slightly improved with bullets for parameter hints.

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

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

Covers purpose, output usage, and side effects, but lacks parameter explanations. Given 0% schema coverage and many siblings, parameter details are needed for full 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 0% and the description does not explain any parameters (template_id, wallet_address, caller_id). Users must infer their meaning from context, which is insufficient for correct invocation.

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

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

The description clearly states the tool clones a published strategy config to a wallet, returning a config_template for use with strategy create tools. It distinguishes from siblings by specifying the output is a preparatory template, not a direct creation or modification.

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

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

The description indicates the tool is used before deploying via strategy create tools, but lacks explicit when-not-to-use or alternatives among many strategy siblings. The context is clear enough for typical usage.

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

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

Annotations (readOnlyHint, idempotentHint, destructiveHint) already indicate a safe, read-only operation. The description adds valuable behavioral context: it does not persist, is free per fee schedule, and returns both a normalized definition and a validation report. 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 concise: two sentences followed by a bullet list. It front-loads the core purpose and uses a clear, scannable format. Every sentence adds value, with no redundancy or filler.

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

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

Given the tool's complexity (validating composite definitions with multiple checks) and the existence of an output schema, the description covers the main aspects: purpose, non-persistence, fee implication, and validation rules. It could be more complete by hinting at the definition's structure, but overall it provides sufficient 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?

The sole parameter `definition` is an object with no schema descriptions (coverage 0%). The description does not elaborate on its expected structure, but it lists validation checks that imply required fields (schema, streams, risk caps). This provides partial compensation but not full parameter semantics.

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

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

The description clearly states the tool validates a composite definition and distinguishes it from creation or persistence tools. It uses specific verbs ('validate', 'returns') and identifies the resource ('composite definition'). Among siblings like `strategy_composite_create` and `publish_strategy`, its purpose is distinct.

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 when to use the tool: to validate a composite definition before creation or persistence. It lists specific checks (schema, stream existence, rule-tree limits, risk caps, anti-gaming rule) which guide the user on what the tool ensures. It does not explicitly state when not to use, but the validating nature is clear.

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

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

The description fully discloses that nothing executes until user approval, the tool never signs or sees keys, and that amount is in base units. It adds context beyond annotations (e.g., destructiveHint=true is about intent creation, not actual token movement).

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 but slightly lengthy. It front-loads the core purpose and uses paragraphs effectively. Could be more concise but no fluff.

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

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

Given the output schema exists, the description adequately covers the tool's lifecycle, return values, and follow-up steps. Missing details on parameters like idempotency_key and slippage_bps, but overall complete for the tool's complexity.

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

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

With 0% schema description coverage, the description only explains 'amount' (in base units). The other 7 parameters are not described, leaving the user to infer their meaning from names alone.

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 creates a propose-only execution intent and returns an approval URL. It distinguishes from siblings by emphasizing the non-custodial, unsigned nature and referencing polling via get_intent_status.

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 when to use this tool (to create a swap proposal without execution) and provides follow-up guidance to poll get_intent_status. However, it does not explicitly list alternatives or when not to use it.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds ranking by reputation and recency, and states 'free' and 'Read-only', which align with annotations. No contradictions.

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 short (two sentences) and front-loaded with purpose. It efficiently conveys key info but could better separate parameter details.

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

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

Given annotations, output schema, and the listing nature, the description covers essential aspects. However, it omits explanation of 'limit' and 'caller_id' parameters, which are not documented in the schema either.

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 0%. The description only explains the 'capability' parameter with allowed values. It does not mention 'limit' or 'caller_id', leaving their meaning unclear despite defaults.

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 'Find' and resource 'registered agents', clearly stating the tool's purpose. It notes optional filtering by capability, distinguishing it from related tools like discover_strategies.

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 you need to list agents, optionally filtered by capability. It lists valid capability values and ranking order, but does not explicitly state when not to use it or contrast with alternatives.

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

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

Annotations already provide safe read-only behavior, and the description adds useful context like 'Crypto-only' and 'free'. No contradiction exists.

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

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

Three concise sentences, front-loaded with the main purpose, followed by specific parameter details. 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?

Covers core functionality, parameter usage, and constraints like 'Crypto-only'. Output schema exists, so return values need no mention. Minor gaps like pagination are acceptable for a straightforward browse 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?

With 0% schema description coverage, the description crucially adds meaning: strategy_type filters to 16 types, sort enumerates possible values. More detail on limit or caller_id would be beneficial.

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

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

The description clearly states that the tool browses published strategies, specifies it's read-only and free, and provides specific details about filtering and sorting, which distinguishes it from sibling tools like strategy_list.

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

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

The description indicates the tool is for browsing published strategies in the crypto domain. It gives concrete filter and sort options but lacks explicit when-not or alternative tool guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, etc. The description adds minimal extra behavioral context beyond the status values. It does not disclose rate limits, authentication needs, or other behaviors 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?

Three sentences, front-loaded with purpose. Could remove the marketing sentence ('Highlights the structural advantage...') to be more concise, but overall efficient.

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

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

Given an output schema exists, description need not explain return values. However, it fails to document parameters or provide context on when to use this tool versus other market-related tools. Adequate for a simple status tool but incomplete.

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

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

Schema description coverage is 0%, and the description does not document the meaning or usage of the symbol or caller_id parameters. The description adds no value over the bare 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 returns NYSE session status and a 24/7-on-Solana availability flag, with specific status values (closed, pre_market, open, after_hours). This distinguishes it from sibling tools like equity_quote or equity_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 usage for checking market hours but does not provide explicit guidance on when to use this tool versus alternatives, nor does it state when not to use it. No comparison to siblings is given.

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

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

Annotations already cover readOnlyHint, openWorldHint, and destructiveHint. Description adds value with 'free' and explicitly mentions referral stats, which annotations do not. No contradiction.

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 sentence with 10 words, front-loaded with primary action. Every word adds value with no redundancy.

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

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

The description covers the tool's purpose and key behavioral traits, but misses parameter details. Output schema exists, so return values are handled, but parameter semantics are weak given low schema coverage.

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 0% and description adds no explanation for parameters (wallet_address, caller_id). The tool name implies wallet_address is the agent identifier, but caller_id is left undocumented.

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

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

Clearly states the tool reads an agent's published profile and referral stats. The verb 'Read' and specific resources distinguish it from siblings like discover_agents or get_balances.

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

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

Implied usage but no explicit when-to-use or when-not-to-use context. Lacks guidance compared to similar tools and doesn't differentiate from alternatives like discover_agents.

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?

Adds significant context beyond annotations: explains debouncing, filtering logic, episode structure, and limitations (ignores fees, slippage, transfer latency). No contradiction with annotations (readOnlyHint=true, idempotentHint=true, etc.).

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?

Concise yet informative: opens with a clear summary, then details filtering and episode contents, ends with workflow guidance. No redundant content; every sentence 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?

Given the output schema exists, description sufficiently explains data structure (episode fields) and context (debouncing, filtering). Provides complete understanding for using this read-only intelligence 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?

With 0% schema coverage, description explains core parameters (min_spread_bps, assets, window_hours) and their roles. The caller_id parameter is not mentioned but it's a common identification field. Overall compensates well for lack of schema 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 it retrieves 'persisted cross-venue discrepancy episodes' and distinguishes from sibling tool get_cross_exchange by noting it is 'Already-debounced' and part of 'INTELLIGENCE step' vs live read.

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

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

Explicitly states workflow positioning ('INTELLIGENCE step') and pairing recommendation with get_cross_exchange. Also warns it is 'never an execution instruction' and 'Not financial advice', setting clear boundaries.

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

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

Annotations already provide readOnlyHint, idempotentHint, etc. The description adds behavioral details: only returns ACTIVE, non-suppressed/non-expired insights; explains fields like k, epsilon_spend, crowding_index; and clarifies it is descriptive, not a recommendation. 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 well-structured: starts with purpose, lists filters, describes output fields, then gives workflow context. It is detailed but each sentence adds value. Could be slightly more concise, but overall effective.

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

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

Given the tool has 5 parameters and an output schema exists, the description is quite complete. It explains filters, output fields (including privacy metadata and staleness), and workflow. Does not need to detail return values as output schema is present.

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

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

Although schema coverage is 0%, the description explains the key parameters: asset, strategy_type, insight_type (with list of options), detail (concise/full). This adds meaning beyond the plain schema properties.

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 'Fleet-wide collective insights, historical performance data (free read)' and specifies filters. It differentiates from siblings by placing it in the 'INTELLIGENCE step' alongside get_market_briefing and get_consensus, clarifying its role before sizing or creating strategies.

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 a 'Workflow' section that explicitly states when to use this tool: as an intelligence step before sizing or creating strategies, alongside get_market_briefing/get_consensus. It implies usage context but does not explicitly state when not to use it.

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

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

The description discloses behavioral traits beyond annotations: it is a descriptive signal only (not a recommendation), explains the contrarian condition (high agreement flagged), and details billing behavior (PAYMENT_REQUIRED, billing field in response). This adds significant value given the already helpful annotations (readOnlyHint, idempotentHint).

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-structured and front-loaded with purpose. It is slightly verbose but each sentence adds value. Minor redundancy could be trimmed, but overall efficient for the complexity.

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

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

Given the output schema (existing), annotations, and sibling tool context, the description is comprehensive. It explains the output fields, workflow integration, billing, and provides sufficient context for an agent to use 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?

With 0% schema description coverage, the description compensates somewhat: it explains 'asset' and 'window_hours' (including default 24), and mentions 'payment_header' in billing context. However, 'caller_id' and 'wallet_address' are left unexplained, leaving 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's function: providing multi-source consensus and contrarian read for one asset. It specifies the output metrics (consensus_score, source breakdown, accuracy-weighted score) and distinguishes from siblings by focusing on consensus aggregation.

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 explicit guidance on when to use this tool (INTELLIGENCE step, pairing with get_market_briefing and get_source_accuracy) and mentions billing requirements. However, it does not explicitly state when not to use it or alternative tools for different contexts.

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

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

Annotations already indicate readOnly, idempotent, non-destructive. Description adds that it's 'Descriptive signal only, not a recommendation' and 'Not financial advice.' Also discloses PLATINUM-tier subscription/payment requirement, though the exact behavior when payment is missing is implied but not detailed.

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?

Description is front-loaded with purpose and tier, includes a workflow line. Some redundancy (PLATINUM mentioned twice) and line breaks, but overall efficient and well-structured.

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

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

Given 5 parameters (none required) and existing output schema, the description covers primary use case, billing context, and workflow role. Lacks details on the output structure or exact behavior when payment fails, but sufficient for agent selection.

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

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

Schema has 0% description coverage, so description must compensate. It explains 'window_hours' and 'asset' optionality, and implicitly covers 'payment_header' and 'wallet_address' via billing context, but 'caller_id' is entirely unexplained. Adds moderate meaning beyond schema names.

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

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

Clearly states the tool scans intelligence signals for crowded (contrarian) and uncertain assets, with specific mention of the PLATINUM tier and billing. Differentiates from sibling signal tools by focusing on contrarian conditions and uncertainty.

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

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

Explicitly places it in the 'INTELLIGENCE step' workflow, surfacing crowded trades to fade or uncertain assets to avoid before committing to a regime/allocation. Lacks explicit when-not-to-use or alternative tool references, but context is clear.

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

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

Annotations already provide readOnly, idempotent hints. The description adds context about scoring from on-platform activity and circular funding flagging, going 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?

Description is well-structured and informative, though slightly lengthy; it front-loads the purpose and provides details without unnecessary repetition.

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

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

Given an output schema exists, the description explains return values well, but lacks error case or parameter semantics; adequate but not fully complete.

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

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

Schema coverage is 0%, and the description fails to explain the caller_id parameter or provide details on wallet_address beyond its name.

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

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

The description clearly states it is for a wallet's Crank Score reputation breakdown, listing specific components and distinguishing it from sibling tools like get_score.

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

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

No explicit when-to-use or when-not-to-use guidance compared to alternatives like get_score or get_score_leaderboard; usage is implied by the resource name but not clarified.

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 annotations, the description adds that data is observed, decision-support only, ignores fees/slippage/latency, and the wrapped-asset premium is only for BTC/ETH. 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?

Well-structured with summary, details, limitations, and workflow. Every sentence adds value, but could be slightly more concise regarding limitations.

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?

Output description is comprehensive, but input parameters are not explained despite 0% schema coverage. Workflow context is provided, but parameter documentation gap reduces 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?

With 0% schema coverage, the description should explain parameters. It does not describe window_minutes or caller_id, and only implies asset is the query target. Lacks compensation for missing 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 it provides a cross-venue snapshot for one asset, listing specific data points and distinguishing it as an intelligence step. It also mentions pairing with get_arb_discrepancies, differentiating 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?

Explicitly says when to use (INTELLIGENCE step), when not (never an execution instruction), and suggests pairing with get_arb_discrepancies. Provides strong guidance on context and alternatives.

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

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

Annotations already indicate read-only, open-world, idempotent, non-destructive. The description adds significant behavioral detail: what counts as an active user, what transactions count, aggregate nature, no per-wallet data. It also notes 'free'. 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 detailed and front-loaded with the tool's purpose. Every sentence provides value, but it could be slightly more concise. The structure is logical, explaining the metric, decision, and return values.

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 presence of an output schema (not shown but indicated), the description explains all return fields (gate_met, active_users, near_active_users, users_with_any_tx, pinned transaction definition) and the active user definition. It covers behavioral constraints (aggregate only, no per-wallet) and usage context. It is complete for an informational readiness metric.

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

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

Schema has 2 parameters with 0% schema coverage. The description explains the 'cluster' parameter (mainnet vs devnet) and its effect, adding value. It does not describe 'caller_id', but its purpose is often self-explanatory. Overall, the description compensates well for the lack of schema documentation.

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

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

The description clearly states the tool's purpose as checking the ILO adoption gate readiness, specifying the exact metric (active users >= 1000 with at least 5 transactions in 7 days) and what it returns. It distinguishes itself from sibling tools by focusing on this unique readiness metric.

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 that the tool is for checking ILO readiness on mainnet, with devnet for pre-launch observability. It states it is informational and not a promise. However, it lacks explicit guidance on when not to use it or alternatives, but the context is clear enough for typical use.

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

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

Annotations declare readOnlyHint, idempotentHint, and not destructive, which are consistent. The description adds critical behavioral nuance: it only returns server-persisted state, never infers (e.g., UNKNOWN means unresolved send), and explains the fail-closed reporting model. This goes beyond basic annotation info.

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 at 4 sentences, front-loading the purpose. It could be more structured by separating the list of states and the behavioral caveats, but overall it is efficient and avoids unnecessary 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?

Given the tool has an output schema (not shown), the description reasonably explains the return states and their semantics (e.g., UNKNOWN vs CONFIRMED). It provides enough context for an agent to understand the tool's role in the intent lifecycle, though it lacks parameter explanations and could mention typical use cases.

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 2 parameters (intent_id required, caller_id optional) with 0% schema description coverage. The description does not explain the parameters' meaning or usage beyond implying intent_id identifies the execution intent. No detail on caller_id or expected formats is provided.

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 verb 'Read' and the resource 'persisted lifecycle state of an execution intent', immediately distinguishing it from sibling tools like get_strategy_status or crank_dependency_status. It also lists specific return states, making the tool's purpose unambiguous.

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

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

The description explains that the tool reads server-persisted state and interprets UNKNOWN as unresolved and CONFIRMED as verified on-chain success, but it does not explicitly state when to use this tool over alternatives or when not to use it. No sibling comparisons or exclusion criteria 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 indicate readOnly, idempotent, non-destructive. Description adds useful context: tool is free, crypto-only, no return promises (rule 8), and entries carry on-chain attestation hash. 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?

Two sentences, no wasted words. Front-loaded with the core purpose, followed by scope constraints and data details. Efficient and clear.

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?

Output schema exists, so return value details are not required. Description covers scope (crypto-only) and data items (metrics + hash). However, fails to describe three out of four optional parameters, leaving the agent with incomplete understanding. Adequate but with clear 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 coverage is 0%, meaning description provides no explicit parameter details. Only 'sort' is implied via listing sort metrics. Parameters limit, caller_id, and strategy_type are not mentioned. Description fails to add meaningful semantics beyond the schema.

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

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

Clearly states it returns top published strategies ranked by a verified backtest metric, specifies crypto-only exclusion of equity templates, and mentions the default sort. Distinguishes from siblings like get_score_leaderboard or get_strategy_leaderboard by focusing on verified backtest metrics.

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

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

Provides sort options (sharpe, return, etc.) with default, and describes what each entry contains (backtest metrics + attestation hash). Implicitly suggests when to use (for ranking strategies) but doesn't explicitly differentiate from sibling tools. Lacks explicit when-not-to-use or alternatives.

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

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

The description adds significant behavioral context beyond annotations (readOnlyHint, idempotentHint). It discloses pricing, quota limits, billing outcome in response, reliance on free public sources, and that it is not financial advice. 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 comprehensive but somewhat lengthy; however, every sentence adds value. It is well-structured with a clear flow: purpose, details, parameters, billing, workflow context. Could be slightly more concise but remains effective.

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

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

Given the complexity (6 parameters, 0% schema coverage, output schema exists), the description adequately covers data sources, sentiment components, billing tiers, prerequisites, and workflow placement. It does not detail the output schema but the presence of output schema reduces that need.

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 0% schema description coverage, the description compensates by explaining the two key parameters: assets (optional list, focuses synthesis for paid tiers) and detail_level (free, pro, platinum with pricing and quality differences). Other parameters like caller_id and wallet_address are mentioned but not detailed, yet their purpose is inferable from 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 returns a crypto market briefing synthesized from free public sources, with specific components like market summary, top movers, sentiment, Fear & Greed, and source attribution. It differentiates itself among siblings by focusing on aggregated market context, distinct from tools like get_market_regime or get_consensus.

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 explicit guidance on when to use this tool: as an INTELLIGENCE step framing detect_regime and allocation, and references get_trading_workflow for context. It explains billing tiers and prerequisites for paid tiers (subscription or x402 payment header). However, it does not explicitly state situations where this tool should be avoided in favor of alternatives.

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false. The description adds value by stating it is a 'free read', 'descriptive observed data only', and 'Not financial advice', which enriches the behavioral understanding 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?

The description is about six sentences, well-structured with the main purpose first, followed by output details, differentiation from sibling, workflow guidance, and disclaimers. Every sentence adds value, though it is slightly verbose for the parameter gap.

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

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

Given that an output schema exists (which documents return values), the description provides good workflow context and data classification. However, the complete lack of parameter documentation is a significant gap that reduces completeness, especially since schema coverage is 0%.

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 0%, meaning none of the three parameters (limit, caller_id, window_hours) are described in the schema. The description does not explain the meaning, range, or effect of any parameter, leaving the agent without guidance on how to populate them.

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 returns the market-wide regime from persisted data, specifies the outputs (dominant regime, confidence, distribution, contributing signals), and distinguishes itself from the sibling tool detect_regime by noting it is for market-wide, not per-asset, regime.

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 places the tool in the INTELLIGENCE workflow step for market-wide posture check before strategy selection, and suggests pairing with detect_regime for the asset leg. It does not explicitly state when not to use it, but the context is clear.

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

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

Annotations already indicate readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds significant behavioral context: it explains that data is sourced from journaled non-paper outcomes, includes calibration scores only when expectations are journaled, and uses the phrase 'free read' to imply no cost. No contradiction with annotations exists.

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

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

The description is relatively concise but includes some redundancy (e.g., 'Your own realised performance, grouped (free read)' could be merged). The three-paragraph structure is clear but might benefit from tighter phrasing. It front-loads the core purpose, which is good, but the second paragraph detailing metrics could be integrated more efficiently.

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

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

Given the tool's complexity (aggregation, multiple grouping dimensions, calibration score) and the presence of an output schema (not shown but exists), the description covers key functional aspects. It explains what metrics are returned, the grouping mechanism, and the calibration condition. However, it does not clarify whether historical data includes current period limits or pagination behavior, which is a minor gap.

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

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

Input schema has 4 parameters with 0% description coverage. The description partially compensates by explaining the grouping mechanism (strategy_type, asset, decision_type, hour_of_day) and the time window ('over window_hours'), which covers group_by and window_hours. However, wallet_address (required) and caller_id (default '') are not explained, leaving ambiguity about their purpose and constraints.

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 specific verbs like 'aggregates' and clearly identifies the resource as 'your own realised performance'. It lists the grouping dimensions (strategy_type, asset, decision_type, hour_of_day) and mentions included metrics (win rate, P&L, fee drag, calibration score). This distinguishes it from many sibling tools that focus on other data (e.g., get_leaderboard, get_risk_assessment) or actions.

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

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

The 'Workflow: ORIENT step -- read this before sizing or creating strategies' provides explicit guidance on when to use the tool. The description also notes it is 'descriptive only, not a recommendation', setting expectations for non-actionable insight. However, it does not name alternative tools for specific performance comparisons or filtered queries, leaving some gap in completeness.

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 readOnlyHint, idempotentHint, destructiveHint=false. The description adds: 'loaded once per session instead of forgotten between calls' (caching behavior), 'free read', and details about advisory vs hard rules. This enriches transparency beyond the structured fields.

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 somewhat verbose with phrases like 'a user-authored document declaring...' but provides structured information. It front-loads the key action and follows with details and workflow, making it effective despite minor 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?

Given the tool's complexity and the presence of an output schema, the description covers all essential context: what the tool returns, when to use, behavioral notes, and relation to sibling tools. No gaps remain for successful 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 0%, so the description must compensate. It explains the overall purpose but does not describe the two parameters ('wallet_address', 'caller_id') explicitly. The wallet_address role is implied, but caller_id is unmentioned. Without parameter descriptions, the agent lacks clarity on input semantics.

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

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

The description clearly states 'Read the wallet's active portfolio charter' with a specific verb and resource. It distinguishes from sibling tool 'set_portfolio_charter' and explains the charter's role as a CRANK.md-equivalent mandate, making purpose unambiguous.

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

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

Explicitly tells when to use: 'ORIENT step 0 -- read this FIRST, before get_balances / portfolio_snapshot'. Also provides when-not-to-use: 'has_charter is False when the wallet has not set one yet -- call set_portfolio_charter'. This gives clear context for agent decision-making.

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 declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, which the description complements with specifics: it's a 'FREE read', time-bounded campaigns, and includes progress when wallet_address is given. The description adds behavioral context (e.g., carries disclaimer, what fields each quest has) without contradicting annotations.

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

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

The description is brief and front-loaded with the core purpose. It uses two sentences plus a list-like explanation of quest fields, avoiding unnecessary words. Every sentence 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?

Given the presence of an output schema (not shown), the description need not detail return values. It sufficiently explains what each quest contains (metric, target_value, reward_points, active window) and the conditional progress output. The mention of disclaimer adds completeness. For a read-only tool with good annotations, this is fully adequate.

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

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

Schema description coverage is 0%, so the description must explain parameters. It describes wallet_address's effect (triggers progress_value + completion state), but does not explain caller_id. This partial coverage adds some meaning but leaves one parameter undocumented, resulting in a mid-range score.

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 retrieves 'Live Crank Score quests' and optionally a wallet's progress. It specifies the resource (quests) and action (get). It distinguishes from siblings like get_crank_score or get_leaderboard by focusing on quests, a specific type of campaign.

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

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

The description implies use for retrieving quests and wallet progress, but lacks explicit guidance on when to use this tool versus alternatives (e.g., get_crank_score). It does mention 'FREE read', suggesting no cost, which is a usage hint. However, without clear comparisons to siblings, the guidance is incomplete.

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

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

Annotations already provide readOnlyHint, idempotentHint, openWorldHint, and non-destructive. The description adds value by detailing the data structure (fields like agency, relevance, summary), ranking logic, limitations ('Not financial advice'), and the scheduled daily scan. No contradictions.

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?

Description is front-loaded with purpose, then details return data, parameters, and workflow. It is somewhat lengthy but every sentence adds value; no redundancy. Could be slightly more concise but effectively structured.

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

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

With an output schema present, the description covers input parameters, purpose, workflow, and data semantics. The only gap is the undocumented caller_id parameter; otherwise, it is sufficiently complete for a read-only retrieval 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 0%, but the description explains three of four parameters: window_hours (default 168, cap 720), min_relevance (high/medium/low), and agency (SEC/CFTC/FinCEN). The caller_id parameter is not explained, but overall parameter semantics are well-addressed.

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 recent regulatory statements (SEC/CFTC/FinCEN press releases and rule proposals) relevant to Crank's scope, with specific verbs like 'returns' and details on classification. It distinguishes from siblings like 'get_technology_updates' through focus on regulatory content and workflow step.

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 provides explicit workflow context ('Workflow: INTELLIGENCE / COMPLIANCE step') and usage scenarios but does not directly name alternative tools or when not to use. The guidance is clear for its purpose but lacks explicit exclusions.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds value by detailing the returned fields (total_score, rank, multiplier_bps, metrics, quests) and includes a disclaimer about token distribution. However, it does not mention rate limits or authentication requirements.

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

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

The description is appropriately detailed and front-loaded with the main purpose. Each sentence provides useful information, though it could be slightly more concise. The structure is logical and readable.

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 (multiple return fields) and the presence of annotations and an output schema (not shown), the description covers all essential aspects: what it returns, the anti-farm scoring source, and the disclaimer. It is complete enough for an agent to understand the tool's behavior.

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

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

Schema description coverage is 0%, meaning the schema has no parameter descriptions. The description does not explicitly clarify the purpose of the two parameters (caller_id, wallet_address) beyond their names. With low coverage, the description should compensate but does not, leaving parameter semantics vague.

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 the user-facing Crank Score including rank, multiplier, metrics, and quests. It distinguishes itself from the sibling tool get_crank_score by calling it the 'campaign-layer view', providing specific verb+resource 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 implies usage context (user-facing score) and hints at distinction from get_crank_score, but does not explicitly state when to use this tool versus alternatives like get_leaderboard or get_quests. No 'when not to use' guidance is 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, openWorldHint, idempotentHint, and destructiveHint. Description adds that it's a 'FREE read', caps limit at leaderboard_size, and lists return fields. Does not contradict annotations; provides useful behavioral context 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?

Three sentences covering purpose, sorting, parameter behavior, return fields, and sibling distinction. No wasted words, front-loaded with key intent.

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?

While annotations and output schema are present, the description covers ranking, limit cap, and return structure. Could mention default limit or pagination, but sufficient for a read-only leaderboard.

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 0%, but description explains the 'limit' parameter's behavior (capped at leaderboard_size) and lists return entries. The 'caller_id' parameter is not elaborated, but defaults are present.

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

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

Clearly states it's a 'Top-N Crank Score leaderboard' ranked by total_score, with a specific identifier. Distinct from sibling get_leaderboard, which ranks strategy templates, as explicitly noted.

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

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

Explicitly distinguishes from get_leaderboard, stating its ranking scope. Also indicates it's a 'FREE read', guiding agents on when to use without risk.

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. The description adds significant value by specifying that the tool is a 'free read', returns only descriptive historical data, and is never a recommendation or promise of results, reinforcing safety and non-mutating nature.

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-structured with a purpose statement, filter list, output details, and workflow note. It is slightly verbose but efficiently conveys key information without redundancy.

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

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

Given the presence of an output schema and annotations, the description adds crucial workflow context and distinguishes from sibling tools. However, the unexplained caller_id parameter and lack of full parameter details prevent a perfect 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?

Schema coverage is 0%, so description must compensate. It explains three of four parameters (source_type with examples, signal_type, window with options) but omits caller_id entirely. Provides partial but incomplete semantics.

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

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

The description clearly states the tool returns fleet action-conditioned signal effectiveness metrics, distinguishing it from personal performance tools like get_source_accuracy and get_my_performance. It explicitly mentions 'historical collective performance data' and 'descriptive only, never a recommendation'.

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 explicit filters and workflow context, suggesting use as an 'INTELLIGENCE step' alongside personal track records. It does not explicitly state when not to use, but the context is clear and distinguishes from siblings.

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

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

Annotations declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the description adds value by noting that 'unknown filter values are dropped, not errored' and that the data is 'descriptive observed data only.' 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 well-structured in three paragraphs: main purpose, parameter details, and workflow integration. It is front-loaded with the core function. The list of signal types is somewhat verbose but still efficient. No unnecessary sentences.

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

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

Given the tool has an output schema (so return values are covered externally) and 8 parameters, the description provides sufficient context for an AI agent to understand the tool's role, filtering behavior, and how to integrate it with siblings. It could mention the default limit or the purpose of caller_id, but overall it is 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?

With 0% schema description coverage, the description compensates by explaining key filtering parameters: subject, signal_type, tier, risk_level, min_score. It also describes the behavior for unknown values. However, it does not explain some parameters (limit, caller_id, include_expired) beyond their names, and the schema provides no 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 it provides a 'filtered, most-recent-first feed of structured market signals' and lists the categories of signals (squeeze, flow, technical, etc.). It distinguishes itself from sibling tools by naming specific complementary tools (get_market_briefing, get_token_risk_assessment).

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

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

The description explicitly says to use this as an 'INTELLIGENCE step' and pairs it with other tools for macro and per-token analysis. It clarifies that it is 'not a trade instruction' and 'not financial advice,' implying a read-only analytical use. However, it lacks an explicit statement of when not to use it.

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

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

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is clear. The description adds that results are newest first and claim-code secrets are excluded, but this is minimal extra behavioral context 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?

The description is a single, front-loaded sentence with no wasted words. Every part (resource, ordering, exclusion) 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?

While an output schema exists, the description lacks parameter explanations and usage guidance, making it incomplete for a tool with two parameters (one required). The simple nature of the operation partially offsets this, but gaps remain.

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 0%, and the description adds no meaning to the two parameters (caller_id, wallet_address). The wallet_address parameter is required, but its significance is not explained. In low-coverage scenarios, the description must compensate, which it fails to do.

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 resource ('social token sends') and action ('get'), with ordering ('newest first') and exclusion ('no claim-code secrets'). This distinguishes it from sibling tools like send_token_social or bulk_send_social.

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 (newest first, no secrets) but no explicit guidance on when to use this tool versus alternatives. No when-not or alternative tool mentions, leaving the agent to infer usage from name and context.

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

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

The description goes beyond annotations (readOnlyHint, idempotentHint, destructiveHint=false) by detailing output structure, ranking logic, omission of sources with no resolved calls, and the accuracy calculation formula. 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 well-structured, front-loading the purpose, then detailing output, parameters, accuracy, caveats, and workflow. It is slightly verbose but every sentence adds value. A bit more conciseness would elevate it to a 5.

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

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

The description provides comprehensive context: output structure, parameter behavior, accuracy definition, caveats, and workflow integration. The caller_id parameter is omitted, but overall completeness is high given the presence of an output schema and detailed annotations.

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 0% schema description coverage, the description explains two of three parameters: 'windows optionally narrows the periods (subset of [7,30,90])' and 'source_type optionally filters by source kind (youtube, rss, api, on_chain).' The caller_id parameter is not explained, leaving a gap.

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

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

The description clearly states the tool's purpose: 'Historical directional hit-rate of each intelligence source (free read).' It specifies what is returned (per-source accuracy stats), lists the sources, and differentiates from sibling tools like get_signals or get_source_weights by focusing on historical 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 provides explicit workflow guidance: 'Workflow: INTELLIGENCE step -- pair with get_market_briefing to discount or trust a signal...' and includes a caveat that past accuracy is not a guarantee. It lacks explicit when-not-to-use instructions but the context is clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds valuable behavioral context: 'free read' (no cost or permission issue), 'historical grading statistics only -- descriptive, never advice', and the anti-gaming cold start mechanism for social sources. These details go beyond what annotations provide, though annotations already cover the read-only nature.

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 structured into three concise paragraphs: data content, clarification of descriptive nature, and workflow integration. It is mostly efficient, though the repetition of 'descriptive, never advice' and 'Not financial advice' could be merged. Overall, it is well-organized and front-loaded.

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

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

The description covers the tool's purpose, behavioral traits, and workflow context. However, it does not explain the single parameter, which is a gap. Since an output schema exists, return values are not needed, but the incomplete parameter explanation reduces completeness. Given the tool is a simple read lookup, it is adequate but not fully comprehensive.

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

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

Schema coverage is 0% and there is one parameter 'caller_id' with a default. The description does not explain what this parameter does or how to use it. Although the parameter might be optional, the agent lacks guidance on its purpose, especially when to override the default. The description focuses entirely on the output data, ignoring the input parameter.

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

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

The description clearly states the tool provides a source-effectiveness weight table with specific fields like graded evaluation counts, smoothed weight, and a composite value. It explicitly distinguishes itself from sibling tools by mentioning the workflow alongside 'list_signal_catalog' and implying it is for 'pick streams with a real graded track record'. The verb 'get' and resource 'source weights' is unambiguous.

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

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

The description provides explicit workflow context: 'COMPOSE step -- read alongside list_signal_catalog to pick streams... before authoring a definition'. This tells the agent when to use this tool (during composition, before definition authoring). It does not explicitly list alternatives or when not to use, but the workflow guidance is clear enough.

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, destructiveHint=false. The description adds crucial behavioral context: anonymization, k-anonymity floor of 25, no wallet/cohort identification, and that data is descriptive only (not a recommendation or promise). This significantly enhances transparency without contradicting annotations.

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

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

The description is well-structured: a one-line summary, then key details, then workflow. It is slightly longer than minimal, but every sentence adds value. It could be trimmed slightly but remains efficient and readable.

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

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

Given that an output schema exists (and thus return values are documented), the description covers purpose, usage, behavioral constraints, and workflow thoroughly. There are no obvious gaps for an intelligence-focused 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?

With schema description coverage at 0%, the description must compensate. It mentions 'window (24h|7d|30d|90d|all)' and implicitly covers 'strategy_type' by referring to it in the workflow. However, 'caller_id' is not explained. The description adds partial meaning beyond the schema but is not comprehensive for all three parameters.

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

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

The description clearly states it is an anonymized strategy-parameter leaderboard that ranks collective insights by effect_size over various windows. It explicitly distinguishes from siblings by positioning it as an intelligence step before adjusting strategies, and it details what the tool does and does not do (never identifies wallets, drops small buckets).

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 explicit workflow guidance: 'INTELLIGENCE step -- compare a strategy_type's own parameter choices against fleet-wide observed outcomes before adjusting via suggest_parameter_adjustment / the strategy tools.' It also specifies that results are anonymized and only descriptive, not recommendations, and that buckets with fewer than 25 contributors are dropped. This gives clear when-to-use and when-not-to-use context.

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

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

Annotations already provide readOnlyHint=true, destructiveHint=false, and idempotentHint=true. Description adds value by detailing aggregation frequency (hourly), data sources (accuracy-weighted consensus), and stating it never executes actions. No contradiction.

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

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

Front-loaded with key purpose and usage. Workflow and status details are clear. Slightly verbose but well structured for the complexity of 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?

Tool complexity is moderate; has output schema, so return values are covered. Description explains workflow and data context. Missing a bit on parameter details, but overall adequate given sibling differentiation and annotations.

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 0% (no parameter descriptions in schema). Description only explains one parameter: 'status' with allowed values. Other parameters (asset, limit, caller_id) are undocumented. With low schema coverage, description should compensate more.

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?

Clear verb+resource: 'signal-to-action suggestions from the synthesis engine'. Distinguishes from siblings by emphasizing read-only nature and specific data sources (accuracy-weighted consensus, Fear & Greed context). No confusion with execute 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?

Explicitly states it never executes anything and suggests workflow: review suggestions, pair with backtest_strategy + get_risk_assessment before create. Mentions PROPOSE flow and using strategy tools. Lacks explicit 'when not to use' but provides sufficient context.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds rich context: data sources, classification categories, output fields, and 'triage signal, not advice'. No contradictions.

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 informative but slightly lengthy. It is well-structured with a summary, details, and parameter explanations. Each sentence adds value, but could be tightened slightly.

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 (multiple feeds, classifications, output fields) and the presence of an output schema, the description is impressively complete. It covers data sources, output fields, and workflow context thoroughly.

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

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

Schema has 0% coverage, so description carries full burden. It explains window_hours (default 168, cap 720), min_relevance (high/medium/low), and category (optional). However, caller_id is not described, leaving a minor gap.

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

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

The description clearly states it returns technology developments relevant to Crank and Engaij, listing specific feeds and classification. It distinguishes itself from sibling tools like get_regulatory_updates by focusing on tech/tooling updates.

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 workflow guidance ('INTELLIGENCE step -- scan for SDK / API releases, competitor moves, or tooling worth adopting before planning integration or strategy work'), but does not explicitly mention when not to use it or compare to alternatives.

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

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

Annotations already declare readOnlyHint and idempotentHint. The description adds detailed return fields and fail-safe logic (tradeable=false for unscored/inactive tokens), which goes beyond annotation hints.

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

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

The description is two sentences with the primary purpose first. The second sentence is dense but informative. No wasted words, though could be slightly more streamlined.

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 presence of an output schema, the description explains the key return dimensions and fail-safe behavior. It is complete for a classification tool with good annotation coverage.

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 0%. The description clarifies the required param 'mint_or_symbol' by stating it accepts a mint or symbol, but does not explain 'caller_id'. Only partial compensation for low 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 provides standardized tokenized-stock classification for a mint or symbol, listing specific dimensions returned and composite risk. This distinguishes it from siblings like token_info and verify_token.

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

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

The description mentions it's read-only and describes fail-safe behavior, giving context on when to use. However, it doesn't explicitly compare to alternatives or state when not to use.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, so the agent knows it's a safe, read-only, idempotent operation. The description adds behavioral context beyond annotations: it describes the roll-up logic (worst risk level, 0..1 score, per-level breakdown, contributing signals worst-first), the window of consideration (non-expired signals), and that it is 'descriptive observed data only' and 'Not financial advice'. This adds value by explaining how the tool processes data, though annotations already cover the safety profile, so score is high but not maximum.

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: three short paragraphs that front-load the main purpose and key behavior. The first sentence immediately states the core functionality. The structure is logical: purpose, details, workflow guidance. Every sentence provides value without redundancy. However, it could be slightly more structured (e.g., explicit parameter descriptions), but overall it is efficient and well-organized.

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

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

Given the tool has 4 parameters, a sibling tool, and an output schema (which exists), the description covers the main contextual needs: purpose, when to use, relationship to sibling, and the roll-up logic. It does not explain the output structure (though output schema exists, so that burden is lower) or provide details on each parameter. The workflow guidance is strong. For an agent deciding whether and when to invoke this tool, the description is sufficient, but for parameter usage it relies on the schema. Overall, it is complete enough for selection but not for full parameter understanding.

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 0%, meaning the description does not individually explain parameters. The description mentions 'subject (symbol or mint)' implicitly in the first sentence, but does not describe limit, caller_id, or window_hours beyond their defaults. For a tool with 4 parameters, the description provides minimal semantic value beyond what the schema gives (names and types). The agent would need to infer the purpose of parameters, which is insufficient for correct invocation.

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

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

The description clearly states the tool's purpose: 'Per-token risk roll-up over recently observed safety signals'. It specifies the verb (roll-up/get), resource (per-token risk), and distinguishes itself from the sibling 'get_risk_assessment' by contrasting that this is descriptive observed data versus the other's regime+position-size guards. The phrase 'Complements -- does not replace' further clarifies the relationship. The purpose is specific, verb-driven, and differentiates from siblings.