Rubin Exchange

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

Annotations already declare idempotentHint=true and destructiveHint=true, so the safety profile is clear. The description adds that the operation is performed in one transaction and is limited to SHORT_TERM orders, which is useful but does not deeply disclose behavior like error handling or result format.

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

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

The description is two sentences with no unnecessary words. It is front-loaded with the core action and immediately provides differentiation from siblings. Extremely 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?

The description covers key constraints (order type, batching) and sibling alternatives, but lacks information about return values (no output schema) and does not explain parameter semantics. For a tool with 2 required params and no output schema, it is partially complete.

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

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

Schema description coverage is 0%, so the description must compensate. It does not explain that 'market' identifies the trading market and 'clientIds' are the order client IDs. The parameter names are somewhat self-explanatory, but the description adds no explicit semantics or constraints beyond what the schema provides.

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

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

The description clearly states the verb 'Cancel', the resource 'multiple SHORT_TERM orders', and the context 'in one tx'. It also distinguishes from the sibling tool 'cancel_all_orders' by specifying the order type limitation.

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 (for SHORT_TERM orders) and when not (for stateful/mixed orders, use cancel_all_orders). It also mentions a chain limitation, providing clear 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?

Adds context beyond annotations: auto-handling of order types, return field 'remainingOpen', and retry advice. Contradicts no annotations; idempotentHint and destructiveHint are consistent.

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 then return/retry info. Every word earns its place, no redundancy.

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

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

Explains return value and retry logic. Lacks error conditions or prerequisite info, but adequate for a relatively simple cancellation tool without 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?

Schema covers 50% of parameters with descriptions (confirm has description). Description does not elaborate on market format or confirm's default behavior beyond schema. Adds no new parameter-specific insight.

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 cancels every OPEN order for a subaccount in a market, automatically handles SHORT_TERM and LONG_TERM orders, and distinct from sibling tools like cancel_order (single) and batch_cancel (multiple but unspecified).

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?

Implicitly indicates use when wanting to cancel all open orders in a market, and mentions automatic type handling. Lacks explicit when-not-to-use or alternative tool references, but contextual clues from siblings are available.

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

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

Discloses return format ('confirmation' with possible values), code meaning, and potential mismatch behavior. Adds value beyond annotations (idempotentHint, destructiveHint) by detailing verification and retry guidance.

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 purpose. Second sentence is long but packs necessary details. Could be broken into structured points for readability, but still 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?

Covers return values, error states, and retry logic despite no output schema. Parameters are mostly explained. Missing explanation of market parameter, but overall adequate for a cancel operation.

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 low (17%), but description explains purpose of clientId, goodTilBlock, goodTilTimeSeconds, and orderFlags. Clarifies which good-til field to use per flags. Does not explain market or confirm beyond schema.

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

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

Clearly states 'Cancel a single order by clientId', specifying the resource (order) and action (cancel). Distinguishes from siblings like batch_cancel and cancel_all_orders by focusing on single order cancellation.

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 instructions for parameter selection based on order type (SHORT_TERM vs LONG_TERM/CONDITIONAL) and what to do if 'still_open' is returned. Lacks explicit mention of when not to use this tool versus alternatives.

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

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

Annotations are all false, so the description carries the full burden. It discloses the use of reduce-only market orders, respect for allowlist, slippage bounds, and the return of a result array. It does not mention potential destructive nature on positions, but the action is inherently 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 very concise, two sentences that front-load the action and efficiently convey key behavioral details without 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 no output schema and only two parameters, the description covers the essential behavior: how orders are placed, allowlist handling, slippage control, and post-action guidance. Could be slightly more explicit about return format 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?

Schema coverage is 50% (only slippageBps has a schema description). The description adds meaningful context for slippageBps (default, purpose), but does not mention the confirm parameter or its boolean 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 uses a specific verb 'Flatten' and identifies the resource 'every open perpetual position', clearly differentiating it from the sibling 'close_position' which targets a single position. The action is unambiguous.

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

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

Provides guidance on re-running with larger slippage if unfilled and mentions the operator market allowlist. However, it does not explicitly compare with alternatives like 'cancel_all_orders' or indicate 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?

Rich behavioral details: reads current position, flips side, sizes close, slippage bounds, and explains return outcome (unfilled/partially_filled). No contradiction with annotations (readOnlyHint=false, destructiveHint=false are not contradicted).

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

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

Well-structured with core action upfront. All sentences add value, though slightly verbose for a tool definition. Good balance of detail.

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

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

