Crank Protocol

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

With annotations only providing readOnlyHint=false, destructiveHint=false, openWorldHint=true, and idempotentHint=false, the description goes far beyond by detailing the state transition (pending → approved → redispatch), the exact re-invocation mechanism (stored tool_name + params through the dispatch table), the failure semantics (stays APPROVED, not silently EXECUTED or PENDING), and retry guidance ('call this again to retry'). This richly complements the openWorldHint and aligns with the non-destructive annotation.

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

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

The description is well-structured with purpose front-loaded, then mechanism, then failure/retry behavior, then a code reference. The final 'See wallets.approve_proposal' is a useful pointer. The middle sentence is long and packs several clauses, but each detail earns its place; it is dense rather than 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?

For a complex stateful tool with an output schema, the description covers purpose, preconditions (pending proposal, propose-mode, TTL), mechanism, post-conditions, and error/retry semantics. The only gap is the unexplained caller_id/approved_by semantics, which ties back to parameter 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 description coverage is 0%, so the description must compensate. It helps for proposal_id by establishing the approval targets a 'pending PROPOSAL,' but it is completely silent on caller_id and approved_by — both have empty-string defaults and ambiguous purpose. An agent cannot tell whether to populate them, leave them empty, or whether they are server-injected for attribution or signature.

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

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

The description opens with a specific verb+resource+context: 'Approve a pending PROPOSAL within its TTL, then re-dispatch it (non-custodial control plane).' This uniquely identifies what the tool does and distinguishes it from siblings like propose_allocation, propose_template_update, and set_permission_mode — the agent immediately understands this is the approval step in a proposal lifecycle.

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

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

The description clearly implies when to use this tool: when a proposal is in propose-mode ('see set_permission_mode') and pending, and it even explains when to call again on redispatch failure. It cross-references set_permission_mode as a precedent condition. However, it never explicitly states 'when NOT to use' or names a direct alternative for the same step, so guidance stops short of a full 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, etc. The description adds: 'Registry-authoritative with a static + symbol fallback' and 'Factual classification only—not a recommendation,' clarifying data sourcing and non-recommendation nature. Slightly lacks detail on response format, but output schema exists.

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

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

The description is concise at ~6 lines, front-loaded with the classification purpose, and well-structured: categories, input, special cases, data source, workflow. Every sentence adds value 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 tool's complexity (compliance implications), the description covers purpose, input, special behavior, workflow integration, and pairing. Output schema exists for return values, so no gap. Aids correct agent decision-making fully.

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%; description partially compensates by naming 'token_address (mint)' and 'symbol' and their usage. However, the third parameter 'caller_id' is not explained, leaving a gap. Adds value for two params but incomplete.

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

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

The description starts with a clear verb and resource: 'Classify a token' followed by the specific categories, distinguishing it from siblings like get_token_classification. It also details special cases (e.g., tokenized securities as equity), 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 states when to use—'RISK/COMPLIANCE step—classify before executing'—and consequences of 'equity' classification (geo-gating + confirm). Also pairs with get_disclaimers and references get_trading_workflow, providing complete usage context.

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

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

Beyond the annotations, the description discloses surprising behavior: the tool always refuses, applies to every wallet, validates capabilities only for UX, and never lets anything but the public signer key cross the surface. It also explains the security rationale and the handshake requirement.

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 first sentence front-loads the most critical behavior, and every subsequent sentence adds relevant context: the reason for refusal, the alternative workflow, and the security rule. There is no filler or repeated schema information.

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

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

The description is complete enough for an agent to avoid a doomed call and route to the browser handshake. Minor gaps remain around additional parameter details and the exact output/error payload, but the output schema and the always-refusal design reduce the need for more.

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

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

The description adds important meaning for signer_pubkey, explaining it is a user-held keypair and only its public key should cross the surface. However, schema description coverage is 0%, and other parameters such as expires_at, capabilities, label, and caller_id are left mostly to inference from their 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?

The description opens with an explicit behavioral statement: 'Refuses ALWAYS with BROWSER_CONFIRMATION_REQUIRED.' It clearly defines what the tool does, why it exists, and differentiates it from the actual authorization flow via request_session_signer_authorization and poll_session_signer_authorization.

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

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

It explicitly tells the agent when not to use this tool by stating every call is refused and names the only valid mint path: the browser handshake sequence. This is strong when-to-use and when-not-to-use guidance with named 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 discloses that the tool is read-only, simulates with no fees or on-chain actions, and provides honesty reports for composite strategies. This adds value beyond the annotations (readOnlyHint, destructiveHint) by detailing specific behavioral traits.

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 clear purpose, parameter details, and workflow. It front-loads the main idea and contains useful examples. While slightly verbose in listing all 17 strategy types, it remains efficient overall.

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 (13 parameters, output schema exists), the description covers return metrics, honesty reports, slippage models, and workflow. It provides sufficient context for the agent to use the tool correctly without needing the output schema details.

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 most parameters (strategy_type, asset, timeframe, dates, params, slippage_model, etc.) and their defaults. However, a few parameters like caller_id and wallet_address are not detailed, leaving minor 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 purpose: backtesting a strategy on historical Solana OHLCV before deploying capital. It lists specific strategy types and differentiates this tool from siblings by positioning it as a simulation 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?

The description provides explicit usage guidance: use before deploying capital, run twice for comparison, retune on poor Sharpe. It also references related tools (get_risk_assessment, strategy_*_create) and a workflow, giving clear when-to-use and fallback advice.

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 far beyond annotations: it states the tool is non-custodial, that Crank never signs or broadcasts the EVM leg, that funds are never held in flight, that the result is an unsigned evm_transaction to be broadcast by the user, and that idempotency_key replays the original order. This gives an agent an unusually clear behavioral model.

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

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

The description is dense but well organized, front-loaded with purpose and process. It includes some repeat emphasis (never signs, never broadcasts, never holds funds in flight), but each sentence contributes actionable information and the length is reasonable for a complex bridge 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?

Given the output schema exists, the description covers the most important operational facts: source chains, return shape, signing requirement, post-bridge workflow, fees, paper trading, and idempotency. It could still explain a few non-obvious params like pay_in_crank and caller_id, but an agent would be well equipped to call this tool correctly.

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

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

Schema description coverage is 0%, so the description carries the burden. It meaningfully explains amount units, dst_token semantics, wallet_address, evm_sender, src_chain supported values, and idempotency_key. Some parameters like caller_id, pay_in_crank, and payment_header remain unexplained, which keeps this from being a 5.

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

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

The description clearly states a specific action — funding a Solana wallet from a major EVM chain — and explains it does this by building an unsigned EVM bridge order. It names the resource types involved (dst_token, wallet_address, evm_sender) and differentiates itself from nearby sibling concepts like bridge_out or jupiter_swap.

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

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

It gives clear context for when to use the tool: cross-chain funding from supported EVM chains into Solana, then pairing with jupiter_swap or strategies once funds arrive. It lacks an explicit when-not-to-use statement or named alternatives such as bridge_out, but the workflow guidance is strong enough to route a caller.

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 well beyond the annotations, disclosing the two-phase build/completion flow, the fee model ('charged once per order on the build leg, never re-charged on the completion leg'), paper trading behavior, idempotency semantics, and the reconciliation mechanism via order_id. It also flags that the unsigned transaction must be signed with the wallet for wallet_address. This gives an agent strong awareness of side effects and financial implications.

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 long but densely informative, with clear paragraph breaks for the two-phase flow, fees/paper trading, idempotency, and reconciliation. The main purpose is front-loaded, and most sentences add operational value. It could be slightly tightened, but the length is justified given the tool's complexity.

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

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

For a complex 13-parameter bridge tool, the description covers the overall workflow, signing requirement, fee behavior, and post-completion polling. The presence of an output schema reduces the need to describe return values. The main completeness gap is the set of undocumented parameters, especially dst_token, which prevents the description from being fully self-sufficient.

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 provides meaningful semantics for several key parameters: src_token as the Solana mint, amount as base units, evm_recipient as the address on dst_chain, signed_transaction mode, idempotency_key, and order_id. However, it leaves important parameters unexplained, including the required dst_token, plus verify, caller_id, pay_in_crank, and payment_header, which are not self-evident from the schema 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 opens with a specific verb and resource: 'Bridge value from Solana out to a major EVM chain (non-custodial).' This clearly distinguishes it from sibling bridge_in by direction and explicitly names target chains. The purpose is unambiguous and not a tautology.

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

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

