RubinTrade

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

Annotations already indicate idempotent and destructive behavior. The description adds that it operates in one transaction and explains the chain limitation (SHORT_TERM only), which goes beyond the annotations.

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

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

Two sentences with immediate purpose and usage guidance, no wasted words.

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

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

No output schema and no parameter explanations make this incomplete for a tool with two required params. The description does not cover return behavior or constraints beyond the type of orders.

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 two required parameters ('market' and 'clientIds'), leaving the agent to rely solely on schema names and types.

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 cancels multiple SHORT_TERM orders, distinguishing it from the sibling 'cancel_all_orders' which handles stateful/mixed orders.

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 specifies that this tool is only for SHORT_TERM orders and advises using 'cancel_all_orders' for stateful/mixed orders, providing clear context for when to use 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 indicate destructiveHint=true, idempotentHint=true. The description adds value by disclosing automatic handling of order types and providing retry logic based on remainingOpen field. No contradiction with annotations.

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

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

Two sentences, front-loaded with action and scope, followed by return value and guidance. No wasted words.

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

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

Given no output schema, the description explains return value and retry condition. It covers the essential behavior for a cancellation tool, but could mention error conditions or prerequisites (e.g., market existence or authority).

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 50% (only confirm has description). The tool description does not add meaning for the market parameter beyond 'in a market', and does not describe the confirm parameter at all, failing to compensate for the incomplete 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 cancels every OPEN order for the subaccount in a market, and mentions it handles SHORT_TERM and LONG_TERM automatically. It distinguishes from siblings like cancel_order (which cancels a single order) by specifying 'all orders' and is unique among siblings.

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

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

The description implies this tool is for bulk cancellation of all orders in a market, but does not explicitly state when to use it over cancel_order or batch_cancel, nor does it provide exclusions or alternatives. No guidance on prerequisites or context.

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

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

The description discloses that the cancel may return 'still_open' if the goodTil value is incorrect, that 'code: 0 only means the cancel was broadcast' (not necessarily confirmed), and suggests retrying. This adds context beyond the annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=true) and helps the agent understand the tool's non-deterministic behavior. 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 three sentences, front-loaded with the core purpose ('Cancel a single order by clientId'), followed by essential usage details and return value interpretation. Every sentence adds value without redundancy. It is highly 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?

For a tool with 6 parameters, 3 required, order-type logic, and no output schema, the description covers the key behavioral aspects: how to cancel each order type, what the return confirmation indicates, and how to handle errors ('still_open' retry). It references 'get_open_orders' for obtaining the goodTil value. While it does not detail the 'confirm' parameter (already in schema) or the full return structure, it is adequate for practical use.

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 only 17% schema description coverage, the description adds significant meaning by explaining the relationship between 'orderFlags' and the two goodTil parameters, and where to obtain the original goodTil value ('available from get_open_orders'). It clarifies that 'clientId' identifies the order. While 'market' and 'orderFlags' are not explained, the description compensates for the most critical conditional parameters.

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

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

The description clearly states 'Cancel a single order by clientId', which is a specific verb ('Cancel') and resource ('order'). It distinguishes from siblings like 'batch_cancel' and 'cancel_all_orders' by specifying 'single order'. It also details order-type handling, making 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?

The description provides explicit guidance on when to use specific parameters based on order type ('For SHORT_TERM pass goodTilBlock; for LONG_TERM/CONDITIONAL pass goodTilTimeSeconds') and explains how to interpret results ('If still_open, the goodTil value likely did not match the original — retry'). It does not explicitly state when not to use the tool versus alternatives, but the focus on single orders and the availability of sibling tools imply the context.

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

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

Annotations indicate a write operation (readOnlyHint=false) and non-idempotent. Description adds behavioral details: reduce-only orders, oracle-bounded slippage, allowlist skipping, and per-market result array. This goes beyond annotations without contradicting them.

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

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

Two sentences, each valuable. First sentence defines the action; second adds constraints and post-action guidance. No redundant or vague phrasing.

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

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

Given the complexity of a batch close operation and no output schema, the description provides necessary return information ('per-market result array') and instructions for partial fills. However, it lacks details on the confirm parameter's role and the exact structure of the result array.

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 50% (slippageBps has a description, confirm does not). The description adds context for slippageBps ('default 500 bps, raise to sweep thin books') but does not mention the confirm parameter, leaving its purpose unspecified.

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: 'Flatten EVERY open perpetual position with reduce-only MARKET orders (one per market).' This is a specific verb+resource combination and distinguishes from sibling tools like close_position and cancel_all_orders.

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 guidance on when to use it and how to handle results: 're-run with a larger slippageBps' for unfilled orders. It also mentions the allowlist behavior. However, it does not explicitly compare to close_position or state when not to use this tool.

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

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