Covers algorithm, slippage, and errors. Lacks explanation of confirm parameter and precise return value structure. Without output schema, description compensates reasonably well.

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 75%. Description adds meaning for percent (default 100, floor to step size) and slippageBps (default 500, bounds). confirm parameter not elaborated but schema covers it.

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

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

Clearly states the tool closes all or part of an open perpetual position with a reduce-only market order. Distinguishes from siblings like close_all_positions and open_position.

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

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

Provides clear context for when to use: when you have an open position. Mentions error if no position. Lacks explicit alternatives but implies appropriate use.

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

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

The description adds context beyond the readOnlyHint annotation by specifying the data returned (collateral and gas balances). However, it does not disclose any behavioral traits such as authentication requirements, rate limits, or the format of the response. Given the annotation already indicates read-only safety, the description provides moderate additional value.

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

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

The description is extremely concise with two sentences that convey the core purpose. There is no extraneous information, and the key facts are front-loaded. Every sentence earns its place.

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

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

Given no output schema and zero parameters, the description provides a reasonable overview but lacks details on the exact output structure (e.g., whether it returns a single number or multiple fields). The mention of 'subaccount collateral' and 'on-chain wallet bank balances' hints at the output, but more completeness would help the agent understand the return format.

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

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

The tool has zero parameters, so the description cannot add parameter-level details. According to the rubric, baseline for 0 parameters is 4. The description appropriately focuses on the output rather than inputs, which is sufficient for this parameterless tool.

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

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

The description clearly states that the tool retrieves two specific types of balances: subaccount collateral (USDC) and on-chain wallet bank balances (gas). It uses the verb 'Get' and specifies the resources. However, it does not explicitly differentiate itself from sibling tools like get_equity or get_portfolio, which may return similar balance information, so it is not a perfect 5.

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

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

There is no guidance on when to use this tool versus alternatives such as get_equity or get_portfolio. The description provides no context about typical use cases, prerequisites, or exclusions, leaving the agent to infer usage from the name and sibling list.

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 useful context beyond that by stating it returns the latest chain block height and is used for goodTilBlock math. No behavioral contradictions are present.

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 that convey the purpose and a use case. Every word earns its place with no fluff or redundancy.

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

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

Given the tool has no parameters, annotations provide readOnlyHint=true, and there is no output schema, the description is fully complete. It explains what the tool does and why it's useful, which is sufficient for an agent to invoke it correctly.

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

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

The input schema has 0 parameters, so the baseline score is 4. The description does not need to add parameter information, and it does not attempt to invent any. This 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 name and title clearly state 'get_block_height' and 'Get latest block height'. The description specifies it returns the latest chain block height, which is a specific verb and resource. Among siblings, no other tool retrieves block height, so it is well-distinguished.

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

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

The description provides a clear use case: 'Useful for SHORT_TERM order goodTilBlock math.' This gives context for when to use the tool. However, it does not explicitly state when not to use it or mention alternative tools, but given the simplicity and uniqueness of the tool, this is acceptable.

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 indicates the tool is read-only (annotations already set readOnlyHint=true) and focuses on retrieving data. It does not add behavioral details such as rate limits, pagination, or data ordering, but it 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?

The description is two sentences, front-loaded with the core action, and contains no extraneous information. Every word is necessary.

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 the tool's purpose and use case, but given the lack of an output schema, it does not describe the return format (e.g., array of candle objects). This is a minor gap for a simple data retrieval tool.

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

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

Schema coverage is 80% (all required parameters and most optional have descriptions). The tool description does not elaborate on parameters beyond what the schema provides, so it meets baseline but adds no extra 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 clearly states the action ('Get'), the resource ('OHLCV candles'), and the key parameters ('for a market at a given resolution'). It also implies a singular market, distinguishing it from the sibling get_candles_multi.

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

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

The description mentions it is 'useful for trend/volatility analysis', which provides a use case but does not explicitly state when to use this tool versus alternatives like get_candles_multi or other analytical tools. No exclusionary guidance is provided.

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

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

Annotations confirm readOnlyHint=true, consistent with 'get'. The description adds value by disclosing the return format ({ candles: { <resolution>: [...] } }) and ordering (newest first), which are not in 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?

Two sentences, no waste, front-loaded with purpose. Every sentence earns its place, efficiently conveying multi-resolution capability and parameter usage tips.

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 3 parameters and no output schema, the description covers purpose, behavior, and parameter nuances. It could mention error conditions or pagination but is sufficient for an agent to invoke 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 coverage is 100% with parameter descriptions. The description adds context: limit default (50), payload size guidance, and default resolutions. This enhances understanding beyond the schema.

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

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