The description gives concrete usage conditions: without signed_transaction it returns an unsigned transaction to sign, and with signed_transaction it broadcasts the tx and returns a verification block. It also routes follow-up polling to get_bridge_status(order_id), which helps an agent choose next steps. It does not explicitly state when to prefer bridge_out over bridge_in or other alternatives, but the directional framing makes the primary use case 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 discloses key behavioral traits: it locks amounts into escrow, returns unsigned transactions for the sender to sign and broadcast, includes claim links and codes, and mentions anti-abuse gating. It also explains idempotency behavior. Annotations indicate destructiveHint=true and readOnlyHint=false, which align with the description's mutation and locking 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?

The description is detailed but well-structured, with a clear opening sentence, then a breakdown of parameters and process. It's a bit long but each sentence adds value. The idempotency explanation is placed at the end, which is appropriate. 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 tool's complexity (batch sends, escrow, unsigned transactions, idempotency), the description covers the essential aspects. It mentions the output includes claim links, codes, and transaction indices, and there is an output schema. It doesn't detail the exact output structure, but the output schema likely covers that. It also mentions anti-abuse gating, which is important context.

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

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

Schema description coverage is 0%, so the description must compensate. It explains 'recipients' as a list of dicts with fields (recipient_handle, amount, message?), mentions 'recipient' alias, 'amount' in base units, and 'message' as optional. It also explains 'token' as mint, 'sender_wallet', and 'idempotency_key' with its retry behavior. This adds significant meaning beyond 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's purpose: 'Distribute one token to many X handles in one call (non-custodial).' It specifies the action (distribute), the resource (token to X handles), and the mode (non-custodial). It distinguishes itself from the sibling 'send_token_social' by emphasizing batch distribution and the claim escrow mechanism.

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

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

The description provides clear context on when to use this tool: for batch distribution to many handles, with details on the recipients structure and the process. It doesn't explicitly state when NOT to use it or name alternatives, but the batch vs. single distinction is implied. It also mentions anti-abuse gating, which helps the agent understand constraints.

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 only flag destructive/read/write traits. The description goes far beyond that by disclosing the non-custodial venue behavior, geo-gating of cancels, optional idempotency replay semantics, the promise that the two leg bugs never raise IDEMPOTENCY_CONFLICT, and the two-phase execution semantics. It also explains isverification enough because cancel moves no position, so no state re-read is required.

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

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

The description is front-loaded with its purpose and then uses compact parameter-focused paragraphs for the nuanced fields. The content is dense and mostly justified, though the repeated 'see place_perp_order' references and the lengthy idempotency paragraph could be tightened without losing information.

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

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

For a 10-para, destructive perp API with an output schema, the description covers the most safety and execution-critical behaviors: non-custodial, geo-gated cancellation, idempotency, and two-phase execution. The main gaps are practical meaning of the remaining optional parameters and the reliance on cross-references to place_perp_order for necessary details.

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 compensates for only some parameters: 'jurisdiction' (geo-gating), 'idempOTency_key' (replay rules, reuse across legs, no conflict), and 'signed_transaction'/'verify' (two-phase semantics). It leaves 'wallet_address', 'order_id', 'venue', 'ip', 'caller_id', and 'acknowledge_tier_b' without any behavioral or formatting explanation, which matters given the schema has no parameter 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 opening line 'Cancel a resting perp order on its venue (non-custodial)' states a specific verb, resource, and scope. It clearly distinguishes cancelling a resting order from position-closing tools like close_perp_position or perp_close, and 'resting order' narrows it from order placement.

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

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

The description gives strong execution context but no explicit when-to-use/when-not guidance against alternatives such as close_perp_position, strategy_cancel, or place_perp_order. The repeated 'see place_perp_order' references explain semantics but do not tell an agent what alternatives exist or when to choose them.

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, covering the safety profile. The description adds valuable behavioral traits beyond these: it returns a specific JSON structure with a live countdown (expires_in_seconds), lists the statuses, and explicitly states it never exposes the claim-code secret. This adds contextual detail 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 concise and well-structured. The first sentence states the purpose, followed by lookup methods, then the output fields. It front-loads the key information and avoids unnecessary fluff. The second sentence is a bit dense but organized as a list of fields, making it easy to scan.

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 simplicity, the annotations covering safety, and the existence of an output schema, the description is sufficiently complete. It tells the agent how to look up status (by claim_id or recipient), what fields to expect, and includes a security note. The only gap is the undocumented caller_id parameter, but this is minor given the tool's overall clarity.

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 must compensate for parameter meanings. It explains claim_id as 'the send id', recipient as 'X handle', and sender_wallet as scoping for a recipient lookup. However, it does not explain caller_id at all, leaving one of four parameters undocumented. The description partially compensates but is not complete.

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

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

The description clearly states the tool's purpose: 'Sender-facing claim status of a social send (FREE read).' It names the specific resource (social send) and the operation (check claim status), and differentiates from siblings by specifying the lookup methods (claim_id or recipient) and the output fields. It also adds a security constraint (never exposes claim-code secret), making it unambiguous.

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

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

The description provides clear context for when to use the tool: it is sender-facing and a free read, suitable for looking up claim status. It explains the two primary lookup methods (claim_id or recipient) and optional scoping by sender_wallet. However, it does not explicitly mention alternatives or when not to use it vs. sibling tools like claim_status or get_social_sends, so it falls short of a 5.

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

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

The description discloses crucial behavior beyond annotations: there is no backend signing path and 'Crank NEVER co-signs a claim', the returned transaction must be signed by the caller, and the tool returns a no-op result when nothing is claimable. It also explains that claims are free of technology service fees. This is consistent with the idempotentHint=false, destructiveHint=true, and readOnlyHint, 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?

The description is well structured and dense: each block adds distinct value—the claim action, the unsigned-transaction behavior, the the nothing-to-claim branch, the fee policy, and the workflow. There is no redundant prose or vague filler.

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

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

The description very thoroughly covers behavior, edge cases, fee, and workflow, and the output schema can carry the return details. It loses slightly on contextual completeness only because parameter roles are not explained for a multi-parameter mutation tool with 0% 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?

The input schema has 5 parameters with 0% schema description coverage, and the description does not explain the required parameters like launch_id and wallet_address, nor optional ones like idempotency_key or pledger_token_account. It only generically mentions 'your own wallet' and 'your own allocation', which is too thin to properly disambiguate the parameters.

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

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

The description opens with a specific verb and resource: 'Claim the launch tokens your liquidity release schedule has unlocked.' It clearly distinguishes itself from status-check siblings by describing the action and the two action-response forms: sign_required and nothing_to_claim.

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 an explicit workflow: 'poll get_my_pledge_status, claim when release.releasable_base_units is non-zero' and names the relevant sibling tool. It also clearly states the 'when not to claim' conditions by explaining when the tool returns nothing_to_claim instead of a transaction.

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, openWorldHint, idempotentHint, destructiveHint) already declare a safe read operation. The description adds value by listing the returned fields (status, amount, claimable, expiry), but no additional behavioral traits are disclosed.

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 efficiently conveys the tool's purpose and output fields. No redundant information.

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

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

Given the presence of annotations and an output schema, the description covers the basic functionality. However, missing details about error conditions or input format reduce completeness for a simple 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 has 0% description coverage for parameters. The description only mentions 'claim code' in context, failing to explain the purpose of 'caller_id' parameter or any constraints on 'code' format.

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

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 vs alternatives, such as 'check_claim_status'. The description lacks context for selection criteria.

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

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

Beyond the annotations (readOnlyHint false, idempotentHint true), the description explains the effect: 'LOOSENS enforcement (removes a cap constraining every value-bearing call)' and clarifies the Lane-2 behavior. It doesn't fully specify return values, but the output schema exists, so that's not required.

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

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