The description discloses key behavioral traits beyond annotations: it uses a reduce-only MARKET order, reads current position, auto-flips side, floors partial closes to market step size, bounds orders at oracle ± slippageBps, and returns a confirmation outcome. Annotations only say readOnlyHint=false, destructiveHint=false, idempotentHint=false; the description adds rich context without contradiction.

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

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

The description is well-structured, starting with the main purpose, then detailing mechanics, then error handling. It is comprehensive but slightly verbose; some sentences could be tightened (e.g., combining oracle±slippageBps explanation). However, it is clear and front-loaded with the key action.

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 (partial closes, slippage, market orders) and absence of an output schema, the description is fairly complete. It explains the return value ('confirmation' outcome) and provides guidance on re-running. However, it does not describe the `confirm` parameter, and the exact structure of the confirmation object is missing. Overall, it covers most use cases adequately.

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 75% (3 of 4 parameters described in schema). The tool description adds meaning: explains default values for percent (100) and slippageBps (500), how slippageBps bounds the order, and that percent is floored to step size. It also explains the behavior of the market parameter. The confirm parameter is not described, but the main parameters are well 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 clearly states 'Close all or part of an open perpetual position with a reduce-only MARKET order.' It specifies the action, resource, and method, distinguishing it from sibling 'close_all_positions' which closes all positions. The verb 'close' and resource 'perpetual position' are precise.

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 comprehensive usage guidelines: explains automatic side-flipping (LONG→SELL, SHORT→BUY), default percent (100 for full close), partial close behavior (floored to step size), slippage bounding (oracle ± slippageBps, default 500 bps), and error handling (re-run with larger slippage on unfilled/partially_filled). It implicitly tells when not to use (if no position, error NOT_FOUND). While alternatives aren't explicitly named, the tool is self-contained.

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 explains key behavioral details beyond the annotations: funds never leave the account, the trading key is allowed to make this transfer, and the $0.95 gas reserve remains untouched. This gives an agent an accurate safety model for a mutating action.

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 filler: the mechanism, the parameter behavior, and the triggering use case are each covered. The description is front-loaded with the core action.

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

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

For a single-parameter mutating tool with no output schema, the description provides all essential context: what happens, how the amount is decided, safety constraints, authorization, and the exact scenario for using it. Nothing significant 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?

Although the schema covers amountUsd, the description adds meaningful semantics: omitting the parameter moves everything above the $0.95 gas reserve, while providing it moves exactly that amount with the same reserve enforced. This clarifies default and exact-value behavior beyond the schema text.

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

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

The description clearly states the action: depositing USDC from the wallet into the trading subaccount to become collateral. This is specific and distinguishes the operation from related tools like top_up_gas or external transfers.

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

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

The description explicitly says to use it when the user has sent money to the account and the subaccount collateral is 0 or too low to trade. It does not explicitly name alternative tools or state when not to use it, but the usage context is clear enough.

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

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

Despite readOnlyHint being present, the description adds meaningful behavioral detail: wallet balance is NOT collateral until deposited, there is a $0.95 gas reserve, and funding synthesizes the deposit decision. This goes well beyond the annotation and prevents a common misunderstanding.

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 earning its place: the first names the resources being fetched, the second clarifies the collateral versus wallet distinction, and the third explains the summary field and next actions. Information is front-loaded and nothing is redundant.

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

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

For a parameterless read-only tool with no output schema, the description is complete. It explains both key balances, the gas reserve, the suggestedAction logic, and even references the relevant sibling tools deposit_to_subaccount and top_up_gas.

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

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

There are no parameters and schema description coverage is 100%, so there are no input ambiguities. The description instead explains the meaning behind the returned balances, which is the only semantic value needed here.

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 and identifies two distinct resources: the subaccount collateral balance and the on-chain wallet bank balance. It also disambiguates these two concepts clearly, which helps an agent understand what this tool reports and what it does 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 clear context about when the balances matter and explains the suggestedAction field, including conditions for depositing spare USDC or topping up gas. It does not explicitly provide exclusionary routing against sibling balance tools, so it stops slightly 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?

The description does not contradict the readOnlyHint annotation and confirms read-only behavior, but adds no extra details like rate limits or data freshness that would enhance transparency.

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 short sentences with no redundancy, directly stating purpose and use case in a front-loaded manner.

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 no parameters, no output schema, and is simple; the description fully covers what it returns and its typical application in order math.

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 zero parameters, the schema coverage is 100% and the description needs no additional parameter documentation, meeting the baseline for parameterless tools.

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 verb 'Return' and the resource 'latest chain block height', clearly differentiating from sibling tools that deal with orders, positions, and account 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?

