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 readOnlyHint annotation indicates no destructive actions, and the description adds value by detailing the specific balance types (collateral and gas). No contradictions.

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

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

Two concise, front-loaded sentences. No redundancy; every sentence provides distinct information about the tool's function.

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

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

For a read-only tool with no parameters, the description sufficiently explains the output (collateral and gas balances). No output schema exists, but the description fills the gap 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?

There are no parameters, and the description effectively explains what the tool returns. With 100% schema coverage (none), the description adds necessary context.

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

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

The description clearly states the tool retrieves subaccount collateral (USDC) and on-chain wallet bank balances (gas). It specifies the exact resources and distinguishes itself from siblings like get_equity or get_pnl.

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

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

The description implies usage for checking balance types but does not explicitly state when to use it over alternatives (e.g., get_equity). No exclusions or prerequisites 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?

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?

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?

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?

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?

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?

Annotations already indicate readOnlyHint=true, and the description adds specific behavioral details (cannot withdraw/transfer) that confirm safety. The 'Call this first' instruction is a useful behavioral cue.

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

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

The description is two sentences, front-loading the purpose and ending with a clear call to action. No redundant information.

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

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

Given no parameters and no output schema, the description fully explains what the tool returns and when to use it. It is complete for the tool's simplicity.

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 0 parameters and schema coverage is 100%, so the description does not need to add parameter details. Baseline score of 4 applies.

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

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

The description clearly states the verb 'Report' and the resource 'this session', detailing the specific information returned (account, trading capability, authorization scope) and that it cannot withdraw/transfer. This distinguishes it from sibling tools that are all trading actions.

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

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

Explicitly says 'Call this first', providing strong guidance on when to use this tool. The description explains what it reports, so the agent knows it's for obtaining session context before other operations.

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