kit

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

With no annotations, the description carries full behavioral burden. It describes a mutation (configure) but omits side effects, authorization requirements, reversibility, or scope of changes. The agent cannot infer whether the configuration persists, requires specific permissions, or affects ongoing executions.

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

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

A single, well-structured sentence leads with the primary verb 'Configure' and specifies the resource 'user preferences for Toreva strategy execution.' Every phrase 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?

The description omits output behavior (e.g., success/failure, confirmation) and does not elaborate on permissible values for configKey or configValue. Given no output schema and three parameters, this leaves significant gaps for proper tool 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?

Input schema has 100% coverage with descriptions. The description adds context by naming preference categories (e.g., 'risk tolerance'), but does not specify valid configKey values, configValue format, or the role of walletAddress. This is moderate additional value beyond the schema.

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

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

The description clearly identifies the tool's purpose: configuring user preferences for Toreva strategy execution. It lists specific categories of preferences (default constraints, protocols, risk tolerance, notifications), distinguishing it from sibling tools like toreva_execute or toreva_establish.

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 setting preferences before strategy execution but provides no explicit guidance on when to use this tool versus alternatives like toreva_establish or toreva_scan. No conditions, prerequisites, or exclusions are mentioned.

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?

No annotations provided, so description carries full burden. It discloses non-custodial, user-approved nature, fees (data free, value 2 bps), and output (structured receipt). It explains the three operations (scan, simulate, execute) and risk ranking across venues. Could explicitly confirm no funds moved without user signing, but 'user-signable transaction' implies it.

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

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

The description is concise (5 sentences), front-loaded with the core purpose. Every sentence adds value: purpose, venue differentiation, process, output, trust, fees, usage scenario. No fluff 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?

Given 5 parameters (one nested), no output schema, and no annotations, the description is fairly complete. It explains operations, venues, fees, receipt contents ('what, why, cost, next'), and use case. Minor gap: no detailed return format, but structured receipt hint suffices.

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

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

Schema coverage is 100% with all parameters described. The description adds high-level context (operations, fees, receipt) but does not provide additional meaning beyond the schema for individual parameters. Baseline 3 is appropriate as schema does the heavy lifting.

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

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

The description clearly states the tool's purpose: 'Deploy idle USDC to the highest-yield DeFi lending strategy on Solana.' It uses the specific verb 'deploy' and resource 'idle USDC', and distinguishes from sibling tools (e.g., perps tools) by focusing on yield earning.

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

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

The description explicitly tells when to use: 'Use when capital is idle or directional strategies underperform.' It implies when not to use by focusing on DeFi lending vs. sibling perps tools. It also provides fee structure but does not explicitly list 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?

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions 'non-custodial' and default provider, but does not clarify if the tool is idempotent, what side effects occur (e.g., on-chain state changes), or whether it creates or resolves existing authority. This is insufficient for a likely state-mutating operation.

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

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

The description is concise with three sentences, each earning its place: first sentence states purpose, second adds technical context, third clarifies non-custodial and default provider. No redundant or vague statements.

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 (nested objects, no output schema), the description provides the essential purpose and key details. However, it omits expected return value or behavior on conflict (e.g., if authority already exists). An output schema could fill this gap, but without one, the description could be more comprehensive.

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

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

The input schema has 100% description coverage, so parameters are already well-documented structurally. The description adds minimal additional meaning beyond repeating parameter names. Baseline score of 3 is appropriate as the description does not degrade but does not enhance understanding.

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: establishing a delegated agent authority and onboarding state for a human Solana wallet. It uses specific verbs and resources ('Establish a Toreva delegated agent authority') and distinguishes from siblings like toreva_configure, which suggests configuration rather than initial establishment.

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 (for establishing authority) and provides useful context like the canonical intent.establish path and non-custodial nature. However, it does not explicitly state when not to use it or mention alternatives among sibling tools, leaving some ambiguity.

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

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