It explicitly suggests use 'for SHORT_TERM order goodTilBlock math', providing context for when to invoke it, though it does not mention when not to use it or alternatives.

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

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

The annotations already declare 'readOnlyHint: true', which is consistent with a read operation. The description adds no new behavioral context beyond what annotations provide, resulting in a neutral score.

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

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

The description is two concise sentences that efficiently convey the core purpose and a use case, with 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?

The description omits important details like the return format or ordering of candles. With no output schema, the agent cannot infer what data the tool returns, making it less complete for informed 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 coverage is high (80%), so baseline is 3. The description does not add parameter details beyond the schema; for example, 'limit' lacks a description in the schema and is not mentioned in the tool description.

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

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

The description clearly states the tool retrieves OHLCV candles for a market and resolution, which is specific. However, it does not differentiate from the sibling tool 'get_candles_multi', so it loses the top score.

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

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

The description mentions the tool is 'useful for trend/volatility analysis', giving context, but does not specify when to use this over alternatives 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?

Annotations already declare readOnlyHint=true, so the description adds value by specifying the return order (newest first) and structure (candles keyed by resolution). No contradictions; additional behavioral context is provided.

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

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

Two sentences front-load the key purpose and provide actionable guidance with no wasted words. Highly efficient.

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

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

Given no output schema, the description fully explains the return format (candles keyed by resolution, newest first). Inputs and defaults are covered. For a read-only tool with 3 parameters, this 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?

Schema coverage is 100%, so parameters are documented. The description adds contextual meaning: default limit of 50, default resolutions as all indexer resolutions, and a hint to use smaller limits or subsets for efficiency.

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 gets OHLCV candles across multiple resolutions in one call, distinguishing it from the sibling get_candles which is presumably single-resolution. It specifies the default resolutions and the return format, leaving no ambiguity about the tool's purpose.

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

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

The description provides guidance on when to use this tool (to read trends across timeframes) and offers tips to keep payload small (lower limit, subset of resolutions). It does not explicitly exclude scenarios but the context with sibling tools makes it 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 declare readOnlyHint: true; description adds specific fields returned. No mention of auth or rate limits, but given annotations cover safety, description adds value without contradiction.

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

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

Single sentence, front-loaded with purpose, enumerates contents without waste. Highly concise and clear.

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

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

Sufficient for a simple read-only tool. No output schema, but description lists return fields. Could mention response format or limitations, but adequate.

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

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

No parameters; schema coverage is 100% trivially. Baseline 4 is appropriate as description adds no param info but no parameters exist.

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 gets a subaccount summary with specific fields (equity, freeCollateral, etc.). The verb 'Get' and resource 'subaccount summary' are precise and differentiate from siblings like get_balance or get_positions.

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 siblings. The description implies it's a summary endpoint but does not provide when-not-to use or alternative tools. Adequate but lacks explicit direction.

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

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

Annotations already establish readOnlyHint=true; the description adds meaningful behavioral detail beyond that: negative maker fees are rebates, tiers depend on 30-day volume, staking can affect fees, and the output includes thresholds and the full tier table. It transparently conveys that this is a snapshot-style read of the account's fee status.

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-packed: it front-loads the core purpose, then enumerates precisely what the response contains, and closes with one relevant cross-reference. Every clause supports the agent's decision to use or understand the tool.

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

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

With zero parameters, a readOnly annotation, and no output schema, the description covers the needed return values and edge cases (negative fees, staking discounts, progression to next tier, referral handling). Nothing critical is missing for the agent to select and use this tool successfully.

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

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

The tool exposes no parameters, so there is no schema burden to compensate. The description still contextualizes what the tool inherently applies to—the current account's trading fee tier—which is sufficient for invoking the tool correctly.

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

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

The description clearly states it returns the account's current trading fee tier and related conditions, with resourceful detail (maker/taker fee, rebates, volume, staking discount, full fee-tier table). It distinguishes itself from siblings by focusing on 'this account's current' fee-specific data and even directs to get_referral_program when relevant.

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 makes clear when this is the right tool: to learn one's own fee tier and the conditions used to compute it. It also forwards referred users to the specific sibling get_referral_program. It does not provide broader when-not/alternative guidance, but there is no strongly overlapping sibling.

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

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