The description clearly states it retrieves OHLCV candles across multiple resolutions in one call. It specifies the default resolutions and return format, distinguishing it from the likely single-resolution sibling get_candles.

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 (read trend across timeframes) and how to adjust parameters (lower limit or pass resolutions subset). However, it lacks explicit instructions on when not to use or alternatives, though siblings imply get_candles for single resolution.

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 is true, and the description adds value by specifying the exact data returned (equity, freeCollateral, etc.), which goes beyond just stating it's read-only. 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?

Single sentence that is front-loaded with the tool's purpose and efficiently enumerates returned fields. 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?

For a zero-parameter read-only tool, the description fully covers the needed context. It lists all return fields, and since there is no output schema, the description fulfills the completeness requirement.

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 trivially 100%. The description adds context by listing what the tool returns, which is helpful despite no input parameters.

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

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

The description clearly states it gets the subaccount summary and lists specific fields like equity, freeCollateral, marginEnabled, open perpetual positions, and asset positions. This distinguishes it from sibling tools like get_balance or 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 implies when to use the tool (when needing account summary), but does not explicitly state when not to use it or mention alternatives. However, the context is clear given the tool name and sibling list.

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

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

Annotations provide readOnlyHint=true, matching description. Description adds data fields but no extra behavioral context like pagination or ordering.

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, efficient, and front-loaded. Could improve with structured listing of returned fields.

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?

Missing pagination details, ordering, subaccount specification. No output schema. Significant gaps for accurate invocation.

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

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

Description does not describe any parameters. Schema has 3 params with only market having a description (33% coverage). No parameter meaning added.

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

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

Description clearly states it retrieves executed fills with specific data fields (price, size, fee, liquidity). Distinct from siblings like get_open_orders 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?

Implied usage for subaccount trade history, but no explicit when-to-use or alternatives. Does not differentiate from get_balance, get_pnl, etc.

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 set readOnlyHint=true, so the description does not need to reiterate non-mutability. It adds value by listing specific data fields returned (e.g., clobPairId, atomicResolution), which helps the agent understand the tool's output beyond the 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 is a single sentence that front-loads the purpose and lists key data fields. No extraneous information. 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?

The tool has no output schema, so the description must compensate by indicating return values. It lists several fields, giving a good sense of the response. Could mention that it returns a single object, but the list suffices for this simple tool.

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

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

The single parameter 'market' is fully described in the schema with an example. The tool description does not add further semantics; it merely restates the purpose. With 100% schema coverage, baseline 3 is appropriate.

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

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

The description is concise and specific: 'Get details for one perpetual market' with a clear list of returned fields. This distinguishes it from siblings like list_markets (which lists multiple) and other read tools.

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

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

The description implies usage when you need details on a single market. It does not explicitly state when to avoid using it or name alternatives, but the sibling list includes list_markets for comparison, providing implicit context.

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

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

Annotations already set readOnlyHint=true. Description adds valuable context: no importance field (user judges impact), headlines in ru/en, and structure of returned items. 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?

Description is concise (4-5 sentences), front-loaded with purpose, and every sentence adds unique value. No fluff.

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

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

Despite no output schema, description details return fields (source, url, etc.) and notes missing importance field. With 5 parameters and zero required, it covers filtering options well and explains usage context.

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

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

Schema coverage is 100%, and description adds meaning: explains filtering logic, matching behavior of query (text and hashtags), and examples like BTC. It clarifies relationship between category and channels.

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 fetches latest headlines from the ritbit news feed, specifying the curated channels (crypto/markets/business) and ordering (newest first). It distinguishes from sibling tools (mostly trading) by being a news-specific tool.

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: use for sentiment/catalysts or answering 'what's latest'. It also notes absence of importance field. While it doesn't explicitly state when not to use, the context implies it's for news gathering, distinct from trading actions.

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. The description adds valuable behavioral context: includes both resting and untriggered conditional orders, return format, and a note scenario when there are 0 orders. This goes beyond the annotation 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 three concise sentences, each serving a clear purpose: core function, return format, and exclusion with fallback note. No fluff, well front-loaded.

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

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

Despite no output schema, the description covers return format and a specific edge case. It could elaborate on order fields or pagination, but is largely complete for a read-only list tool.

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

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