The description is informative but somewhat verbose and run-on. It includes nested clauses and awkward capitalization (e.g., 'LOOSENS enforcement...'). It could be condensed into clearer sentences without losing meaning.

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, the description covers the key context: the effect on enforcement, the Lane-2 exception, and the recommended alternative. It doesn't mention prerequisites or edge cases, but the presence of an output schema mitigates the need for return details.

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 lists 'caller_id' and 'wallet_address' with no descriptions, and the tool description does not explain either parameter. The wallet_address is implied by the context, but caller_id's role is unclear. The description adds no parameter semantics beyond the names, and schema coverage is 0%.

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 action: 'Remove a wallet's AGNTA DelegationGrant cap opt-in' and specifies the resource (wallet's cap). It differentiates from the sibling 'set_agnta_grant' and conditionally from 'request_agnta_grant_clear', making the purpose unambiguous.

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

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

Explicitly provides when to use this tool vs. the alternative: 'for a Lane 2 wallet this raises BROWSER_CONFIRMATION_REQUIRED: call request_agnta_grant_clear instead' and states 'A non-Lane-2 wallet clears directly.' This gives clear selection criteria.

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

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

With annotations already marking this as non-read-only and non-destructive, the description adds useful behavioral context: the action is free, records attribution, incurs a 15% clone-creator fee share, and returns a deployable template rather than performing deployment itself. These are beyond the schema but consistent 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 compact sentences front-load the action and then add only high-value workflow and cost details. Every clause earns its place; no redundant filler.

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

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

For a mutate-style tool with an existing output schema and annotations, the description covers the core behavior, cost, attribution, and the follow-up action (strategy create tools). It is slightly incomplete only in parameter-level detail and explicit sibling differentiation.

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 opening sentence maps template_id to the published strategy config and wallet_address to the destination wallet, which covers the required parameters. However, the description does not explain caller_id at all, and with 0% schema coverage the agent must infer type/format for the core 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?

Sentence one states a specific verb+object: 'Clone a published strategy config to a wallet' and adds the attribution nuance. It distinguishes the tool's role from the sibling strategy create tools by noting the returned config_template is meant for subsequent deployment.

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 frames the intended workflow: clone a published config, receive a config_template, then deploy via strategy create tools. This clearly signals when to use the tool, though it does not explicitly enumerate alternatives or exclusion conditions.

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?

Despite destructiveHint and non-idempotent annotations, the description adds substantial behavioral context beyond them: it explicitly says the tool returns an UNSIGNED transaction/payload, closes are geo-gated, the two-phase signed_transaction flow is supported, and idempotency_key replays the original result. This greatly helps the agent understand side effects and execution phases.

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 organized with parameter-scoped notes and front-loads the core purpose before getting into idempotency and two-phase execution. It is somewhat long and repeats the place_perp_order reference multiple times, but each sentence contributes behavioral or safety-relevant information.

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

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

The tool is complex (13 parameters) and the schema descriptions are absent, so the description carries a heavy burden. It covers the behavioral flow well, but leaves several defaulted and non-defaulted parameters unexplained and relies heavily on a sibling tool for crucial two-phase execution details. An output schema exists, but input semantics for parameters like wallet_address and pay_in_crank remain 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%, so the tool description must carry the parameter meaning; it does a good job for close_pct, position_id, jurisdiction, idempotency_key, verify, and signed_transaction. However, important parameters such as wallet_address, venue, pay_in_crank, payment_header, and acknowledge_tier_b receive no meaningful explanation, and the description defers a fair amount to place_perp_order rather than being self-contained.

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

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

The description states a specific action ('Close a perp position'), the resource, and the full/partial scope, and it adds important context about non-custodial venue settlement and unsigned signing payloads. It does not explicitly distinguish itself from close-related siblings such as perp_close, so it falls just short of full 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 explains mechanics like idempotency, jurisdiction, and two-phase execution, but it does not state when to choose this tool versus alternatives such as perp_close, cancel_perp_order, or perp_modify. It also does not mention when not to use the tool, aside from implicitly being for closing perp positions.

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, establishing safe read-only behavior. The description adds value by confirming 'No persist; read = FREE per the fee schedule' and detailing the validation checks. It also mentions the return of a normalized definition and validation report, providing extra 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?

The description is extremely concise: two sentences and a bullet list, with no redundant words. It front-loads the core purpose and key details, making it easy for an agent to quickly parse.

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 (one free-form object parameter), the description covers the essential purpose, behavioral traits, and validation checks. The output schema likely handles return value specifics. It omits details like output format or error handling, but the mention of 'validation report' and existing output schema mitigate this. A mention of example usage context would strengthen it further.

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% description coverage, meaning the single parameter 'definition' is completely undocumented in the schema. The description partially compensates by listing what the tool checks (schema, stream existence, rule-tree limits, risk caps, anti-gaming), implying required aspects of the definition. However, it still lacks explicit structure or required properties for the definition object, leaving ambiguity.

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

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

The description clearly states the verb 'Validate' and the resource 'composite definition'. It specifically says it returns a normalized definition and validation report, and distinguishes itself from sibling creation tools by explicitly stating 'No persist'.

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

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

The description provides context on when to use this tool: to validate a composite definition before creation. It enumerates specific checks (schema, stream existence, rule-tree limits, risk caps, anti-gaming rule), which helps the agent understand its applicability. However, it lacks explicit exclusions or alternatives, such as noting that this should be used prior to strategy_composite_create.

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 this is not read-only, not idempotent, and not destructive. The description adds valuable behavior beyond that: it creates a record, optionally applies policy presets, and can create a pending record for a Turnkey provisioning ticket to fill. It also discloses the return fields, which is useful context. 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 and well-structured: first sentence states the core purpose, second explains how the record is created and key parameters, third lists return values. Every sentence adds value with no fluff, and it is front-loaded with the most important information.

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

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

For a tool with 6 parameters and an output schema, the description covers the core mechanics (keyed by agent_id, policy presets, pending record flow) and return values. It does not explicitly explain how this relates to sibling lifecycle tools like enable_agent_wallet, but the context provided is sufficient for most 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?

Schema description coverage is 0%, so the description carries the burden. It does explain the semantics of default_policies (conservative | balanced | aggressive) and wallet_address (public key, optional, pending record behavior). However, it does not clarify agent_id, caller_id, display_name, or owner_address, leaving half the parameters under-explained.

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 begins with 'Register an agent wallet the caller controls (non-custodial control plane)', which is a specific verb+resource statement. It clearly distinguishes this from sibling tools like enable_agent_wallet, kill_wallet, and wallet_status by focusing on registration and creating an AgentWallet record keyed by agent_id.

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

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

The description provides clear context for when to use the tool — registering an agent wallet in a non-custodial control plane. It explains conditional usage (omit wallet_address for pending records) but does not explicitly name alternatives or exclusion criteria relative to sibling wallet tools, so it stops slightly short of a 5.

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

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

Annotations (readOnlyHint=false, destructiveHint=true, not idempotent, openWorld=true) are dramatically enriched by text explaining the timing and locus of side effects: 'NOTHING executes until the user opens the approval URL and signs', 'never signs and never sees a key', the distinction between proposing an intent (this tool) and executing (user action), fee-quote-baked-into-tx semantics, and the Reg S/OFAC compliance layer for security tokens. This converts a terse 'destructive + not idempotent' annotation into an actionable mental model.

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

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

The definition is genuinely front-loaded (the single most important fact — propose-only, user approval required — is first), and the return shape {intent_id, approval_url} is repeated for emphasis. However, at ~400 words it is long, and the FEE PARITY paragraph is bloated with internal design reasoning ('Decision: pay_in_crank IS exposed here...') and rationale ('Without this an intent proposed via this Lane 1 rail could be fee-classified differently') that an agent doesn't need to invoke the tool. There's also an empty link '(follow-up to )' and the return value is described twice. The meaningful info could be cut in half.

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

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

For a tool with 0% schema coverage and full behavioral annotations, the description covers the most safety-critical aspects: keys are never touched, nothing executes without user signature, fee parity is guaranteed, geo/OFAC gating applies, and amount units are pinned down. But it omits several agent-relevant behaviors: what happens on slippage/who passes validator keys, retry semantics for a non-idempotent call (the existence of idempotency_key is mentioned nowhere), and whether wallet_address must be pre-verified. The description is rich where it matters for compliance and safety, but thin on the operational edge cases an agent would hit when actually retrying or recovering.

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 and 11 parameters, the description carries the full documentation burden and only partially delivers. It explicitly documents amount ('in input-token base units'), implicitly documents pay_in_crank (quoted via the discount-aware classifier pipeline), jurisdiction (declared once for Reg S), and ip (origin for the identity-proof layer). But slippage_bps semantics on an unsigned proposal, allow_unverified behavior, idempotency_key semantics on a non-idempotent call, wallet_address binding, and the two token params are entirely undocumented.

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

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