The readOnlyHint annotation already declares no side effects. The description adds context about what data is returned (price, size, fee, liquidity) but does not mention pagination, sorting, or any other behavioral traits beyond that.

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

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

Single sentence of 15 words, direct and front-loaded. Every word adds value, no redundancy or filler.

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

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

For a simple read tool with no required parameters and no output schema, the description covers the core purpose and data fields. However, it omits pagination details (page, limit) and does not describe the return structure, which would help agents interpret results.

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

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

Schema description coverage is only 33% (only market has an inline description). The tool description does not clarify the purpose of page, limit, or market beyond naming the returned fields. No parameter-specific guidance is provided.

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

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

The description clearly states the tool retrieves executed fills for a subaccount, listing included data fields (price, size, fee, liquidity). It distinguishes from sibling tools like get_balance, get_equity, etc., which serve different purposes.

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 usage for retrieving trade history but offers no explicit guidance on when to use this tool versus alternatives such as get_positions or get_pnl. No when-not-to-use 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.

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

Given readOnlyHint=true, the description adds valuable behavior beyond the annotation: funds land in the wallet and are NOT collateral, the depositableUsdc calculation subtracts a $0.95 gas reserve, and the tool can suggest deposit_to_subaccount or top_up_gas. There is no contradiction with the read-only 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?

Three dense sentences cover the core concept, the returned fields, and pragmatic use cases. No filler is present; each sentence earns its place and the most important distinction 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?

With no output schema, the description carries the full burden of explaining the return payload, and it does so well. The call conditions and the meaning of the suggested action list make the tool fully operational for an agent with no further 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?

The tool has no parameters, so there is no parameter documentation burden. The description still contributes useful context about the account-level behavior, which is sufficient given the empty 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 states exactly what the tool does: it locates the account's USDC between the wallet and trading subaccount. It also lists the meaningful return values (depositableUsdc, gas-low flag, suggestedAction), making it clearly distinct from generic balance or portfolio 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?

Explicit call conditions are provided: when the user reports sending funds, when collateral reads 0, or before any funding decision. The description does not explicitly name sibling tools that should be used instead, but the when-to-use signals are concrete and unambiguous.

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 the description notes pagination and the conditional `me` row, which reveals a non-obvious return behavior not in the schema. It adds useful context without contradicting the safety hint.

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 earning its place: the core purpose and fields, the special 'me' row behavior, and the alternative tool for a different query. No filler or duplication of schema content.

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

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

For a read-only paginated list with fully documented parameters, this description is complete: it names all return fields, explains the special self row, and provides sibling routing. No output schema exists, but the field list is enough for an agent to interpret the result.

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 structure carries the parameter documentation burden. The description adds the list of time span values and implies pagination but doesn't go beyond what the schema already states.

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 tool returns 'the trader PnL leaderboard' and enumerates both the time spans and the exact output columns (rank, username, address, PnL, ROI, equity), making its purpose unambiguous. It also explicitly distinguishes itself from the sibling get_my_rank, aiding selection.

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 usage context: one time span at a time, optionally using search for filtering, and explicitly points to get_my_rank when all time spans are needed at once. This provides actionable routing to alternatives.

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

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

Annotations already provide readOnlyHint, so the description adds value by listing returned fields but does not disclose additional behavioral traits beyond what annotations convey.

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

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

The description is a single sentence, efficiently conveying the tool's purpose and output 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?

Given the tool's simplicity (1 param, no output schema), the description adequately lists return fields. However, it could be slightly more complete by explicitly stating it returns a single object.

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 does not add meaning beyond the schema's parameter description. It focuses on return values rather than parameters.

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

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

The description clearly states the verb 'Get' and the resource 'perpetual market', listing specific fields returned. It distinguishes from siblings like 'list_markets' which likely returns multiple 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 when to use (querying details of one market) but does not explicitly state when not to use or mention alternatives like 'list_markets' for multiple 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?

Beyond the readOnlyHint annotation, the description adds important behavioral details: omitted timeSpan returns all five time spans, and a null entry means the account is not ranked on that board due to no qualifying activity. This is valuable because there is no output schema to convey these semantics.

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 tight sentences: the first front-loads the return payload and the optional parameter behavior, and the second clarifies null semantics. No filler or redundant restatement.

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

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

For a read-only tool with one optional parameter, no output schema, and no nested objects, this description covers everything an agent needs: return fields, single- vs all-time-span behavior, and null-entry meaning. The account-scoped nature also removes ambiguity against siblings.

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

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

The input schema already fully documents the timeSpan enum and its description, so the description does not need to add much. It does add the useful note that omitting the parameter returns every time span, but the schema already carries the main parameter semantics.

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

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