Schema description coverage is low (33%). The description explains the 'market' and 'side' parameters in context, but does not mention the 'limit' parameter, leaving its purpose ambiguous. This partially compensates but misses full param explanation.

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 the subaccount, with optional filters by market and side. It distinguishes from filled positions and directs to get_positions, making the purpose unambiguous and distinct from siblings.

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

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

The description explicitly states what the tool includes (open resting and untriggered conditional orders) and excludes (filled positions), and mentions when to use get_positions. However, it does not provide guidance on when to use this tool vs. order manipulation tools like cancel_order.

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. Description adds 'live' and 'truncated' but no additional behavioral traits like rate limits or data freshness.

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 clear sentence with no waste. Perfectly concise.

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

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

For a simple read-only retrieval tool with no output schema, the description is sufficient. No missing information required for agent to use 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 covers both parameters fully (100% coverage). Description only loosely echoes parameter info ('optionally truncated to a depth') without adding new 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?

Clearly states verb 'Get', resource 'live orderbook', and scope 'for a market, optionally truncated to a depth'. Distinguishes from sibling tools like get_market or get_candles.

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

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

No guidance on when to use this tool versus alternatives (e.g., get_market, get_candles). Does not mention 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 is consistent with the readOnlyHint annotation, indicating a read-only operation. It adds context about returning historical ticks over time. However, it does not discuss behavior around pagination, empty results, or any potential side effects. Given the annotation already covers safety, a score of 3 is appropriate.

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 just two sentences (20 words), capturing the core purpose and a key usage hint. It is front-loaded with the action and resource, containing no filler or repetition. Every sentence earns its place.

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

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

For a tool with 3 parameters and no output schema, the description covers the main return fields (equity, totalPnl, netTransfers) and the essential time-bounding parameter. However, it omits guidance on pagination behavior and expected response shape, which would help an agent fully understand usage. The presence of readOnlyHint reduces the gap somewhat.

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 createdOnOrAfter has a description). The description adds value for this parameter by stating its use for bounding the range. However, the other parameters (page, limit) are left undocumented in both the schema and description, despite their role in pagination. For a low-coverage scenario, more explanation was 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 clearly states the verb 'Get' and the resource 'historical PnL ticks', specifying the subaccount scope and the fields included (equity, totalPnl, netTransfers). It distinguishes this tool from siblings like get_equity (which likely provides a snapshot) by emphasizing the time series nature.

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, giving a usage hint. However, it does not explicitly state when to use this tool versus siblings like get_equity or get_portfolio, nor does it provide guidance on pagination (page, limit). More explicit contrasting would improve this dimension.

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, so the agent knows it's a safe read. The description adds useful behavioral context: it's a 'one-call snapshot' that aggregates multiple data types including margin risk calculation, which goes beyond the annotation's binary safety flag.

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, well-structured paragraph that front-loads the purpose, lists the returned data components, and gives usage examples. Every sentence adds value without redundancy.

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

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

The description fully explains the tool's output in sufficient detail for an AI agent: it lists equity, freeCollateral, open positions (with notional, unrealized PnL, estimated liquidation price), active orders (resting + untriggered TP/SL), and account margin risk. Since there is no output schema, the description carries the burden of explaining return values and does so thoroughly.

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

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

There are no parameters, so the input schema is fully documented. The description does not need to add parameter info, and it correctly omits any mention of parameters.

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

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

The description explicitly states what the tool returns: a comprehensive snapshot including equity, freeCollateral, open positions with details, active orders, and margin risk. It gives specific use cases and distinguishes from sibling tools by saying it returns both orders and positions, so the agent doesn't need to worry about ambiguity.

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

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

The description provides clear use cases ('what do I have open?' or 'how am I doing?') and implies this tool is best when the user might mean orders or positions. However, it does not explicitly state when to use the more specific sibling tools like get_open_orders or get_positions instead.

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?

Although annotations already declare readOnlyHint=true, the description adds significant behavioral context: it explains the meaning of maintenanceMarginBufferUsd, marginUsageRatio, account leverage, and per-position details. This goes well beyond the annotation.

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

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

The description is a single dense sentence that efficiently conveys all necessary information. It could be slightly improved by breaking into shorter sentences, but it is front-loaded with key metrics and uses no filler.

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

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

Given no parameters, a readOnly annotation, and no output schema, the description is remarkably complete. It explains the exact metrics returned and their meaning, including the liquidation guard interpretation, leaving no major gaps for a read-only tool.

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

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