The opening line 'Create a propose-only execution intent; returns an approval URL to hand to the user' pairs a specific verb with a clear resource and a distinctive behavioral qualifier ('propose-only') that separates this from a direct execution tool. The 'Lane 1 (non-custodial default)' framing further clarifies scope. It doesn't earn a 5 because it never names a sibling to differentiate from (e.g., jupiter_swap for direct execution), so an agent must infer the exact nature of the alternative path.

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 explicit follow-up guidance — 'poll get_intent_status and report ONLY the persisted on-chain state (CONFIRMED before any success claim)' — which is a clear directive on how to chain this tool with its sibling. The Geo Gate section tells agents which control applies ('same control jupiter_swap/trade_equity enforce') and the non-custodial framing implies the correct invocation context. However, it never explicitly says 'use X instead when you need direct (custodial) execution,' so the when-NOT-to call decision is left to inference.

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

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

Beyond the annotations, the description discloses key behavioral traits: the declaration is 'remembered for 90 days,' 'Re-declaring overwrites the prior value,' and it changes behavior from a permanent unknown-jurisdiction DENIED to an explicit reason. It also clarifies that this is a self-declaration, never advice, which is meaningful for a regulatory tool.

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

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

The description is longer than average but each sentence carries operational or regulatory substance, and the core action is front-loaded in the first line. The 'Gap:' paragraph is slightly verbose but explains a genuine integration nuance worth preserving.

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 regulatory complexity and the presence of an output schema, the description covers all needed context: when to call, persistence, cross-framework scope, limitations of a US-person declaration, and overwrite behavior. Nothing critical is missing for an agent to invoke the tool correctly.

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

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

With 0% schema description coverage, the description carries the parameter-semantics burden and does so well for jurisdiction: 'ISO-3166-1 alpha-2 country code,' self-declaration, and its legal effect. However, wallet_address, ip, and caller_id receive no explicit semantic explanation, though the first is inferable from the tool name and the others are optional metadata.

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

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

The description opens with a precise verb-resource pair: 'Declare your wallet's jurisdiction for geo-gated trading.' It also distinguishes the tool from siblings by explicitly naming trade_equity's jurisdiction param and the perps/short/leverage tools, so an agent can tell what this tool is and what it is not.

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

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

The description gives explicit when-to-use guidance: 'Call this ONCE (or pass jurisdiction= directly on any perps/short/leverage/trade_equity tool)' and explains the 90-day persistence. It also sets boundaries, noting that a US-person declaration does not unblock US-restricted venues, which prevents misuse.

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 a write operation (readOnlyHint=false) and openWorldHint=true. Description adds 'free control-plane write' but fails to disclose side effects, reversibility, or error states. For a destructive action, more context is expected 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?

Extremely concise (one phrase). It is front-loaded with the action, but lacks structure and depth. The brevity sacrifices useful details without achieving meaningful conciseness.

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

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

The tool has 3 parameters and an output schema, but the description provides minimal context. It does not address required parameters, error handling, or success behavior. The existence of an output schema reduces the need for return value explanation, but the description still needs to cover usage prerequisites and typical outcomes.

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 parameter meanings. It does not mention wallet_address, webhook_id, or caller_id. While parameter names are somewhat intuitive, format or constraints are omitted.

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

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