The description states a specific verb and resource: it returns THIS account's PnL leaderboard rank, including rank, board size, PnL, ROI, and equity. It clearly distinguishes itself from a full-leaderboard tool by explicitly scoping to the current account, which separates it from sibling tools like get_leaderboard.

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 conveys when to use it: when the agent needs the current account's rank on the leaderboard, and optionally for a specific time span or all time spans by omitting timeSpan. It does not explicitly name alternatives or say when not to use it, but the 'THIS account' scoping provides clear contextual guidance.

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

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

Annotations indicate readOnlyHint=true, and the description adds non-obvious traits: no importance field (self-judgment), return format (source, url, publishedAt, tags, text), and language (ru/en). This goes 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 four sentences, well-structured with purpose first, then parameter details, then usage guidance. 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?

Given no output schema, the description explains the return structure. All five parameters are covered, and usage guidance is provided. No obvious 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 100%, but the description adds value by explaining how parameters interact (e.g., 'query' matches text and hashtags, 'channels' overrides category) and provides an example (BTC). This aids 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 'Fetch the latest headlines from the ritbit news feed' with specific details about curated channels and ordering. It distinguishes itself from sibling tools, which are all trading/account operations.

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 suggests usage contexts: 'Use this to factor sentiment/catalysts into an assessment, or to answer "what's the latest?".' It does not explicitly mention when not to use or alternatives, but given sibling tools are unrelated, this is sufficient.

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

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

Annotations already declare readOnlyHint=true, indicating safety. The description adds value by disclosing the inclusion of untriggered conditional orders and explaining the return format ('orders' array). It does not contradict annotations and provides useful context beyond the structured fields.

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

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

The description is concise (3-4 sentences), front-loaded with the primary purpose, and every sentence adds meaningful information. No extraneous 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?

Given 3 optional parameters and no output schema, the description covers the return format ('orders' array), explains the note for zero orders, and distinguishes from positions. It lacks explicit mention of pagination or the limit parameter's purpose, but overall it is adequately 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 33% (only market has a description). The description clarifies that 'side' and 'market' are filters, adding meaning beyond the schema. However, it does not explain the 'limit' parameter, leaving its purpose undocumented. This is a gap, but partial compensation keeps it at baseline.

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

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

The description clearly states the tool retrieves active orders for a subaccount, with optional filters by market and side. It distinguishes itself by clarifying it does not return positions and points to the get_positions sibling tool. The verb 'get' and resource 'orders' 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 explicitly tells when to use this tool (to get open orders) and when not to use it (for filled positions, which become positions). It directs the agent to the appropriate sibling tool (get_positions) and explains edge cases like zero orders with open positions resulting in a note.

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, so the description does not need to reiterate safety. It adds value by specifying 'live' (real-time) and 'optionally truncated to a depth', which are behavioral traits beyond the annotation. 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 a single 15-word sentence that is front-loaded with the purpose. Every word earns its place, with no unnecessary 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 simple read tool with two parameters and no output schema, the description is mostly complete. It explains the return value (bids/asks) and the optional depth truncation. However, it could provide more detail on the orderbook structure (e.g., price levels), though it remains adequate.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds minor context by linking 'depth' to truncation, but the schema already describes both parameters adequately.

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

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