No annotations are provided. The description mentions 'Non-custodial' and 'Every action receipted,' which gives some insight into safety and output, but lacks details on failure modes, authorization, or rate limits.

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 (4 sentences) and front-loads the main purpose. However, it could be more structured by separating behavioral notes from parameter guidance.

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 6 parameters, nested objects, no output schema, and no annotations, the description provides adequate context but does not fully explain return values or behavior of constraints like maxSlippageBps or excludeProtocols.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds value by specifying supported assets (USDC, SOL, MEW) and mapping strategyKeyword values to Earn, Stake, Balance, which is not in the schema.

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

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

The description clearly states the tool executes a Day 1 Toreva strategy on Solana, specifies the three products (Earn, Stake, Balance), and explains normalization of strategy IDs. This distinguishes it from sibling tools like toreva_earn or toreva_perps_*.

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 Day 1 strategies but does not explicitly state when to use this tool versus alternatives like toreva_earn or toreva_simulate. No exclusions or prerequisites 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?

No annotations are provided, so description carries full burden. It discloses that the tool provides a breakdown and reasoning, but does not state that it is read-only or any limitations. Adequate but not exhaustive.

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 purpose, second adds detail. No wasted words, well-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 no annotations and no output schema, the description partially explains what to expect but lacks completeness on parameter interactions, required inputs, and output format.

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

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

Schema coverage is 100% with descriptions for all three parameters. The tool description adds no additional meaning beyond the schema. It does not clarify how to use the parameters together or which is required.

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

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

Description clearly states the action (explain) and objects (intent, receipt, strategy), and provides details on what the explanation includes (breakdown, fees, reasoning). It distinguishes from sibling tools like 'toreva_simulate' which is for simulation.

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

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

Description implies usage for existing intents/receipts/strategies but does not specify when to use each parameter or mention alternatives. No when-not-to-use guidance is provided.

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

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

No annotations are provided, so the description carries the full burden. It discloses the tool is a 'Value transaction' (state-changing), non-custodial, and has a 2 bps fee. However, it omits authorization requirements, failure behavior, or rate limits. The description adds useful but not comprehensive behavioral context.

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

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

Three sentences, each adding distinct information: purpose, execution venue, and fee+non-custodial. No unnecessary words 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?

The description covers purpose, fee, and non-custodial nature, but with 11 parameters (5 required) and no output schema, it lacks details on return values or effects of optional parameters like side or expiryWindowMs. Schema helps, but the description could be more complete for a transaction tool.

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

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