With 0 parameters and 100% schema coverage, the baseline is 4. The description does not need to add parameter info, and it correctly describes what the tool returns without referencing 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 tool returns margin health for the subaccount, listing specific metrics. However, it does not explicitly differentiate from sibling tools like get_positions, which might also return position-level data.

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

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

The description explicitly says 'Use before adding risk or to decide whether to protect/close a position,' providing clear context for when to use the tool. No when-not-to-use guidance is given, but the read-only nature is implied.

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. Description further clarifies that positions are not orders and notes the default status filter. No contradictions; adds value 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?

Two sentences: first states purpose and returned fields, second clarifies concept and usage. No wasted words, front-loaded with key information.

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

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

For a simple 1-param tool without output schema, description covers purpose, default behavior, relationship to siblings, and returned fields. Fully adequate.

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

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

Schema has 1 parameter with enum and description, coverage 100%. Description adds default behavior insight: 'Defaults to OPEN positions', which is not in the schema. This helps agents infer behavior when status is omitted.

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

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

Description clearly states 'Get perpetual POSITIONS' and lists specific fields returned (size, side, entryPrice, etc.). It distinguishes positions from open orders, differentiating from sibling tools like get_open_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 says 'Defaults to OPEN positions' and advises when to use this tool vs get_open_orders or get_portfolio. Provides clear context on how to handle ambiguous user requests.

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 read-only nature is covered. The description adds detail on the returned fields (ticker, status, oracle price), which is helpful but not extensive. 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 consists of two concise sentences. The first states the tool's function, and the second provides usage guidance. Every sentence is necessary and adds value without redundancy.

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

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

Given the tool has no parameters, no output schema, and the readOnly annotation covers safety, the description sufficiently explains what is returned (ticker, status, oracle price) and the use case. It is complete for a simple listing 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 no parameters, so the description does not need to explain them. With schema coverage at 100% (empty schema), a baseline of 4 is appropriate.

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

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

The description clearly states the verb 'list' and the resource 'all perpetual markets', specifying the fields returned (ticker, status, oracle price). It also differentiates from sibling tools by advising to use it first to discover valid market tickers before placing 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 explicitly says 'Use this first to discover valid market tickers before placing orders', providing clear context for when to use the tool. It does not mention exclusions or alternative tools, but the guidance is sufficient for the intended use case.

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 it is not read-only, idempotent, or destructive. The description adds rich behavioral context: market order execution, size/notionalUsd mutual exclusivity, bracket legs placed only if entry succeeds, reduce-only nature, execution bound, and slippage cap. 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 clear, front-loading the main action and detailing constraints progressively. Each sentence adds value, though it could be slightly more concise without losing information.

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

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

With no output schema, the description covers return values (confirmation, bracket IDs) and main behavior (entry with conditional orders). It lacks error conditions or handling of partial failures, but the complexity (8 parameters) is well-addressed.

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 75%, but the description adds significant meaning: explains mutual exclusivity of size and notionalUsd, conversion details, default slippage, and bracket parameters' behavior (reduce-only, opposite side, execution bound). This goes well beyond schema descriptions.

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

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

The description clearly states the tool enters a new position with a market order and optionally attaches bracket orders. It distinguishes itself from siblings like place_market_order (which lacks position context) and close_position by focusing on opening a new position with conditional 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 specifies when to use (entering a new position with a market order) and when to use bracket attachments. However, it lacks explicit exclusion of alternatives like place_market_order for simpler market entries or place_stop_loss/place_take_profit for standalone conditional 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?

Excellently discloses behavioral traits: explains the broadcast-commit vs async nature of GTT and SHORT_TERM, the meaning of broadcast code 0 vs actual fill status, and rate limiting. This goes well beyond what annotations provide (readOnlyHint=false, etc.), adding significant value.

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 sentences) and informative, front-loading the purpose. It could be slightly more structured (e.g., separate sections for behaviors), but it is efficient and easy to read.

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 (11 parameters, no output schema), the description covers key behaviors (timeInForce, confirmation, rate limits) and explains the return format. It is fairly complete but could benefit from brief explanations of less common parameters like postOnly and reduceOnly.

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 55%, so some parameters lack schema descriptions. The description adds context for timeInForce and confirm, but does not elaborate on other parameters like postOnly, reduceOnly, clientId, etc. It provides moderate added value beyond the schema.

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

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