Description clearly states action (delete), resource (webhook subscriptions), and scope (one of a wallet's). It distinguishes from siblings like register_webhook and list_webhooks, providing a specific verb+resource combination.

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

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

The phrase 'free control-plane write' hints at low cost but does not explicitly state when to use this tool versus alternatives like register_webhook or list_webhooks. No guidance on prerequisites or 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?

The description goes well beyond the annotations by explaining that the tool is deterministic, returns raw indicator values for transparency, and makes no on-chain actions or fees. It also includes an explicit disclaimer that it provides "a suggestion only -- not financial advice, not a trade instruction (DYOR)." These details add behavioral context not captured in the readOnlyHint/idempotentHint/destructiveHint annotations, giving the agent a clear picture of the tool's side-effect profile.

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

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

The description is longer than average but every sentence adds value: it front-loads the core purpose, succinctly explains the output and parameters, notes limitations, and gives workflow context. It is well-structured with clear paragraphs and no filler. The length is justified by the tool's complexity and the need to disclaim financial advice.

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

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

The description is remarkably complete given the tool's complexity. It covers the input (asset and timeframe), the output (RegimeSignal fields and raw readings), the operational context (INTELLIGENCE step, pairing with other tools), and the boundaries (read-only, no on-chain action). Since an output schema exists, the description need not repeat return types, but it still provides enough detail to use the tool correctly.

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

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

With schema_description_coverage at 0%, the description must compensate for missing parameter details. It explains that "asset is a token mint" and lists valid timeframe values ("1m/5m/15m/1h/4h/1d"), which adds meaning beyond the bare schema types. However, it does not describe lookback_candles or caller_id at all. Since half of the parameters are undocumented in the description, the compensation is incomplete, 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's purpose with a specific verb and resource: "Detect the current market regime for a Solana asset." It also distinguishes itself from similar tools by detailing its unique output (RegimeSignal, ADX, +DI/-DI, etc.) and by referencing sibling tools like get_market_briefing and get_ml_signal as complementary, not replacements. The read-only and deterministic nature is also highlighted.

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: "pair with get_market_briefing (macro) + get_ml_signal (forecast)" and states that it feeds strategy choice and direction_mode. It also gives a concrete usage example: "bear + allow_short -> consider a short." It clearly positions itself within the INTELLIGENCE step and even references get_trading_workflow for further context, making when to use this tool unambiguous relative 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?

Matches annotations (read-only, idempotent) and adds 'free' and ranking details. Does not contradict 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?

Very concise (3 lines), front-loads purpose, and well-structured without unnecessary 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 purpose, filtering, ranking, and read-only nature. Has output schema and rich annotations, so missing param explanations for limit and caller_id are minor 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%, but description only explains the capability parameter with a list of values. No details on limit or caller_id, insufficient 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 'Find registered agents, optionally filtered to one capability,' with a specific verb and resource. It lists valid capabilities and distinguishes this from sibling 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?

Provides explicit context on filtering (capability list, empty = all) and ranking (by reputation then recency). Lacks explicit when-not or alternatives but is adequate for agent discovery 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 annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, and the description adds genuinely useful behavioral context beyond that: the tool is free, crypto-only, and the detail parameter changes the shape of each returned entry. It does not mention rate limits or pagination, but this is not critical given the annotation coverage.

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

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

Every sentence earns its place and the description packs filtering, ordering, default behavior, and output-shape semantics into a compact, structured format. It is information-dense without being bloated.

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 essential decision factors: scope, cost, platform limitation, filter semantics, sort semantics, and output shape. The output schema is also present, so return-value documentation is largely handled elsewhere. Minor omissions like limit bounds and caller_id semantics are not critical for a read-only 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?

The schema has no inline descriptions (0% coverage), so the description carries nearly the entire burden. It meaningfully explains strategy_type, sort, and detail, including allowed values and default behavior. However, limit and caller_id are not covered, even though limit's purpose is fairly inferable from 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 opens with a specific verb and resource combination, 'Browse published strategies', and immediately distinguishes the operation as read-only, free, and crypto-only. It also explains how the returned template_id feeds into clone_strategy, which separates it from other strategy-related siblings.

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

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

The description clearly frames the tool as a read-only strategy browsing utility and gives the selection conditions for filtering and sort modes. It also points forward to clone_strategy for the next step, but it does not explicitly say when to prefer this tool over strategy_list, get_strategy_leaderboard, or get_strategy_suggestions.

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 provide basic hints (readOnly false, openWorld true), but the description adds critical behavioral context: returns a pairing URL + device_code, requires wallet-signature gated approval in the user's own browser, forbids accepting in-chat consent, and references a spec section. These details go well beyond annotations and disclose the sensitive confirmation workflow.

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

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

The description is three sentences, front-loaded with the primary action. It then packs essential safety and next-step information without redundancy. Every sentence earns its place, making it 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?

An output schema exists, so return values are handled externally. The description covers the workflow (open handshake, show URL, require user approval, poll until done) and safety constraints. The only notable gap is the missing explanation of optional parameters (caller_id, display_name), which prevents 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 description coverage is 0% (no parameter descriptions). The description does not explain the three input parameters: agent_id, caller_id, and display_name. While agent_id is inferable as the target wallet, caller_id and display_name remain ambiguous, forcing the agent to guess their purpose. The description fails to compensate for the schema's lack of parameter documentation.

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

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

The description clearly states the tool's function: 'Open the browser-confirmation handshake for a Lane 2 agent wallet.' It explicitly differentiates from related tools by saying 'Does NOT create a wallet,' and specifies the output (pairing-style confirmation URL + device_code). This is a specific verb+resource with clear sibling distinction.

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

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

The description provides explicit when-to-use guidance: it's for enabling an agent wallet via browser confirmation, not for creation. It instructs to poll with poll_agent_wallet_enable(device_code) until status changes, and provides strong constraints (ask user to approve in their own browser, never accept in-chat 'yes'). This is actionable and contrasts 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 declare readOnlyHint=true and destructiveHint=false. The description adds that the tool is provider-backed and returns an honest empty payload with an SEC EDGAR link when no feed is configured, which is valuable behavioral context 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 three concise sentences with no wasted words. The core purpose is front-loaded in the first sentence, making it immediately 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?

Given the existence of an output schema and annotations, the description adequately covers the tool's behavior, including the empty payload case. It mentions tokenized equity and the Solana context, though it omits details on calendar field contents, which may be in the output schema.

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

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

With schema description coverage at 0%, the description must compensate for the two parameters (symbol, caller_id) but provides no explanation of their meaning or usage. The schema alone does not clarify purpose.

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 an earnings/dividend/split calendar for a tokenized equity, with a specific verb+resource. It distinguishes itself from siblings like equity_quote and equity_positions by focusing on corporate events.

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 overnight strategies via the 'after-hours-agent feature' but does not explicitly state when to use this tool over alternatives or when not to use it. No exclusions or comparisons are provided.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive. The description adds that it returns next open/close times and highlights the 24/7 trading advantage, which 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?

The description is brief at two sentences, but the final sentence about structural advantage is promotional and adds no technical guidance. It could be trimmed to only essential information.

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

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

While the description covers the output status values and next open/close behavior, it does not explain how the symbol parameter affects the results or how the availability flag is represented. Given the existence of an output schema, the description is moderately complete but has gaps.

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

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

Schema description coverage is 0%, meaning no parameter descriptions in the input schema. The tool description does not mention the parameters (symbol, caller_id) or explain their role, failing to compensate for the schema's lack of detail.

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

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

The description clearly states the tool provides NYSE session status and a 24/7-on-Solana availability flag. It lists possible status values (closed, pre_market, open, after_hours) and mentions next open/close times, making the purpose specific and actionable.

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 on when to use this tool versus siblings like equity_markets. The description does not specify when not to use it or which alternative might be better for related needs.

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 valuable context: source (admin-editable TokenRegistry), data quality ('best-effort' for prices), and special flags (NYSE status, 24/7-on-Solana). 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?

Three sentences, each adding value: first defines action and output, second adds source context, third enumerates fields. No redundancy or fluff.

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

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

The description covers source, data quality, and key fields. Given an output schema exists and the parameter is optional, this is nearly complete. Minor gap: no explanation of caller_id, but overall adequate for a list 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 has one optional parameter (caller_id) with 0% description coverage. The description does not mention this parameter or its purpose, leaving the agent without guidance on when or why to provide it.

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

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

The description clearly states 'List available tokenized equities' with specific fields (issuer, price, market hours, etc.), which distinguishes it from siblings like equity_quote or equity_positions. The verb 'list' and resource 'tokenized equities' are unambiguous.

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

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

The description implies usage for reading tokenized equity listings but does not explicitly state when to use it vs alternatives or provide exclusions. Context suggests it's the go-to for a catalog, but lacks explicit guidance.

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

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

Beyond annotations (readOnlyHint=true, idempotentHint=true), the description adds details about return fields (symbol, quantity, current_price, etc.) and notes that avg_cost/unrealized P&L are null until cost-basis tracking lands. 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?

Two sentences: first states core purpose, second adds key details. No extraneous information. 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 the tool's simplicity and the presence of an output schema, the description covers all necessary aspects: read-only behavior, filtering, fields, and a caveat about missing P&L. Complete for its complexity.

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

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

Schema description coverage is 0%, and the description does not explain the parameters beyond implying wallet_address is needed. caller_id has no explanation. The description should add meaning, but it doesn't compensate for the missing 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 'Tokenized-equity holdings for a wallet with live prices + market hours,' specifying a verb (holdings) and resource. It distinguishes from sibling tools like equity_quote or equity_corporate_events by focusing on holdings with live data.

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

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

The description explicitly notes 'Read-only' and 'Filters balances to registered equity mints,' providing clear context. It doesn't name alternatives or exclusions, but the purpose is sufficiently clear for selecting this tool over others.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by specifying the return contents (expected output, price impact, effective fee, slippage, SEC disclaimer) and clarifies the advisory nature of venue_hint, which goes beyond the annotations without contradicting them.

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

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

The description is concise, front-loaded with the read-only and no-execution note, and uses backticks for code-like parameters. Every sentence adds meaningful information without unnecessary verbosity.

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

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

The presence of an output schema reduces the need to detail return structure. The description covers the tool's purpose, key parameter semantics (amount, venue_hint), and returns conceptually. Minor gaps remain for unclarified parameters (symbol, caller_id, slippage_bps), but these are commonly understood in trading contexts and the overall intent is clear.

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 must compensate for parameter explanations. It clarifies 'amount' (base units of input token, USDC for buy, equity for sell) and 'venue_hint' (advisory). However, it leaves 'symbol', 'caller_id', and 'slippage_bps' unexplained, and 'side' is only implicitly connected to amount. The most critical parameters are covered, but several remain ambiguous.

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

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

The description clearly states a specific action: providing a read-only quote for a tokenized-equity trade, explicitly noting no execution. It distinguishes itself from related tools like trade_equity and jupiter_swap by emphasizing the read-only nature and the trade context.

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 key usage context: it clarifies the amount interpretation by side and notes that venue_hint is advisory, not required, with a pointer to trade_equity for execution. However, it does not explicitly state when to choose this tool over other quote-related tools (e.g., get_quotes) or provide 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?

The description goes beyond annotations by explaining that it returns an UNSIGNED base64 tx, reverts unless repaid in-transaction, verifies the borrowed token, requires x402 payment past the free tier, and supports idempotent retry. This richly discloses operational behavior and does not contradict the readOnly=false/destructive=true 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 front-loaded with the most important purpose and then covers the execution model, safety behavior, fee requirement, and optional idempotency semantics. Every sentence provides necessary information and there is no filler.

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

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

Given the complexity and 0% schema coverage, the description covers the core mechanics and safety profile well. It does not fully document all optional parameters or explain how to construct instructions beyond 'JSON ix', but it is near-complete for safe 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 coverage, the description compensates well for key params: instructions, allow_unverified, payment_header, and idempotency_key. However, caller_id and pay_in_crank are not explained, and amount, wallet_address, and marginfi_account rely on their names rather than explicit semantics.

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

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

The description opens with 'Marginfi flash loan for arbitrage (non-custodial, atomic)', which gives a specific verb, resource, and use case. It clearly differentiates this tool from generic lending tools like lend_borrow by emphasizing the atomic, non-custodial, borrow-plus-repay mechanics.

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 specifies the intended context: arbitrage, non-custodial, atomic, and repaid within the transaction. It does not explicitly say 'use this instead of X' or name alternative lending tools, so the guidance is clear but not exclusionary.

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

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

The description discloses key behavioral traits: non-custodial nature, fee calculation based on notional past a free tier, idempotency replay behavior when an idempotency_key is supplied, and the returned checkout_url and session_id. This goes beyond the annotations (which only indicate readOnly, openWorld, idempotent, destructive hints) and enriches the agent's understanding of side effects.

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

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

The description is relatively short but contains some cryptic elements (e.g., '(x500 payment_header)' appears to be a placeholder or typo that reduces clarity). It avoids redundancy, but the awkward phrasing around the fee and payment_header could be smoother.

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 and 8 parameters, the description covers the core flow and return values but lacks detailed explanations for several parameters and does not provide usage scenarios or edge cases. It is adequate for basic understanding but not fully comprehensive for an agent to invoke it correctly in varied contexts.

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

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

The description explains some parameters (amount_usd, payment_method with allowed values, wallet_address implicit, idempotency_key replay) but leaves several others unexplained: currency, caller_id, pay_in_crank, payment_header. Since the schema itself has no descriptions (0% coverage), any added meaning is helpful, but it's incomplete for a tool with 8 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 states a specific verb ('Fund'), a resource ('wallet'), and the method (via MoonPay) with a clear direction (fiat to USDC). It distinguishes itself from offramp tools by indicating the direction, and the mention of MoonPay provides a concrete implementation detail.

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 (funding a wallet with fiat) but does not explicitly say when to prefer this over alternatives like offramp_to_fiat or other payment tools. No conditional guidance or comparison to siblings is provided, leaving the decision partially implicit.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds the 'free' attribute and specifies the data returned (profile + referral stats), providing value 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?

A single sentence that conveys the tool's essence with no extraneous words. Every word earns its place.

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

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

The tool is a simple read operation with 2 parameters and an output schema. The description is complete for the purpose but lacks parameter documentation, which is a notable gap.

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

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

With 0% schema description coverage and no parameter information in the description, the agent must infer from parameter names. The description adds no meaning beyond the schema, failing to compensate for the coverage 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 uses the specific verb 'Read' and identifies the resources 'published profile' and 'referral stats'. It clearly distinguishes from sibling tools like 'update_agent_profile' and other read 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 includes 'read-only, free' which implies when to use (read operations, no cost) but does not explicitly state when not to use or mention alternatives. The context is clear enough for an agent.

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

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

Beyond the annotations, the description explains record shape, field sets, concise/full modes, and the fact that only active venues appear. It also tells the agent that venue is the ID to chain into get_venue_health, which is useful behavioral context not present in the annotations.

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

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

The description is compact and front-loads the main purpose. It explains the field modes clearly in a deliberately chosen format; the only minor redundancy is repeating "Read-only" when the annotations already declare readOnlyHint.

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 and read-only/idempotent annotations are provided, the description covers invocation intent, record shape, and a sensible follow-up tool. It could be slightly more explicit about the decision between get_all_venues_status and get_venue_status, but nothing essential to invoking the tool correctly is missing.

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

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

The description compensates for the 0% schema coverage by explaining `detail` values: "concise" trims records and "full" adds deploy slot, TVL, volume, and uptime. It does not explain `caller_id`, but that parameter is optional with a default and seems peripheral to functionality.

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

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

The description clearly identifies a specific resource: a dashboard overview of all configured venues with per-venue health records. It states the operational purpose, routing decisions, and distinguishes itself from single-venue tools by emphasizing 'all' and 'one health record per active venue.'

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

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

The description gives clear context: use this as an overview when picking a venue in a single call, and it even points to get_venue_health as the follow-up. It does not explicitly state exclusions like 'use get_venue_status for a single venue,' but the intended workflow 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, destructiveHint=false, etc. The description adds valuable behavioral context: the data is 'already-debounced' requiring consecutive polls, and is 'decision-support 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 front-loaded with the core purpose, followed by concise technical details, disclaimers, and workflow integration. Every sentence adds value without redundancy or fluff.

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

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

Given that an output schema exists (not shown), the description need not detail return values. It explains episode content (venue pair, spread, times, reference price), limitations, and integration with a sibling tool. Combined with annotations, this provides a complete picture.

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 the description must explain parameters. It mentions 'assets,' 'min_spread_bps,' and 'window_hours' with clear semantics. However, 'caller_id' is not referenced. Despite this omission, the description provides sufficient meaning for the majority of 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 defines the tool as retrieving 'Persisted cross-venue discrepancy episodes (free read),' explicitly distinguishing it from the sibling 'get_cross_exchange' by noting it is persisted and debounced versus a 'current live-ish read.' The verb 'get' and resource 'arb discrepancies' are specific and unambiguous.

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

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

The description provides explicit usage guidance: it is an 'INTELLIGENCE step' to be paired with 'get_cross_exchange' for live reads. It also states limitations ('ignores fees, slippage, and transfer latency; never an execution instruction'), clearly defining when not to use the tool.

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

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

In addition to the readOnly hints, the description reveals how the response changes based on `detail`, including the default output shape (total_usd, count, trimmedbalance entries) and the fuller shape of `full`. It also notes that returned IDs are meant for chaining, giving the agent useful expectations for downstream.

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: three sentences are tightly focused: what it returns, how modes differ, and how to position. It fits an agent workflow and uses non-redundant phrasing.

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

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

With an output schema in place, a robust annotations block, and active description detailing mode semantics and workflow ordering, the entry is complete. The`caller_id` is the only marginal gap, and it's not essential to tool selection or core invocation correctness.

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

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

The description adds a lot for `detail`, detailing the default value and exact effect of 'uscise' vs 'full'. However, it does not explain `caller_id` at all, and `wallet_address`'s format or validation behavior is not explicitly documented. Given 0% parameter description coverage in the schema, the description partially but not fully compensates.

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

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

The description states the exact resource and scope: wallet token balances covering SOL plus all SPL tokens, and adds USD valuations. It further distinguishes itself by explaining the concise/full response modes and placing itself as the ORIENT/starting read, which is clearly distinct from nearby wallet-focused sibling tools.

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

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

The description explicitly names and marks this as 'ORIENT step' and the starting read 'for any flow', which tells an agent exactly when it should be selected. The instruction 'See get_trading_workflow' and the IDs 'for chaining into e.g. get_quotes' provide concrete routing guidance and references to related tools.

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

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

Beyond the annotations, it discloses that nothing is charged, no order is created, and returns estimated destination amount, per-leg USD values, and DLN protocol costs. This meaningfully extends the readOnlyHint into concrete behavioral expectations.

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

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

The description is well-structured and front-loaded with the most important information: free read and no execution. Every sentence earns its place, covering purpose, semantics, supported chains, return values, and usage context without redundancy.

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

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

The description is strong overall: it covers safety, parameter roles, supported chains, and precedes the execution siblings. The remaining gaps are minor but real — the exact token identifier format and caller_id semantics are not addressed — though the output schema likely covers return expectations.

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 that amount is in source-token base units, what src_token/src_chain and dst_token/dst_chain mean, and listing supported chains. However, it leaves caller_id unexplained and does not specify whether tokens are addresses or symbols.

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

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

The description names the operation (quote), the resource (cross-chain bridge via deBridge DLN), and explicitly disambiguates from execution tools by saying 'FREE read, no execution.' It clearly distinguishes itself from siblings like bridge_in and bridge_out.

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 the intended workflow position: 'Use before bridge_in / bridge_out.' It also tells the agent that no order is created, clarifying that this is a pre-flight quoting step, not an execution step.

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 directly contradicts the readOnlyHint annotation: it says the tool 'best-effort updates the matching BridgeTransfer row,' which is a write operation despite readOnlyHint=true. This is a significant safety-relevant inconsistency that should be flagged.

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

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

The description is dense but well-structured, front-loading the core action and then providing useful context about the underlying mechanism and return values. It is slightly longer than strictly necessary, but each sentence contributes meaningful information.

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

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

The description covers the operation's trigger, external behavior, return mapping, and internal side effect. With an output schema present and annotations covering idempotency and non-destructiveness, the main gap is caller_id documentation and the conflict with readOnlyHint.

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

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

The description adds useful meaning for order_id by explaining that it is returned from bridge_in/bridge_out. However, caller_id is not explained at all, and the schema has 0% description coverage, so one parameter remains semantically 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 identifies a specific action—polling a dispatched DLN bridge order's fulfillment status—and clearly ties it to bridge_in/bridge_out as a follow-up. It names the external endpoint and the returned values, making it easy to distinguish from other status 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 states explicitly that this is a follow-up to bridge_in/bridge_out and explains why polling is necessary (the order stays 'pending'/'broadcast' in Crank's record unless polled). It does not list alternatives or when not to use it, but the context is clear enough for an agent to route correctly.

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 non-destructive behavior. The description goes beyond this by disclosing that only active, current insights are ever returned, that detail=full changes the payload, that every response is historical aggregated data, and that it is descriptive only and never a recommendation. 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?