The description clearly states the tool gets the live orderbook (bids/asks) for a market, using a specific verb 'Get' and resource 'orderbook'. This distinguishes it from sibling tools like get_market (market info) or get_candles (historical 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 implied usage (to fetch orderbook data) but does not explicitly state when to use this tool versus alternatives like get_market or get_fills. No when-not conditions or alternative tool names 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?

Annotations already declare readOnlyHint=true. The description adds context that the tool returns ticks with equity, totalPnl, and netTransfers over time. No behavioral contradictions. It could mention pagination but is otherwise transparent.

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

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

The description is a single sentence plus a brief instruction, with no wasted words. It is front-loaded with the core purpose and immediately useful.

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 how to use the key parameter. It does not cover pagination behavior or default values, but given the simplicity and the presence of readOnlyHint, it is largely 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 low (33% with only createdOnOrAfter having a description). The description adds meaning for createdOnOrAfter ('bound the range'), but page and limit parameters lack extra context. This partially compensates for the low coverage.

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

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

The description clearly states the verb (Get), resource (historical PnL ticks for subaccount), and specific fields (equity, totalPnl, netTransfers). It distinguishes from sibling tools like get_equity by specifying it returns ticks over time.

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

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

The description mentions using createdOnOrAfter to bound the range, providing a usage hint. However, it does not explicitly state when to use this tool versus alternatives like get_equity or get_portfolio, nor does it 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?

Annotations declare readOnlyHint=true, so the description doesn't need to repeat. It adds value by detailing return fields (notional, unrealized PnL, liquidation prices for positions; resting and untriggered TP/SL for orders; margin risk). No contradiction.

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

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

Single sentence is front-loaded with core purpose and specific return data, then provides usage guidance. 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?

No output schema but description fully explains what is returned. For a read-only snapshot with no parameters, the description is complete and covers all relevant aspects.

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?

Zero parameters with 100% schema description coverage. Baseline is 4 for no parameters; description adds no param info, but none is needed.

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

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

The description uses 'One-call snapshot' and lists specific data returned (equity, freeCollateral, positions with details, orders, margin risk). It distinguishes from sibling tools like get_positions and get_open_orders by stating it returns both.

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 advises using this tool to answer 'what do I have open?' or 'how am I doing?' without needing separate calls for orders vs positions. It gives clear when-to-use and differentiates from 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 the description adds valuable behavioral details: 'maintenanceMarginBufferUsd (the EXACT liquidation guard — liquidatable when < 0)', 'marginUsageRatio (1.0 = at liquidation)', and per-position liquidation price with distance. This goes beyond annotations to explain critical thresholds.

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

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

Two sentences: the first lists the key data fields, the second states the use case. Every word adds value; 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?

Despite no output schema, the description explains all returned fields clearly. For a zero-parameter read tool, it is fully self-contained and tells the agent exactly what to expect.

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 exist, so schema coverage is 100% by default. The description does not need to add parameter info. It earns a baseline of 4 for zero-param tools.

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 'Margin health for the subaccount' and lists specific fields like equity, freeCollateral, margins, liquidation guard, and per-position liquidation info. This distinguishes it from sibling tools like get_positions or get_portfolio which focus on different aspects.

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

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

Explicitly says 'Use before adding risk or to decide whether to protect/close a position.' This provides context for when to use. It could mention alternatives or when not to use, but it's clear enough for the agent.

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

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

The annotations already declare readOnlyHint=true, so the description adds context by specifying the default status filter (OPEN) and listing returned fields, which is helpful 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 extremely concise: two sentences and a note. It front-loads the primary function and fields, then provides critical usage guidance. No extraneous 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 simple schema (one optional parameter, no output schema), the description covers all necessary aspects: what the tool returns, its default filter, and how it relates to sibling tools. It is fully complete.

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

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

Schema coverage is 100% with a single parameter (status) having an enum. The description adds value by stating 'Defaults to OPEN', which is not explicitly in the schema, helping the agent understand default behavior.

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 'Get', the resource 'perpetual POSITIONS', and lists specific fields returned. It also distinguishes from sibling tools like get_open_orders and get_portfolio.

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 explicit guidance on when to use this tool: it clarifies that a position is not an open order and advises checking both this and get_open_orders when the user asks 'what is open?'.

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 readOnlyHint says the tool is read-only, and the description reinforces this by describing a status query without mutation or side effects. It also adds valuable nuance beyond the annotation by specifying eligibility triggers (lifetime volume threshold or existing affiliate) and time-bound data (30d/all-time volumes, caps), which fills in what the agent should expect back in the absence of an output schema.

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

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

The description front-loads the main scope and then packs all relevant status details into one sentence. It is long but each item contributes meaning, so it is closer to a compact enumeration than an unnecessarily verbose description. A bulleted list could improve readability, but the content is 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?

Since there is no output schema, this description must carry the full burden of explaining the tool's result, and it does: referral code, link, access unlock status, tier, fee share, volumes, earnings, referred-user stats, referrer, full tier table, and cap parameters. It concentrates almost every meaningful piece of referral state an agent might need to reason about or verify.

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

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

There are no parameters, and the schema already manages the empty property list completely. The description therefore adds nothing new about input needs, but it appropriately keeps the explanation focused on output instead of trying to invent parameter meaning.

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

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

The description states a specific verb and resource: getting this account's referral/affiliate program status. It then enumerates a concrete set of returned fields (referral code, link unlock status, tier, fees, volume, earnings, referrer, tier table, parameters), making it unambiguous. There is no sibling tool covering referral/affiliate program data, so the scope already separates it from the trading/accounting 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 no-parameter, account-scoped 'status' wording gives a clear context: call this when the agent needs this account's referral program state. It does not explicitly document exclusion criteria, such as 'do not call before sign-up,' but there is no alternative sibling to consider, so the simple is 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?

Annotations already provide readOnlyHint: true, so safety is covered. The description adds valuable behavioral context about the output content (ticker, status, oracle price) and its use in the workflow, which is 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 sentences, front-loaded with the action, no wasted 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 no output schema, the description adequately explains what the tool returns (ticker, status, oracle price) and how to use it. It is complete for a simple 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?

There are zero parameters, so baseline is 4. The description does not need to add parameter info, but it adds meaning by describing the output fields, which is appropriate.

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

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

The description uses a specific verb 'list' and resource 'perpetual markets', specifies fields (ticker, status, oracle price), and provides an example. It clearly distinguishes from siblings like get_market by being a list of all markets.

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

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

The description explicitly says 'Use this first to discover valid market tickers before placing orders', giving clear context and purpose. It does not explicitly mention when not to use it or list alternatives, but the guidance is sufficient.

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

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

Annotations are all false, so the description carries full burden. It explains behavioral details: market order execution, size/notional conversion with floored step size, bracket placement conditional on entry success, reduce-only nature of bracket legs, and slippage caps. 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 dense but not excessively long. It is front-loaded with the core action in the first sentence. However, some details could be more concise without losing clarity.

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 8 parameters, 2 required, and no output schema, the description covers nearly all behavioral aspects: entry mechanism, bracket behavior, edge cases (e.g., only one of size/notional, bracket only if entry succeeds). It even mentions the return structure. Complete for the tool's complexity.

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

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

Schema coverage is high (75%+), but the description adds critical semantics: notionalUsd conversion with floor, slippageBps default, bracket leg placement details. This goes beyond the schema's simple field descriptions, providing the agent with actionable behavior context.

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

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

The description clearly states the tool opens a new position with a market order and optionally attaches bracket orders. It uses specific verbs ('Enter', 'open') and resources ('position'), and distinguishes from siblings like place_market_order and place_stop_loss by combining entry and bracket in one call.

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

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

The description provides clear context for when to use the tool (entering a new position with market entry and optional bracket). It implicitly contrasts with separate order placement tools, but does not explicitly state when not to use it or 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?

Comprehensively discloses behavior beyond annotations: explains commit semantics (sync vs async), clarifies that broadcast code:0 does not imply fill, and details confirmation outcome interpretation. This fully compensates for sparse 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 packed with value, front-loaded with the primary action. No redundant words, effective use of parentheses and dashes for clarity.

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 11-parameter tool with no output schema, the description covers essential behavioral details (commit modes, outcome reporting, rate limits) and provides enough context for reliable use.

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?

Adds meaningful context for key parameters: timeInForce options, confirmation outcome, and rate limits. With 55% schema coverage, the description partially compensates for undocumented parameters like postOnly and reduceOnly.

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 places a limit order with specific timeInForce options. Lacks explicit differentiation from sibling tools like place_market_order or place_stop_loss, though the description of GTT vs SHORT_TERM provides some 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?

Provides clear guidance on when to use SHORT_TERM (latency-sensitive) vs GTT, and warns about rate limits for GTT orders. Does not address when to choose a limit order over other order types.

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

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

The description fully discloses the order's IOC behavior, slippage cap operation, and critical nuance that broadcast success (code 0) does not guarantee fill, emphasizing the confirmation.outcome field. This adds significant behavioral context beyond the annotations, which only indicate non-readonly, non-idempotent, non-destructive.

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 action and efficiently packs essential details (mechanism, outcome, retry) into a few sentences without redundancy. Every line serves a purpose 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?

Despite having no output schema, the description thoroughly explains the return value (confirmation object with outcome) and provides actionable guidance for each outcome state (unfilled, partially_filled, pending). It covers all key aspects: order type, slippage, reduceOnly, and result interpretation.

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 meaning to parameters like reduceOnly (closes existing position) and slippageBps (default and side-specific behavior), improving upon the 57% schema coverage. However, clientId is not mentioned, and some details are already in the schema, so the addition is good but not exhaustive.

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 places an IOC market order and distinguishes it from siblings like place_limit_order by explaining the immediate-or-cancel behavior and slippage cap mechanism specific to this order type.

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

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

The description provides explicit guidance on interpreting outcomes and retry logic (e.g., retry with larger slippageBps if unfilled), but does not explicitly compare when to use this tool versus limit or stop orders, missing a clear when-not-to-use statement.

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?

Describes execution behavior beyond annotations: IOC limit bounded by triggerPrice ± slippageBps with direction-specific execution, adding context about order handling not captured by readOnlyHint/destructiveHint=false.

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

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

Concise three sentences: purpose, side constraint, execution details. Front-loaded with key action and no redundant 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 essential behavior—trigger, side rules, execution mechanism—for a stop loss placement. Lacks return value details but acceptable given no 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?

Adds semantics for side (closing direction) and slippageBps (execution bound, default 500 bps), but market, size, and clientId are not elaborated, partly compensating for 17% schema description coverage.

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

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

The description clearly states the tool places a 'reduce-only Stop loss (conditional market order)' triggered at triggerPrice, differentiating it from sibling tools like place_take_profit by emphasizing the closing side constraint.

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 side direction requirements ('SELL closes a LONG, BUY closes a SHORT') implying usage for closing positions, but does not explicitly state when to use this vs. alternatives like place_take_profit or market orders.

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 provides extensive behavioral details beyond the annotations: reduce-only, IOC limit execution, slippage bounds, direction of execution, and the fact that it can cross the book. Annotations are minimal, so the description carries the full burden and excels.

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 that are information-dense yet clear. Every clause serves a purpose, and the key information is front-loaded in the first sentence. No wasted words.

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

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

Given 6 parameters and no output schema, the description covers the core behavior: trigger condition, execution type, slippage, and direction. It could mention what happens if the trigger is not hit, but overall it is sufficient for an agent 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?

Schema description coverage is only 17% (only slippageBps described). The description compensates by explaining the meaning of triggerPrice, side (closing side), and implying size is the close amount. It adds value but does not cover clientId.

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 places a reduce-only take profit conditional market order with specific trigger behavior. The verb 'place' and resource 'take profit' are precise, and the description distinguishes from sibling tools like place_stop_loss.

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 that the side must be the closing side (BUY closes a LONG, SELL closes a SHORT) and that it is reduce-only, giving clear context for when to use it. However, it does not explicitly mention when not to use it or compare directly to alternatives like place_stop_loss.

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 only state it is non-read-only, non-idempotent, and non-destructive. The description adds meaningful behavioral constraints: it moves USDC, cannot send funds elsewhere, is limited to the gas reserve, and can only target the account's own wallet. This goes beyond what the annotations provide.

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

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

The description is compact and front-loaded: the action, threshold, and purpose appear first, followed by constraints and the specific use-after-failure instruction. Every sentence contributes useful information without unnecessary repetition.

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

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

For a no-parameter, no-output-schema tool, the description covers the action, the trigger condition, the target reserve amount, the destination restriction, and the intended usage scenario. So basically all of the tool's behavioral surface is disclosed.

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

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

The tool has zero parameters and the schema is fully defined, so there is nothing for the description to add about parameter semantics. The baseline for a zero-parameter tool applies.

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

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

The description uses a specific verb and resource: moving USDC from the trading subaccount back to the WALLET to restore the $0.95 gas reserve. It clearly distinguishes this tool from the other trading, balance, and order-management 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?

It provides an explicit trigger: use it after a transaction fails for lack of gas, and when the wallet is at or below $0.55. It does not name an alternative tool, but the strict 'only gas reserve, only to own wallet' scope makes the usage context very 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 substantially discloses behavioral traits beyond the readOnlyHint annotation: it lists exactly what will be reported (both address forms, subaccount, permissions) and explicitly states what it 'CANNOT' do, such as withdraw, create wallets, reveal keys/mnemonics, or switch accounts. This helps an agent understand the tool as safe and non-mutating. It aligns with the readOnlyHint, so there is 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 dense but well-organized: front-loaded with the action ('Report what this session controls'), then detailed specific outputs, then explicit can't-do list, then a terse 'Call this first' usage tip. Every sentence carries useful information, including the clarifying parenthetical 'the same 20 bytes.'

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

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

For a no-parameter introspection tool with no output schema, the description doubles as an effective output contract. It describes almost all necessary return facets: account addresses in two formats, subaccount, trading capability, authorization scope, and explicit negations. This is complete enough for an agent to invoke and interpret the result without ambiguity.

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

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

The tool has zero parameters and the schema reflects this completely. Per baseline, 0 parameters means no descriptive burden. The description doesn't need to add parameter semantics, and it doesn't attempt to invent inputs.

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 with a specific verb and resource: 'Report what this session controls.' It enumerates the exact contents (master account in both cosmos/EV M forms, subaccount, trade/read-only status, auth scope, permissions). This distinguishes it from all siblings by establishing it as session introspection, not market data or trading.

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 usage context: 'Call this first, and use it to answer what is my address?.' This tells an agent when to invoke it, though it does not explicitly discuss exclusions or alternatives. Since there are no sibling tools that obviously duplicate this introspection role, concise context is sufficient.

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