The description clearly states 'Place a limit order', which is a specific verb and resource. It does not explicitly differentiate from sibling tools like place_market_order or place_stop_loss, but the purpose is well-understood.

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 detailed guidance on when to use GTT vs SHORT_TERM timeInForce, mentions rate limiting for stateful orders, and explains how to interpret the confirmation result. However, it does not advise when to choose a limit order over a market order, which is a notable omission given sibling tools.

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

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

Beyond annotations, the description explains critical behavioral details: IOC execution, slippage cap relative to oracle, reduceOnly, and the distinction between broadcast acceptance and actual fill. It warns about using confirmation.outcome vs code. This adds significant value.

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

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

The description is efficient, with each sentence serving a purpose. It front-loads the key action ('Place an IOC market order') and logically proceeds to details on slippage, reduceOnly, and outcome handling. No unnecessary 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?

Despite no output schema, the description explains the return value (confirmation) and its fields, including outcome types and how to interpret them. It covers the complexity of IOC orders and potential edge cases, making it complete for usage.

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

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

Schema coverage is 57% (4/7 parameters have descriptions). The description adds meaning by explaining the default slippageBps (500) and how it works relative to side, and that reduceOnly closes an existing position. It does not add much for clientId or confirm but compensates for the gaps.

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

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

The description clearly states the tool places an IOC market order, detailing the slippage cap and side-specific behavior. It distinguishes itself from sibling tools like place_limit_order by specifying the market order execution 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 guidance on when to use this tool (IOC market order) and how to handle outcomes (retry with larger slippage if unfilled/partially_filled, wait if pending). It lacks explicit comparison to alternative order types but the context is strong.

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 neutral. The description discloses that it is reduce-only, triggers as IOC limit with slippage bounds, and explains execution direction relative to trigger. This is sufficient behavioral context beyond annotations.

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

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

Two sentences packed with information. Front-loaded with key purpose, then execution details. 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?

Covers trigger, side, execution mechanics, and slippage. No output schema, but return is likely standard. Does not mention cancellation or replacement, but is complete for a stop loss tool.

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

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

Schema coverage is low (17%), but the description compensates by explaining side (closing side), triggerPrice, and slippageBps (execution bound, default 500). Market, size, clientId are not explained but are self-explanatory.

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 places a reduce-only stop loss (conditional market order) with trigger price and execution details. It specifies the side must be the closing side, distinguishing it from sibling open/close tools.

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

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

It explains that side must match closing side and provides guidance on raising slippage for thin books. While it doesn't explicitly say when not to use, the context of stop loss for risk management is clear.

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

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

The description provides rich behavioral detail beyond the minimal annotations: it is reduce-only, triggers at triggerPrice, executes as IOC limit bounded with slippageBps, and explains the direction of execution relative to the trigger. This fully compensates for the lack of behavioral info in 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 succinct sentences that front-load the core purpose and add critical behavioral details without waste. Every word is informative and necessary.

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, no output schema, and minimal annotations, the description covers the essential aspects: order type, trigger, side, execution behavior, and slippage. It lacks info on return values or clientId usage, but is adequate for a conditional order tool.

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

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

Schema coverage is only 17% (one param documented), but the description adds meaning for key parameters: triggerPrice (triggers order), side (closing side), size (for position close), and slippageBps (default 500, thin book use). It does not detail market or clientId, but the overall order logic is 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 the tool places a reduce-only take profit conditional market order triggered at a specific price. It specifies the side constraint (SELL for LONG, BUY for SHORT) and distinguishes from siblings like place_stop_loss by explicitly labeling it as a take profit.

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

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

The description explains when to use the tool (to take profit on an existing position) and the required side constraint. It does not explicitly mention alternatives or when not to use it, but the sibling list includes place_stop_loss, allowing inference.

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

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

The description adds behavioral context beyond the readOnlyHint annotation by detailing the reported information (e.g., authorization scope, inability to withdraw/transfer). 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 a single, focused sentence that front-loads the core purpose and lists specifics efficiently. Every part adds value without redundancy.

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

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

Given no parameters and no output schema, the description sufficiently covers what the tool reports. It provides complete guidance for the agent to understand the tool's output.

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 schema coverage is 100%. The description doesn't need to add parameter info, meeting the baseline expectation for zero-parameter 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 specifies the tool's purpose with 'Report what this session controls' and lists specific details (master account, subaccount, trading ability, authorization scope). It distinguishes from sibling tools that handle trading, orders, and market data.

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

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

The description explicitly states 'Call this first.', providing a clear directive for when to invoke the tool. This is actionable and helps the agent prioritize the tool over siblings.

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