The description is dense but well organized: a one-line summary, filter details, returned-field semantics, a behavioral caveat, then workflow placement. Every sentence contributes, though there is slight redundancy between 'historical performance data' in the first line and 'historical collective performance data' later.

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 and strong read-only annotations, the description covers purpose, filter semantics, output contents, safety behavior, and usage workflow. The main missing pieces are an explanation of caller_id and the default behavior when no filters are provided, which keeps it from being fully complete.

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

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

Schema description coverage is 0%, so the description carries the parameter-documentation burden. It clearly defines asset (mint/symbol), names strategy_type as a filter, gives a full enum for insight_type, and explains the effect of detail=full. However, caller_id is never explained, and strategy_type valid values are not enumerated, leaving partial 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 opens with a specific verb+resource pair: 'Fleet-wide collective insights, historical performance data (free read).' It then enumerates the exact insight types and fields returned, and positions the tool within the INTELLIGENCE workflow alongside get_market_briefing / get_consensus, which differentiates it from the many other get_* read tools in the sibling list.

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

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

The 'Workflow: INTELLIGENCE step' sentence explicitly tells the agent when to use this tool: for fleet-wide context before sizing or creating strategies, alongside get_market_briefing and get_consensus. The 'never a recommendation' caveat also clarifies that output should not drive direct execution. However, it does not provide explicit when-not-to-use guidance or name alternatives to prefer in specific 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 declare readOnlyHint, openWorldHint, idempotentHint true and destructiveHint false. The description reinforces these by stating 'Descriptive signal only, not a recommendation' and 'Not financial advice.' It adds billing context and explains the consensus score range, exceeding what annotations alone 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 front-loaded with the purpose in the first sentence, followed by detailed explanation and a clear workflow section. No redundant sentences; each adds value. Length is appropriate 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 5-parameter tool with 0% schema coverage and no output schema details, the description provides comprehensive context: premium tier, billing, consensus scoring ranges, source breakdown, and workflow pairing. It is fully complete for an agent to understand usage.

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 carries the burden. It effectively explains 'asset', 'window_hours' (with default 24), and mentions 'payment_header' for billing. However, 'caller_id' and 'wallet_address' are not explained, leaving some ambiguity. Still, the main parameters are well-covered.

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

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