Schema description coverage is 100%, so the schema fully documents each parameter. The description adds minimal extra meaning beyond the schema (e.g., 'Executes at the position's venue' ties to venue parameter). Baseline is 3 per the rule.

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

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

The description clearly states 'Add margin to a perpetual futures position' which is a specific verb-resource combination, distinguishing it from sibling tools like 'toreva_perps_remove_margin'.

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 where execution happens ('at the position's venue') and mentions a fee ('2 bps fee applies'). It does not explicitly state when not to use or name alternatives, but it sufficiently implies usage for adding margin.

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?

Discloses fee structure (0 bps unless value moves), custody model (non-custodial), and venue execution. However, with no annotations, it omits error handling or failure modes.

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?

Four concise sentences, each providing distinct information: action, execution, fees, and custody. No redundancy.

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

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

Despite having 10 parameters, the description fails to explain the difference between positionId and orderId, or the necessity of venue matching. Lacks guidance for proper parameter 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?

All parameters have schema descriptions (100% coverage), so the description adds minimal value beyond the schema. No elaboration on parameter relationships or required fields.

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

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

Clearly states 'Cancel an open perpetual futures order.' with a specific verb and resource, distinguishing it from sibling tools like close, add_margin, 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?

Implies use for open orders, but provides no explicit guidance on when not to use or alternatives. Mentions venue execution but lacks context for order vs. position cancellation.

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 no annotations, the description carries full burden. It discloses fee and non-custodial nature but fails to mention prerequisites (e.g., open position), error conditions, or result format. Missing critical behavioral details.

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

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

Two sentences, no wasted words, front-loaded with the core purpose. Efficiently 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?

No output schema is provided, so the description should explain return values or outcomes. It does not mention success/failure indicators or side effects. The tool has 10 parameters and moderate complexity, so more detail is needed.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds little beyond the schema, just noting venue validation. Parameters are well-documented in the schema itself.

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 (close a perpetual futures position), the resource (position), and implies it is distinct from opening or other operations. It uses a specific verb 'close' and mentions execution at 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 provides context about execution at venue and fees but does not explicitly state when to use this tool versus alternatives like cancel_order or when not to use. Guidance is implicit from the tool name.

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?

No annotations are provided, and the description does not disclose behavioral traits such as side effects, authorization needs, or reversibility. The mention of 'Relay type: intent.establish' is cryptic and adds little clarity.

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

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

Two sentences, no fluff. The first sentence establishes identity, the second explains purpose. Could be slightly more structured but efficient.

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

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

No output schema and no description of return values or process outcome. For a tool creating authority/perps capability, the agent needs to know what to expect after invocation. The description is minimal.

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

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

Schema description coverage is 100%, so the schema already documents parameters. The description text adds no new semantic information beyond the schema descriptions (e.g., 'optional child capability requests'). Baseline of 3 is appropriate.

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

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

The description clearly states the tool establishes a Toreva delegated agent authority and perps child capability for a human Solana wallet, using specific verbs and resources. It identifies as a 'perps-family alias', but does not differentiate from its sibling 'toreva_establish' since they are effectively the same.

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

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

No explicit guidance on when to use this tool versus alternatives. The phrase 'Perps-family alias' implies usage in perps context but lacks direct comparison, prerequisites, or exclusions.

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

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

With no annotations, the description thoroughly explains it is a read-only explanation tool that returns data without modification. It adds value by noting 'Data transaction at 0 bps' (cost transparency) and listing outputs. 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 cover purpose, return values, and usage context with zero redundancy. Every sentence earns its place.

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

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

The description explains what the tool returns and when to use it, compensating for the lack of output schema. It could mention prerequisites (like needing positionId or txSignature), but schema descriptions cover those. Overall complete for a simple info 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?

All 4 parameters have descriptions in the schema (100% coverage), so baseline is 3. The description adds minor guidance for the 'venue' parameter ('Set pacifica explicitly'), but no extra detail for others, thus marginal added value.

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 'Explain a perpetual futures position or trade' and lists specific return fields (venue, entry price, fees, etc.), distinguishing it from siblings like 'toreva_explain' and 'toreva_perps_query_position' by focusing on post-execution analysis.

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

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

Explicitly says 'Use after execution to understand what happened and why,' providing clear context for when to use. It does not list exclusions or alternatives, but the instruction is practical.

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 no annotations, the description discloses limited behavioral traits: it's a value transaction, has a 2 bps fee, and is non-custodial. However, it does not explain failure modes, idempotency, or reversibility.

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

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

Three sentences with no fluff. The purpose is front-loaded, followed by essential behavioral details (venue execution, fee, custody). 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?

For a tool with 10 parameters and no output schema, the description is sparse. It omits prerequisites (e.g., position must exist), explains no return behaviors, and fails to guide on which parameters are critical beyond the required ones.

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

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

The input schema has 100% coverage with descriptions for all 10 parameters. The tool description adds no parameter-specific context beyond what the schema provides, so baseline score is appropriate.

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

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

The description clearly states the verb 'Settle' and the resource 'funding payments on a perpetual futures position'. It distinguishes from siblings like 'toreva_perps_query_funding' (query) and 'toreva_perps_close' (close position).

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 settling payments at the venue and mentions fees, but does not explicitly state when to use this tool versus alternatives like closing or adding margin. No contraindications 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?

No annotations provided, so the description carries full burden. It discloses fees (2 bps), Drift discount, non-custodial nature, receipting, and disclaimer. Missing details like authentication requirements or rate limits, but the key behaviors are covered.

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?

Six sentences, each adding value: purpose, routing, fees, discount, agent decision, non-custodial/receipt, disclaimer. No fluff, front-loaded with main action. Ideal conciseness for a tool definition.

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 14 parameters and no output schema, the description covers core behavior (opening long, routing, fees, custody). It does not explain return values or error scenarios, but the context is sufficient for an agent to use the tool effectively. The lack of output schema is partially mitigated by the 'receipted' mention.

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

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

Schema description coverage is 100%, so baseline is 3. The description does not add extra meaning to individual parameters beyond schema descriptions. It provides context for the venue routing, which relates to the 'venue' parameter, but no new parameter-specific semantics.

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

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

The description clearly states the action: 'Open a long perpetual futures position on Solana.' It distinguishes from sibling tools like 'toreva_perps_short' by specifying direction. The verb 'open' and resource 'long perpetual futures position' 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 explains when to use the tool (to open a long perp position) and describes routing behavior across venues. It implies the agent decides parameters, but does not explicitly state when not to use (e.g., for short positions) or provide alternatives, though sibling names make this 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?

No annotations provided, but description compensates by explicitly stating 'Read-only' and 'Data transaction at 0 bps', indicating non-destructive and cost-free behavior. Does not discuss response format or error handling, but tool simplicity limits necessity.

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, zero redundancy. First sentence states function, second adds behavioral traits. All information earns its place.

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

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

For a simple query tool with one parameter and no output schema, description covers purpose, read-only nature, and cost. Lacks details on returned data structure but acceptable given minimal 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?

Single parameter 'token' with schema description including examples (SOL, BTC). Description adds no additional meaning beyond schema. Schema coverage is 100%, so baseline 3 applies.

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

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

Description clearly states it queries current funding rates for a token across multiple venues (Jupiter Perps, Pacifica, Drift, Flash Trade). Verb 'query' matches tool name 'query_funding' and resource is explicit. Distinguishes from sibling tools like 'funding_settle' and 'query_markets'.

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

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

States 'Read-only' and 'Data transaction at 0 bps', implying safe, cost-free usage. However, no guidance on when to use this tool versus related tools like 'toreva_perps_query_markets' or when not to use it.

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

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

With no annotations, the description discloses the tool is 'Read-only' and has 'Data transaction at 0 bps,' which informs the agent of safety and cost. However, it does not mention potential rate limits or response structure.

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

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

The description is three short, front-loaded sentences with no redundant information. Every sentence adds value: purpose, read-only, and cost.

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

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

The description adequately states the tool's purpose and safety, but without an output schema, it could hint at the response (e.g., containing market names or IDs). It is sufficient for a simple list but lacks depth.

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 covers the single parameter 'venue' with a description. The tool description adds no additional meaning beyond the schema, so the baseline score of 3 applies.

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

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

The description clearly states 'List available perpetual futures markets,' with a specific verb and resource. It also adds 'Read-only' and 'Data transaction at 0 bps' to distinguish it from trading tools. Among siblings, it uniquely addresses querying markets.

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

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

The description implies usage for listing markets but does not explicitly state when to use versus other query tools like 'toreva_perps_query_funding' or 'toreva_perps_query_position'. No when-not-to-use guidance or prerequisites 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?

Explicitly says 'Read-only' and 'Data transaction at 0 bps', covering key safety and cost traits. No details on error handling, permissions, or 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?

One sentence with essential information; efficient but could benefit from a bit more context on usage.

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?

No output schema or annotations; description is minimal. Adequate for a simple query but doesn't fully differentiate from sibling query tools or explain return structure.

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

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

Schema coverage is 100%, and the description adds no extra meaning beyond the schema's parameter descriptions. Baseline score applies.

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

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

Clearly states it queries open perpetual futures positions for a wallet, specifying 'Read-only' and 'Data transaction at 0 bps' to distinguish from trading 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?

No explicit when-to-use or alternatives, but the read-only and zero-cost hint imply safe usage. Lacks comparison to other query tools like torevva_perps_query_markets.

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?

States 'Read-only' and 'Data transaction at 0 bps', so safe and cost-free. However, without annotations, more detail (e.g., auth requirements, data freshness) would improve transparency for a fully burdened description.

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

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

Three concise segments with no redundant or filler text. Front-loaded with the core action and resource.

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 zero-param, no-output-schema tool, the description covers essential aspects (purpose, read-only, cost). Could mention return format or usage context, but not necessary.

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?

No parameters in schema, so description naturally adds no param info. Schema coverage is 100%, meeting baseline. For zero-param tools, this is fine.

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

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

Clear verb 'list' and specific resource 'perps venues' with detail about fee structures. Distinguishes from sibling query tools like query_markets or query_position by focusing on venues.

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

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

No explicit guidance on when to use this tool vs. alternatives. While the purpose is clear, there is no indication of prerequisites or exclusions, which is important given many sibling tools.

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

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

Given no annotations, the description adds some behavioral context: execution at venue, fee, non-custodial nature. However, it lacks details on position health implications or error states.

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

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

Three concise sentences with no fluff: purpose, execution context, fee, and custody model. Front-loaded and efficient.

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

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

With 11 parameters and no output schema, the description lacks completeness on return values, prerequisites, and error scenarios. More context needed.

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

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

Schema coverage is 100%, so parameters are well-described in schema. The tool description does not enhance parameter understanding beyond 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 removes margin from a perpetual futures position, with a specific verb and resource. It distinguishes from sibling tools like 'toreva_perps_add_margin'.

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, such as adding margin or closing a position. No prerequisites or context 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?

Discloses execution fee (2 bps), fee discount on Drift, non-custodial nature, and disclaimer. Since no annotations exist, this covers key behavioral traits, though order type and failure behavior are not detailed.

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

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

Single paragraph with logical flow, front-loaded purpose, fees, discount, then agent role and disclaimers. Efficient but could be more structured for readability.

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 key aspects: purpose, fees, routing, agent involvement. Without output schema, return value not described, but enough for agent to use appropriately.

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 100% coverage; description mentions parameters like size, leverage, collateral but adds minimal extra meaning beyond reinforcing agent's role in deciding them.

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

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

Description clearly states it opens a short perpetual futures position on Solana, specifies assets (e.g., SOL, BTC, ETH), and distinguishes from sibling tools like toreva_perps_long and other perps management 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?

Provides context on when to use: 'Your agent decides direction, size, and leverage. Toreva handles venue selection.' Implies usage for short positions but lacks explicit when-not-to-use or alternatives to other similar 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?

Discloses that no execution occurs and the transaction is at 0 bps, a key behavioral detail not covered by annotations (none provided). Could mention idempotency or lack of state change, but sufficient.

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

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

Four sentences, front-loaded with core purpose and usage. Every sentence adds value with no redundancy.

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

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

Covers purpose, what it returns, and when to use. No output schema, but return values described. Could mention required wallet address parameter, but schema covers it.

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

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

Schema coverage is 100%, so baseline 3. Description adds no parameter-specific details beyond schema; it focuses on tool behavior rather than individual params.

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 specifies the tool simulates opening a perpetual futures position without executing, compares multiple venues, and returns projections. It distinguishes from siblings by advising use before perps_long or perps_short.

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 to use before perps_long or perps_short to preview outcomes, providing clear context for when to use. No explicit when-not or alternatives, but adequate.

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 no annotations, the description carries full burden. It discloses the discovery-only nature and the readiness constraint, but does not explicitly state side effects (likely none) or confirm read-only behavior. The word 'discover' implies no writes, but could be more explicit.

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

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

The description is two sentences, front-loaded with purpose, and no redundant words. The caveat about discovery-only is efficiently placed.

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 (discovery of a large universe) and simple input schema, the description adequately conveys the scope and constraint. However, with no output schema, details on the return format are missing, but the description implies the result covers the mapped universe.

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

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

Input schema has 100% description coverage, so the schema already documents the three parameters. The description adds no additional semantics beyond what the schema provides (e.g., that filters are optional), resulting in no extra value.

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 'Discover' as the verb and specifies the resource: 'toreva's full evidence-gated Solana primitive universe'. It lists mapping dimensions, clearly distinguishing it from sibling tools like toreva_execute which handle execution.

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 it is 'discovery-only' and that 'candidate primitives are not execution tools until their readiness metadata says so', implicitly guiding when to use this tool (discovery) versus alternatives (execution tools like toreva_execute). However, it does not explicitly list alternatives 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?

Annotations are absent, so description carries full burden. It discloses the tool is non-custodial, but does not state whether it is read-only, requires authentication, or if it modifies any state. The 'scan' verb implies read, but not explicitly safe.

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

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

A single sentence conveys the purpose and scope, with an additional tag 'Non-custodial' for trust context. No superfluous words, and front-loaded with key action and resource.

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?

Lacks description of output format or structure (e.g., what opportunities/risk flags look like). Without an output schema, the agent might not know how to interpret results. However, for a scan with one parameter, the purpose is adequately covered.

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

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

Schema coverage is 100% with a clear description for walletAddress. The tool description adds contextual meaning about opportunities and risk flags but does not enhance parameter semantics beyond what the schema provides.

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

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

The description clearly identifies the resource (Solana wallet), action (scan), and scope (Day 1 Toreva opportunities and risk flags across Earn, Stake, and Balance). It also notes non-custodial nature, differentiating from sibling tools that focus on specific actions like execute, earn, or perps.

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 provided on when to use this tool versus alternatives like toreva_earn or toreva_simulate. The description does not explain prerequisites or conditions that would trigger its 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?

No annotations exist, so the description must fully convey behavior. It mentions no funds are committed (safe, read-only) and lists return fields, but does not disclose potential errors, rate limits, or authentication needs. Adequate but not comprehensive.

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 concise sentences: first states action and scope, second states output. No extraneous words. Front-loaded with key 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 5 parameters and no output schema, the description covers overall purpose and returns. It assumes domain knowledge (e.g., 'Day 1 Toreva strategy') but schema fills details like allowed assets. Lacks clarity on return format but sufficient for selection.

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

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

Schema covers all 5 parameters with descriptions, so baseline is 3. The tool description does not add meaning beyond the schema (e.g., the asset parameter is detailed in schema but not in description). No enhancement.

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 simulates a Toreva strategy without committing funds, specifying the public scope (Earn, Stake, Balance on Solana) and the return details (projected venue selection, fees, routing). This distinguishes it from execution tools like toreva_execute.

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 simulation ('without committing funds') but does not explicitly contrast with alternative tools or provide when-to-use guidance. No exclusions or context for when not to use are given.

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

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

No annotations provided; description carries full burden. It details what is returned but does not explicitly state read-only nature or side effects. Verb 'browse' implies no state change, but behavioral traits like authentication needs are omitted.

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

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

Description is verbose (10+ sentences) with excessive detail like reserve split percentages. While front-loaded, it could be shortened without losing essential guidance for an AI agent.

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

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

Given no output schema and complexity of multiple products with fee semantics and metadata, the description provides comprehensive context about returns and constraints. Minor gap: no mention of prerequisites or error handling.

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

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

Schema coverage is 100% with description for the parameter, but the tool description adds significant context about each product (Earn, Stake, Balance) and their characteristics, going beyond the schema's enum values.

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 states 'Browse toreva's locked Day 1 strategy delivery contract for Solana' with specific verb and resource. It clearly distinguishes from sibling tools like toreva_execute or toreva_configure, which are for actions vs browsing.

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

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

Description implies use for browsing strategies but does not explicitly state when to use this tool vs alternatives like toreva_scan or toreva_explain. No when-not or exclusion criteria provided.

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