The first sentence clearly states the verb 'get', the resource 'multi-source consensus + contrarian read for one asset', and distinguishes from siblings by specifying 'PLATINUM premium' and the 'INTELLIGENCE step' workflow context. It is specific and unique.

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: 'Workflow: INTELLIGENCE step -- pair with get_market_briefing + get_source_accuracy to gauge how crowded a directional read is before sizing.' It also explains premium tier and payment process, telling the agent when this tool is appropriate.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, destructiveHint false. The description adds behavioral details: scans over window_hours, returns assets with high/low agreement, billing outcome in 'billing', and states it's 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 front-loaded with the main purpose and includes necessary details (billing, disclaimer). It is organized but slightly long. Each sentence adds value, though some could be more concise.

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 main functionality and billing context, but missing descriptions for caller_id and wallet_address parameters. With 0% schema coverage, more detail is needed for full understanding. Output schema exists but is not shown, so return values are partially explained.

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 window_hours (time window), asset (filters to one asset), and payment_header (via x402 payment). However, it does not describe caller_id or wallet_address, 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 scans for contrarian (crowded) and uncertain assets based on source agreement, with a specific verb 'scans' and resource 'classified intelligence signals'. It distinguishes itself by mentioning 'PLATINUM premium' and 'contrarian' vs. other signal tools, but does not explicitly differentiate from siblings like get_signals or get_ml_signal.

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 context: 'Workflow: INTELLIGENCE step -- surface crowded trades to fade or uncertain assets to avoid before committing to a regime/allocation.' This implies when to use it (before committing) and that it's descriptive only. However, it lacks explicit exclusions or alternative tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds meaningful behavioral context: how the score is accrued (on-platform activity), the penalty for circular funding, and the 'well-formed zeros' response for unscored wallets. This goes beyond mere annotation repetition and helps the agent understand the tool's behavior and output nuances.

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 efficient and well-structured. The first sentence is a clear summary, followed by a compact enumeration of return fields and a note on behavior. No filler or repetition; every sentence adds value. It is front-loaded with the tool's essence and additional details are logically ordered.

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 return fields extensively, including gates and penalties, and even notes the behavior for unscored wallets. The only gap is the lack of explicit parameter documentation, but since the output schema is present (as indicated by the context signal) and the main parameter is obvious, the description is sufficiently complete for an agent to invoke the tool correctly. It could still benefit from mentioning the caller_id parameter or any possible error conditions, but overall it is near-complete.

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

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

Schema description coverage is 0%, so the description must compensate. It implicitly makes clear that 'wallet_address' is the key input (by describing a wallet's score), but it does not explicitly describe either parameter. The optional 'caller_id' is not mentioned at all, and there is no guidance on formats or expectations. Given the required parameter is self-explanatory, the description partially compensates, but the lack of explicit parameter documentation prevents a higher 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's function: retrieving a wallet's Crank Score reputation breakdown. It specifies the resource (wallet) and the exact output fields (total_score, components, sybil_flagged, gates, etc.), distinguishing it from the many sibling get_* tools by naming the specific 'Crank Score' concept. No ambiguity.

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

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

There is no explicit guidance on when to use this tool versus alternatives. The description mentions 'FREE read' but does not explain the difference from other score-related tools like get_score or get_my_contribution_score, nor does it specify conditions (e.g., 'use this when you need the full breakdown'). An agent would have to infer usage from the purpose, which is not ideal given the large sibling set.

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. The description adds important caveats: spreads ignore fees/slippage/latency, data is 'decision-support only', and the tool is a 'free read'. 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 front-loaded with the summary sentence, then a bullet-like list of data fields, and ends with a workflow tip. Every sentence adds value; no fluff. Appropriately sized for the tool's complexity.

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

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

Given the output schema exists and the tool is relatively simple, the description provides enough context for the agent to understand the tool's purpose and limitations. However, the lack of parameter explanations (especially for window_minutes) slightly reduces completeness, as the agent may not know how to correctly set the time window.

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). The description fails to explain the parameters: 'asset' is implied but not explicitly defined, 'window_minutes' is not connected to the listed movement windows (5m/1h/24h), and 'caller_id' is completely unaddressed. The description relies on common sense but does not add sufficient meaning beyond parameter 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?

The description clearly states it provides a 'Cross-venue snapshot for one asset (free read)' and lists specific data points (price/bid/ask/movement, spread matrix, wrapped-asset premium). It distinguishes from sibling tools by noting pairing with get_arb_discrepancies for episode history.

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 frames it as an 'INTELLIGENCE step', advises pairing with get_arb_discrepancies, and warns against using as execution instruction or financial advice. These guidelines help an agent decide when to use this tool versus 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 read-only, idempotent, and open-world behavior. The description adds context about the SEC framework, asset classification, and a separate notice for equity, which improves transparency beyond the annotations.

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

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

Three efficient sentences with clear front-loading of purpose, followed by input options and a reference to full text. No unnecessary words.

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

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

For a simple read-only tool with an output schema, the description covers the core functionality and input options adequately. The only missing detail is 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 the main parameters: asset_classification (with enumerated values) and token_address/symbol for classification. The caller_id parameter is omitted, 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 retrieves compliance disclaimers for an asset class under the SEC framework. It specifies accepted asset classifications and alternative identifier inputs, distinguishing it from sibling tools.

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

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

The description explains when to use the tool: to get disclaimers for an asset. It provides guidance on input options (asset_classification vs. token_address/symbol) and notes a special case for equity. However, it does not explicitly contrast with 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?

Despite strong annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint), the description adds meaningful behavioral context: anonymization, never returning wallet/cohort keys, aggregate historical data, staleness, descriptive-only nature, and 'never a recommendation or a promise of results.' It also clarifies the read-only nature with 'free read.' 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 opens with a compact one-line summary, then provides return details, filters, privacy guarantees, and workflow context in a logical order. Every sentence adds value; no filler or repetition.

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

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

It covers what the tool returns, how to filter, privacy behavior, and when to use it. The output schema presumably covers structured return values, so that is not required. Minor gaps include the ordering criterion for 'ordered behaviour motifs' and the meaning of 'staleness,' but the description is still largely sufficient for correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It explains min_agents ('Filter with min_agents') and limit ('caps the result count (max 100)'), but leaves caller_id completely unexplained. This is a partial gap given the low schema coverage.

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

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

The description uses a specific verb ('Returns') and a concrete resource ('ordered behaviour motifs -- sequences of (regime, signal_key, action, outcome_sign) steps'). It clearly distinguishes itself from sibling intelligence tools by emphasizing motifs that map to NO existing strategy type, so an agent can tell it apart from get_collective_insights, get_signals, and similar get_* tools.

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

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

It explicitly frames usage as an INTELLIGENCE step before designing a new strategy ('see what the fleet is doing that no existing strategy type describes, before designing a new strategy'). It does not name alternative tools or state when not to use it, but the workflow guidance is clear enough for selection.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds value by explaining the health factor meaning and return fields, which goes beyond what annotations provide. 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 extremely concise with two sentences, front-loading the core purpose and critical output details. No extraneous 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 tool's simplicity and presence of an output schema, the description adequately covers the purpose, output fields, and protocol constraints. It misses optional parameter explanations but is otherwise complete for a query 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%, so the description must compensate. It only mentions protocol (kamino/marginfi) but does not explain wallet_address, market, marginfi_account, or caller_id. This leaves significant gaps for a 5-parameter tool.

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

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

The description clearly states it monitors liquidation risk for lending positions, returning health factor with thresholds (>1 safe, <1 liquidatable) along with collateral/debt values. It specifies supported protocols (kamino, marginfi), distinguishing it from siblings like get_lending_rates or set_liquidation_alert.

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 liquidation risk but lacks explicit when-to-use or when-not-to-use guidance. It does not differentiate from other getters or state alternatives. Given the straightforward nature of a query tool, the implicit guidance is adequate but not exemplary.

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

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

Annotations already mark it read-only and non-destructive. The description adds transparency about aggregation (no per-wallet data), the mainnet/devnet distinction, and the explicit 'no promise' caveat, which is valuable 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?

Front-loaded with the core purpose expect, then details the metric definition, cluster behavior, and data scope. Dense but well-structured; could be trimmed slightly but each sentence adds meaning.

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, return metrics (gate_met, counts, transaction definition), cluster semantics, data aggregation limits, and the non-committal nature. Nothing essential is missing for an agent to call it correctly.

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

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

Schema has no descriptions; the description explains the 'cluster' parameter (devnet vs mainnet) but leaves 'caller_id' entirely unexplained. Partial coverage, with the critical parameter 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?

States a specific resource (ILO adoption gate) with a clear verb ('reads') and immediate distinction from sibling tools by defining the metric and its scope. The description makes the purpose unmistakable.

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

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

Explains the gate's role, the devnet vs mainnet choice for observability, and explicitly notes it's informational only (‘not a promise…’). It doesn't name alternative tools, but the context is sufficient for an agent to decide when to call 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, idempotentHint, openWorldHint, and non-destructive behavior; the description adds materially to that by clarifying the tool reads live on-chain data, is free, returns a machine-readable schedule for planning claim_ilo_tokens calls, and that escrow is non-custodial. This helps reason about side effects and timing 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 carefully structured: a one-sentence overview, a backtick-delimited note on launch_id, then the caller_wallet caveat, the fair-launch usage context, and the recommended workflow. Every sentence earns its place, and the important usage guidance is front-loaded.

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

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

Given the rich annotations, an output schema, and the description's own enumeration of the returned content, nothing essential is missing. The description covers purpose, key parameters, workflow, alternative tools, and behavioral caveats.

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 shoulders the burden for parameter meaning. It clearly explains launch_id as an on-chain u64 identifier and explains the optional caller_wallet effect and cap semantics (0 = uncapped). However, the caller_id parameter is never mentioned, which is a small but real 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 opens with a specific verb and resource: 'Read a token launch live from chain', and enumerates the concrete data returned: terms, status, escrow balances, and release schedule. It also explicitly differentiates itself from get_my_pledge_status, so an agent can distinguish which tool is authoritative for per-wallet data.

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

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

The description provides a concrete workflow: use it in the DISCOVER step, read details, check the launch window and per-wallet cap, then preview with pledge_to_ilo before committing. It also names get_my_pledge_status as the authoritative per-wallet alternative, making routing decisions explicit.

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

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false. The description adds that it computes readings only, involves no wallet/fee/on-chain action, and that readings are None while history is warming up. This goes beyond annotations and clarifies behavioral traits.

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 lengthy but well-structured with a clear opening, bullet-like listing of indicators, parameter explanations, and workflow context. Every sentence adds value; it is efficient for its 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 tool's complexity (multiple indicators, parameters, output schema exists), the description covers input semantics, behavior during warm-up, workflow integration, and disclaimers. No gaps remain for an informed selection and invocation.

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

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

Schema description coverage is 0%, so the description fully compensates by explaining each parameter: asset is a token mint, timeframe with allowed values, indicators as a subset array, params as a JSON override, lookback capped at 500, include_series for per-bar data. It also describes the output indicator structure with examples.

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

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

The description clearly states the tool computes the full standard technical-indicator set for one asset/timeframe, specifying it is read-only. It lists the indicators (sma, ema, etc.) and differentiates from sibling tools by labeling it as an INTELLIGENCE step and suggesting pairing with get_ml_signal, get_signals, etc.

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 context: it's for raw indicator readings as part of a workflow, not financial advice, and readings are None during warm-up. It mentions pairing with detect_regime, get_ml_signal, get_signals, and refers to get_trading_workflow. However, it does not explicitly state when not to use or alternatives beyond these 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?

The description states 'Read-only', which aligns with annotations (readOnlyHint=true). It adds minor context about the data scope (per-action, per-month) but does not disclose any additional behavioral traits beyond what annotations already provide. With annotations covering the safety profile, a 3 is reasonable.

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 extremely concise at two short fragments, but the conciseness comes at the cost of missing essential information like parameter details. It is not well-structured for an agent to understand how to invoke the tool correctly.

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 existing, return values are covered externally. However, the description lacks parameter semantics, usage context, and any behavioral nuances beyond read-only. For a tool requiring a wallet address, the omission is significant.

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 fails to explain any of the three parameters (limit, caller_id, integrator_wallet_address). The phrase 'per-action + per-month' hints at aggregation but does not clarify parameter roles or defaults. This is a critical 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 retrieves integrator earnings, specifying 'per-action + per-month' and 'onboarding API', which provides a specific verb-resource combination. However, it does not differentiate from sibling tools like get_integrator_stats, so a 4 is appropriate.

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 on when to use this tool versus alternatives, no conditions or prerequisites. The description simply states what it does without any contextual usage advice.

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 (readOnlyHint, idempotentHint), the description explicitly clarifies that all figures are fee-share USD, not PnL or performance-share, adding valuable behavioral context not inferable from annotations alone.

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 extremely concise, using two clear sentences with no redundancy. The first sentence lists the data categories; the second clarifies the fee-share nature. 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?

While the output schema presumably covers return structure, the description omits critical context like the required integrator_wallet_address parameter, prerequisites, or a more detailed breakdown of the dashboard fields, making it incomplete for a tool with no parameter documentation.

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 fails entirely to explain the two parameters ('caller_id' and 'integrator_wallet_address'), their meaning, or how to use them, leaving the agent without necessary 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 it provides an integrator dashboard including status, share, onboarded count, and earnings breakdown, using a specific verb-resource combination. It distinguishes itself from the sibling tool 'get_integrator_earnings' which focuses only on earnings.

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

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

Usage context is implied (for integrators wanting a dashboard overview), but no explicit guidance is given on when to use this tool versus alternatives like 'get_integrator_earnings' or conditions for use.

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