RubinTrade

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so safety is covered structurally. The description adds genuine context beyond that: the operation is atomic ('in one tx') and constrained by a chain limitation to SHORT_TERM orders. It stops short of stating the failure mode when a non-SHORT_TERM id is included or partial-cancel behavior.

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 core action and scope, followed immediately by the constraint and the alternative. 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?

Purpose, scope, constraint and sibling routing are all covered, and annotations carry the safety profile, so no output schema is needed. However, with zero schema descriptions, both required parameters remain semantically opaque, leaving a real gap for a destructive batch 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 description coverage is 0% – neither 'market' nor 'clientIds' is described in the schema. The description implies multiple orders are targeted (consistent with clientIds) but never explains the market identifier format, the meaning of clientIds, or the 100-item cap. It fails to compensate for the coverage gap.

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

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

States a specific verb (Cancel), a resource (multiple SHORT_TERM orders), and a scope (in one tx). It explicitly distinguishes itself from the sibling cancel_all_orders by naming which order types each handles, so an agent can route without opening either schema.

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 gives the when-not (SHORT_TERM only, due to a chain limitation) and names the alternative tool for stateful/mixed orders. This is exactly the when/when-not/alternative pattern.

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 destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered. The description adds genuine value beyond that: it discloses the return field `confirmation.remainingOpen`, its meaning (0 = all gone), and a retry condition. It does not mention auth/permission requirements, which would have pushed it higher.

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 tight sentences, front-loaded with the action and scope, followed by the return-value and retry semantics. No filler; every clause 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?

With no output schema, explaining the `confirmation.remainingOpen` return value and the retry rule is exactly what is needed, and annotations cover the destructive/idempotent profile. Only the parameter-level details (market format, confirm behavior) are thin, but the core call path 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 50%: the `confirm` parameter is documented in the schema but `market` only carries a regex pattern. The description clarifies the market scope ('for the subaccount in a market') but does not explain the market format or reference `confirm` at all, so it only partially compensates for the gap.

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

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

States a specific verb (Cancel) plus resource and scope: 'every OPEN order for the subaccount in a market,' with the extra detail that SHORT_TERM and LONG_TERM are handled automatically. An agent can distinguish this from cancel_order, though the overlap with the sibling batch_cancel is not explicitly addressed.

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

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

Usage is implied by the scope ('every OPEN order ... in a market') and there is operational guidance to retry if remainingOpen > 0, but there is no explicit when-to-use/when-not or routing to cancel_order or batch_cancel. The retry note is the only real guidance beyond the name.

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

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

Annotations flag destructive/idempotent but say nothing about the asynchronous cancel model. The description supplies that: it explains the confirmation result values, warns that code 0 only means broadcast (not a confirmed cancel), and gives recovery guidance on still_open. That is exactly the behavioral context annotations cannot carry.

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

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

Front-loads the core action, then layers parameter selection, return semantics, and retry advice in tight sentences. Dense but every clause carries operative information; the nested parentheticals cost a little readability.

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

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

With no output schema, the description correctly takes on return-value explanation and the failure/retry path for a destructive mutation tool. It omits any note on permissions or whether a re-cancel is safe (idempotency is only implied by annotations), leaving a small gap.

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

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

Schema description coverage is only 17%, so the description must compensate, and it does for the hardest parameter interaction: which good-til field to supply based on orderFlags, and where that value comes from. market, clientId, and orderFlags receive no added semantics, so it does not fully close the coverage gap.

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

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

States a specific verb and resource with explicit scope: 'Cancel a single order by clientId.' The word 'single' cleanly separates it from the sibling tools batch_cancel and cancel_all_orders without the agent needing to open a schema.

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?

Gives concrete decision rules for the tricky case (pass goodTilBlock for SHORT_TERM, goodTilTimeSeconds for LONG_TERM/CONDITIONAL), points to get_open_orders as the source of the good-til value, and prescribes a retry on still_open. It does not name when to prefer alternatives like batch_cancel or cancel_all_orders, so it stops short of full when/when-not routing.

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?

Goes well beyond the annotations (which only say non-readonly, non-idempotent, non-destructive) by disclosing side-flipping logic, step-size flooring, oracle±slippage bounds with a concrete 5% default, the returned confirmation outcome, remediation for unfilled/partially_filled, and the NOT_FOUND error. This is unusually rich behavioral context.

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

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

Front-loads the core action and then layers mechanics efficiently, with no filler sentences. It is dense but every clause carries operational information; slightly long for a single paragraph but justified by the tool's complexity.

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

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

For a mutation tool with no output schema, the description covers the return outcome (confirmation), failure remediation, and error conditions, which is exactly what an agent needs to call and recover. Nothing essential is missing.

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

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

Schema coverage is 75% and already describes percent and slippageBps, but the description adds real meaning: percent defaults to 100, partial closes are floored to the market step size, and slippageBps is mirrored by side with a 500 bps default. The undocumented `confirm` parameter is left unexplained, keeping it below 5.

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

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

States a specific verb (close) and resource (perpetual position) with the exact mechanism (reduce-only MARKET order). It is clearly distinguishable from siblings like close_all_positions or place_market_order because it scopes to a single market and a specific reduce-only semantics.

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

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

Explains when to use it (closing all or part of an open position, partial close behavior) and documents the error path when no position exists. It does not explicitly name or contrast with close_all_positions, so the 'vs alternative' guidance is implied rather than stated.

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

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

The annotations only provide generic non-read-only and non-idempotent flags. The description adds materially useful behavioral detail: it is an internal transfer, the trading key alone is allowed to make it, the $0.95 gas reserve is preserved, and the default behavior matches the web app. This is exactly the kind of context an agent needs before calling.

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 appropriately sized and well structured: a clear first sentence naming the operation, two sentences explaining the amount semantics, and a final sentence giving the invocation condition. Every sentence earns its place with no filler or restated annotations.

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 one-optional-parameter tool with no output schema, the description is complete enough: it covers purpose, amount behavior, gas-reserve constraint, auth context, and when to use it. An agent can confidently select and invoke the tool without consulting additional 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?

The schema already documents amountUsd at 100% coverage, so the baseline is a 3. The description adds value by explaining the optional behavior precisely: omitting the parameter moves everything above the $0.95 reserve, while providing a value moves exactly that much only if the reserve remains intact. This justifies slightly above 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 states a specific verb and resource: deposit USDC from the wallet into the trading subaccount so it becomes collateral. It also explicitly clarifies that funds never leave the account, immediately distinguishing this from external transfer or withdrawal 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 gives an explicit use case: use it when the user has sent money and the subaccount collateral is 0 or too low to trade. It also explains the two modes (with and without amountUsd). It does not explicitly name a sibling alternative or a when-not-to-use condition, so it stops just short of a 5.

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

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

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

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

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

Three sentences, each earning its place: the first names the resources being fetched, the second clarifies the collateral versus wallet distinction, and the third explains the summary field and next actions. Information is front-loaded and nothing is redundant.

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

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

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

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

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

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

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

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

The description uses a specific verb and identifies two distinct resources: the subaccount collateral balance and the on-chain wallet bank balance. It also disambiguates these two concepts clearly, which helps an agent understand what this tool reports and what it does not.

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

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

The description gives clear context about when the balances matter and explains the suggestedAction field, including conditions for depositing spare USDC or topping up gas. It does not explicitly provide exclusionary routing against sibling balance tools, so it stops slightly short of a full 5.

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

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

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 readOnlyHint annotation already establishes a safe read operation. The description adds the return data type (OHLCV) and a common analysis use case, but does not disclose pagination, default time range, ordering, or the limit cap, so it only partially covers behavior 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?

Two short sentences, front-loaded with the core action and followed by a compact use case. No filler or redundancy; every sentence earns its place.

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

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

For a five-parameter read-only market-data tool with no output schema, the description is adequate but incomplete. It omits the optional limit parameter and time-range behavior, and does not describe the candle return shape beyond the 'OHLCV' acronym, leaving some gaps an agent may need to infer from the 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 coverage is 80%, with descriptions for market, resolution, fromISO, and toISO; only limit lacks a schema description. The description mentions market and resolution but adds no format, default, or temporal-window semantics beyond what the schema already provides, so 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 states a specific verb (Get) and resource (OHLCV candles) with scope (for a market at a given resolution). It is clear what the tool returns, but it does not explicitly distinguish itself from the sibling get_candles_multi, so it stops short of a 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?

'Useful for trend/volatility analysis' gives a generic use case but does not say when to choose this tool over alternatives like get_candles_multi or get_orderbook. There are no exclusion conditions or comparative guidance.

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

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

Annotations only declare readOnlyHint=true; the description adds genuinely new behavioral detail beyond that: the return envelope { candles: { <resolution>: [...] } }, the newest-first ordering, and the payload-size tradeoff. It doesn't mention rate limits or pagination, but it goes well past what the annotations provide.

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

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

Three sentences, zero filler, and the most decision-relevant fact (multiple resolutions in one call) is front-loaded. The defaults and the payload-reduction tip are placed after the core purpose, which is the right ordering.

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 output schema, the description supplies exactly the missing pieces: the response shape, ordering, defaults, and cost-control levers. Nothing an agent needs to invoke it correctly is absent.

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 earns an extra point by adding practical semantics the schema lacks — the rationale for shrinking `limit` (e.g. 20) and the fact that omitting `resolutions` yields all indexer resolutions. It reinforces rather than merely repeats the enum list.

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

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

States a specific verb (get) and resource (OHLCV candles) and immediately pins the distinguishing scope: multiple resolutions in a single call, with the default set enumerated. An agent can tell this apart from the single-resolution sibling get_candles without opening either schema.

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?

Gives clear context for use (read the trend across timeframes at once) and practical guidance for reducing cost (lower `limit`, or pass a `resolutions` subset). It does not explicitly name get_candles as the alternative for single-timeframe reads or state when this tool is the wrong choice, so it stops short of full routing guidance.

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

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

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

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

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

The description is dense but well-packed: it front-loads the core purpose, then enumerates precisely what the response contains, and closes with one relevant cross-reference. Every clause supports the agent's decision to use or understand the tool.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds genuine context beyond that by narrowing scope to executed (not open/cancelled) fills for the subaccount. It says nothing about pagination, default result size, or sort order, so it does not go far beyond the annotation baseline.

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

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

A single well-formed sentence with the core action front-loaded and no filler. It is appropriately sized, though it spends its words on return fields rather than the parameters that need explanation.

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 usefully names key returned fields (price, size, fee, maker/taker liquidity). However, it omits pagination behavior and default limit semantics for a paged list tool, leaving real gaps for a 3-parameter endpoint.

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' is documented), so the description must compensate for page and limit, and it does not — neither parameter is referenced. The field list describes return values, not the 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?

States a specific verb and resource ('Get executed fills') plus the scope ('for the subaccount') and enumerates the returned fields. An agent can distinguish this from get_open_orders or get_orderbook, though the description never names those siblings to reinforce the distinction.

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

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

There is no explicit when-to-use statement, no exclusion against alternative history/order tools, and no mention of prerequisites or how to page through results. 'Executed fills' only implicitly suggests historical trade lookup rather than open 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?

With readOnlyHint already present, the description goes beyond the annotation by disclosing the wallet is not collateral, depositableUsdc is wallet minus a $0.95 gas reserve, and suggestedAction can be one of three values. This gives meaningful behavioral context beyond the structured 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 dense but well-structured: first the central distinction, then the returned fields, then the exact call context. Every sentence contributes useful information; there is no filler or repetition of the tool name.

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 needs to cover return semantics, and it does so well by enumerating depositableUsdc, gas low status, and suggestedAction. It also sufficiently explains the wallet vs subaccount distinction, making the tool callable and interpretable without external documentation.

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

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

The tool has zero input parameters and schema coverage is 100%, so there are no parameter semantics for the description to supply. The baseline for 0-parameter tools is 4; the description even compensates by explaining the meaning of returned fields, which matters because there is no output schema.

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

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

The description clearly identifies the tool as a status readout: where USDC sits (wallet vs trading subaccount) and the three outputs returned. It distinguishes from sibling tools like get_equity or get_balance by framing the wallet/subaccount distinction, so an agent can tell when this tool applies.

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

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

It gives explicit call triggers: 'when the user says they sent funds, when collateral reads 0, or before any funding decision.' It does not explicitly state when not to use it or name a specific alternative tool, but it does provide actionable context and surfaces the suggested follow-up 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?

The annotations only declare readOnlyHint=true, but the description adds meaningful behavioral context beyond that: the leaderboard is scoped to a time span, is paginated, includes this account's own row via `me` when ranked, and lists the returned metrics. These behaviors are not merely restating the annotation and help the agent anticipate the tool's output and scope.

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

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

Three sentences, each carrying distinct information: what the board contains, the `me` row behavior, and a pointer to the sibling tool for a simpler use case. The most critical facts are front-loaded in the first sentence. No redundant phrases 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?

Despite having no output schema, the description states the output columns, the pagination behavior, the available time spans, and the special `me` row. It also covers the main alternative tool, get_my_rank, which is the most likely source of confusion. Everything an agent needs to decide whether and how to call this tool is present.

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

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

The input schema has 100% coverage, so every parameter is already documented with descriptions, defaults, and enums. The tool description does not need to repeat parameter details. It adds some conceptual context around the leaderboard shape but does not add meaning beyond the schema in a way that raises the score.

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

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

The description states a specific verb and resource: 'the trader PnL leaderboard for a time span'. It enumerates the exact fields returned (rank, username, address, PnL, ROI, current equity) and distinguishes this from get_my_rank by explicitly saying that the latter returns this account's rank across all time spans at once. An agent can understand exactly what get_leaderboard does without 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 explicitly says to use the `search` filter for finding a trader by username or address, and directs the agent to `get_my_rank` when wanting this account's rank across all time spans at once. This provides clear when-to-use and when-not-to-use guidance relative to a direct sibling. The context is sufficient for an agent to choose the correct 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?

readOnlyHint=true already tells the agent this is a safe read, so the bar is lower. The description adds the field-level contents of the response, which is useful since no output schema exists, but discloses nothing about error behavior for an invalid ticker or any rate limits.

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

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

A single front-loaded sentence that identifies the resource and enumerates the payload with zero filler. Nothing could be cut without losing information.

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

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

For a one-parameter read-only tool with no output schema, the description compensates by listing the returned fields (clobPairId, tick sizes, oracle price, status). The only real gap is the missing explicit tie-breaker against list_markets.

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 single 'market' parameter is fully documented with a pattern and an example ('BTC-USD'). The description adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb+resource ('Get details for one perpetual market') and enumerates the returned fields, which is more than the title restates. It implies differentiation from list_markets by emphasizing 'one', but never names the sibling, so an agent must infer the single-vs-many split.

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 word 'one' implies you use this when you already have a single market ticker, contrasting implicitly with list_markets, but no when-to-use, when-not, or prerequisite is stated. Usage is left to inference rather than guidance.

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

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

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

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

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

The description is two tight sentences: the first front-loads the return payload and the optional parameter behavior, and the second clarifies null semantics. No filler or redundant restatement.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Annotations 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 only declare readOnlyHint=true; the description goes well beyond that by disclosing the composition of results (resting + untriggered conditional orders), the return envelope { orders: [...] }, and a conditional `note` field that appears when zero orders coexist with open positions. With no output schema present, this return-shape disclosure is exactly the burden the description must carry.

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

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

Four short sentences, front-loaded with the core purpose, then progressively adding return shape and the get_positions boundary. Nothing is redundant and every sentence carries distinct 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 read-only list tool with no output schema, it covers result shape, membership rules, and the sibling it is often confused with. The only shortfall is the silent `limit` parameter, whose pagination semantics an agent must still guess at.

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% — `market` is documented and enum-constrained `side` is self-explanatory, but `limit` (max 100, exclusiveMinimum 0) is undocumented in both schema and description. The description's 'optionally filtered by market and side' restates the two obvious params without adding format or pagination meaning, so it does not compensate for the gap.

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

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

States a specific verb and resource ('Get currently active ORDERS for the subaccount') with scope and filter dimensions. It explicitly separates itself from get_positions by declaring that filled orders leave no open order, so an agent can distinguish the two without reading either schema.

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?

Gives a clear inclusion rule (open resting orders plus untriggered conditional TP/SL) and an explicit exclusion with a named alternative ('a filled market/limit order leaves NO open order, it becomes a POSITION — see get_positions'). It lacks an explicit 'call this when...' phrasing, but the routing condition is unambiguous from the text.

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?

readOnlyHint=true already tells the agent this is a safe read, so the bar is lower. The description adds that the data is 'live' and that depth truncation is optional, but it does not disclose rate limits, pagination, or return shape. That is modest added value over 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?

A single front-loaded sentence with no filler. Every clause (live, bids/asks, for a market, optional depth) carries information and nothing is redundant.

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

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

For a read-only tool with full schema coverage and a readOnlyHint annotation, the description covers the essentials: what is returned and the optional truncation. It stops short of describing return structure or rate limiting, which is a minor gap given there is 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?

Schema description coverage is 100%: both 'market' and 'depth' are documented in the schema, including the depth max and exclusivity. The description's 'optionally truncated to a depth' merely restates the schema, so baseline 3 applies.

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

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

States a specific verb (Get) and resource (live orderbook) with the data shape (bids/asks), the scoping parameter (for a market), and the optional truncation. It is easily distinguished from siblings like get_market (metadata) and get_candles (OHLC).

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 says what the tool returns but gives no when-to-use guidance, no alternatives, and no exclusions relative to sibling market-data tools such as get_market or get_candles. Usage is only implied by the resource name.

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

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

readOnlyHint=true already tells the agent this is a safe read. The description adds the useful detail that the result is a series of 'ticks' containing equity, totalPnl and netTransfers, which is genuine context beyond the annotation. It is silent on pagination, ordering, and default range behavior, so it stops at adequate.

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, front-loaded with the verb and resource, no filler. Every clause carries information the agent needs.

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?

There is no output schema, so the description must carry return-value expectations — it partially does by naming the tick fields. However, for a paginated list tool it omits pagination behavior, ordering, and default time window, leaving real gaps an agent would want closed.

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 createdOnOrAfter is documented). The description clarifies that createdOnOrAfter 'bounds the range' but adds nothing about page or limit, their defaults, or how they interact with a tick stream. With two of three parameters undocumented in both schema and description, the description does not compensate for the coverage gap.

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

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

States a specific verb and resource ('Get historical PnL ticks for the subaccount') and enumerates the returned fields (equity, totalPnl, netTransfers over time), so the agent knows exactly what data shape to expect. It does not, however, distinguish itself from siblings like get_portfolio or get_equity, so it stops short of a 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?

The second sentence gives operational guidance on bounding the query with createdOnOrAfter, which implies the time-series use case. But it never says when to prefer this over get_equity/get_portfolio, nor does it mention pagination expectations, so usage is only implied rather than stated.

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

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

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

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

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

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

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

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

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

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

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

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

The description states a specific verb and resource: getting this account's referral/affiliate program status. It then enumerates a concrete set of returned fields (referral code, link unlock status, tier, fees, volume, earnings, referrer, tier table, parameters), making it unambiguous. There is no sibling tool covering referral/affiliate program data, so the scope already separates it from the trading/accounting tools.

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

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

The no-parameter, account-scoped 'status' wording gives a clear context: call this when the agent needs this account's referral program state. It does not explicitly document exclusion criteria, such as 'do not call before sign-up,' but there is no alternative sibling to consider, so the simple is adequate.

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

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

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?

With annotations only covering readOnly/idempotent/destructive hints, the description adds rich behavioral detail far beyond structured fields: market entry semantics, notional conversion at oracle and step-size flooring, bracket legs placed with opposite side and a 500 bps execution bound past trigger, bracket only placed if entry broadcast succeeds, and reduce-only enforcement preventing flips. This is exactly the kind of operation-specific transparency the dimension rewards.

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 front-loads purpose and sizing before bracket, slippage, returns, and safety details. Every sentence carries operational information: no filler, no repetition of obvious schema content. Length is appropriate for an 8-parameter mutation tool with bracket semantics.

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?

Although there is no output schema, the description explains the return value (entry confirmation plus bracket order ids). Combined with annotations, the description covers entry mechanics, bracket behavior, failure conditions, and sizing rules, leaving no significant gap for an agent to invoke this tool correctly.

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

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

Schema coverage is 75%, but the description adds substantial meaning beyond the schema: exactly one of size/notionalUsd is required, notionalUsd converts at oracle price and is floored to step size, slippageBps caps entry fill vs oracle with default 500, and stopLossPrice/takeProfitPrice are reduce-only conditional orders with specific placement behavior. These are non-obvious parameter relationships and conversions not captured in the schema.

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

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

The description states a specific verb and resource: 'Enter a NEW position with a MARKET order.' It clarifies scope with sizing logic and optional bracket attachments, which differentiates it from generic order-placement siblings. However, it never explicitly names or contrasts with specific alternatives like place_market_order or place_limit_order, so sibling differentiation relies on inference from the name and scope rather than explicit routing.

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

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

The phrase 'Optionally attach ... in the SAME call' implies the tool's use case: opening a new position and atomically attaching stop-loss/take-profit legs. Yet there is no explicit when-to-use vs. alternatives guidance (e.g., 'use this instead of place_market_order when you want a bracket'), nor any when-not-to-use or prerequisite conditions. Usage is therefore implied rather than stated.

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

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

Annotations only declare readOnly=false, idempotent=false, destructive=false — a very thin safety profile. The description adds genuinely decision-relevant behavior: rate limits on stateful GTT orders, the synchronous-vs-async broadcast difference between TIF modes, and critically that broadcast code:0 means the tx was accepted, not filled, so the agent must report from confirmation.outcome. That is far beyond what the 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?

Front-loaded with the core action before any caveats, and essentially every sentence carries operational information (defaults, rate limits, outcome semantics) rather than filler. It is a dense single block, though — the rate-limit and confirmation warnings would scan faster as distinct sentences or bullets.

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 an 11-parameter mutation tool with no output schema, the description covers the essentials: TIF behavior, rate limits, and the shape/meaning of the returned confirmation outcome including the pending case. Minor gaps remain (permissions/auth requirements, and the behavior of the undocumented reduceOnly/clientId parameters), but nothing that would cause a wrong invocation.

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

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

Schema coverage is 55% on 11 parameters, so the description must compensate, and it does: it explains timeInForce's default and the trade-off between its two enum values, plus the post-broadcast meaning of the confirm/confirmation path. It stays silent on reduceOnly and clientId, which are undocumented in both schema and description, so it doesn't fully close the gap.

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

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

States a specific verb ('Place') plus resource ('a limit order'), which inherently distinguishes it from place_market_order, place_stop_loss and place_take_profit in the sibling list. The description goes on to pin down the order's default semantics (GTT, durable, synchronous broadcast-error reporting), so an agent knows exactly what kind of order this creates.

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?

Gives explicit when-to-use guidance at the parameter level: default GTT for durable orders, SHORT_TERM only for latency-sensitive orders. It also warns to pace placements due to rate limits (2/block, 20 per 100 blocks). It does not, however, say when to pick this tool over place_market_order or the conditional-order siblings, so tool-level alternative routing is left to 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?

Goes well beyond the annotations (which only say non-readonly, non-idempotent, non-destructive). It discloses that IOC orders cancel UNFILLED, that broadcast code:0 only means acceptance not a fill, that fills occur at book prices with the cap limiting sweep depth, and that the authoritative result must come from confirmation.outcome.

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?

Dense but front-loaded: the execution model comes first, then outcome semantics and retry logic. Every sentence adds actionable information with 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?

With no output schema, the description takes on the burden of explaining returns and does so thoroughly, detailing confirmation.outcome values and how to interpret each. An agent has everything needed to call and interpret this tool correctly.

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

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

Schema coverage is 57%, so the description carries real weight: it explains side-dependent cap direction, slippageBps default (500 = 5%) and its role in sweeping a thin book, and reduceOnly closing an existing position. It leaves confirm and clientId unelaborated, but the high-value parameters are covered.

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

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

States a specific verb (place) and resource (market order) and immediately pins the execution model: an IOC limit at a worst-acceptable price mirrored around the oracle by side. This distinguishes it from place_limit_order and other order-entry siblings without needing to open either schema.

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?

Gives operational guidance on what to do when the outcome is unfilled, partially_filled, or pending, which tells the agent how to act. However, it never explicitly contrasts with siblings like place_limit_order or open_position, so the choice of when to prefer this tool over alternatives is left implicit.

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

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

Annotations only declare non-read-only, non-idempotent, non-destructive. The description adds real behavioral context: reduce-only enforcement, the trigger semantics, and post-trigger execution as an IOC limit bounded at triggerPrice ± slippageBps. It omits auth/permission requirements and what happens if a stop already exists.

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

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

Two sentences, front-loaded with the core action, and the dense second sentence carries only necessary execution detail. 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?

For a mutation tool with no output schema and thin parameter coverage, the description covers the mechanics an agent needs to place the order correctly. Gaps remain around response shape, idempotency/replacement behavior, and the undocumented parameters.

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%, so the description must compensate. It meaningfully explains side, triggerPrice, and slippageBps (default 500, raise for thin books), but leaves market, size, and clientId entirely undocumented in both schema and 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?

States a specific verb+resource with scope: 'Place a reduce-only Stop loss (conditional market order)'. The reduce-only and conditional-order framing clearly separates it from place_limit_order/place_market_order, though it never names a sibling tool explicitly.

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

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

It gives directional usage guidance for the side parameter (SELL closes LONG, BUY closes SHORT), which is genuinely useful. But it offers no when-to-use vs place_take_profit or place_limit_order, and no conditions under which this tool is the wrong choice.

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

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

Annotations only declare readOnly=false, idempotent=false, destructive=false, so the description adds real value by disclosing the trigger-to-execution mechanics: reduce-only, IOC limit conversion on trigger, slippage bound with a 500 bps default, and the directional bound (BUY above trigger, SELL below). It stops short of covering failure modes, permission/margin requirements, or whether the resting conditional can be modified.

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

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

Three dense sentences, front-loaded with the tool's identity and the most error-prone rule (closing side), then execution mechanics. The nested parentheticals make it slightly heavy to parse, but no sentence is 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 6-parameter mutation tool with no output schema and no annotation detail beyond safety flags, the description covers the trigger, execution, and slippage model thoroughly enough to invoke correctly. Gaps remain around size units, clientId semantics, and the market symbol format.

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

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

Schema description coverage is only 17% (slippageBps alone), so the description must compensate, and it does for the most semantically loaded parameters: side (closing side semantics), triggerPrice (trigger point), and slippageBps (execution bound, default 500, raise for thin books). market, size, and clientId remain undefined in both places, leaving units and client-order-ID behavior ambiguous.

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

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

States a specific verb and resource (place a reduce-only Take profit conditional order) and immediately scopes it with 'triggers at triggerPrice', which cleanly separates it from place_stop_loss, place_limit_order, and open_position in the sibling list.

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

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

The description gives a strong correctness rule for one parameter ('Side must be the CLOSING side of the position: SELL closes a LONG, BUY closes a SHORT'), which implies this is a position-exit tool, but it never says when to prefer this over place_stop_loss, close_position, or close_all_positions, and states no exclusions or prerequisites.

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

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

Beyond the annotations, the description discloses the exact source, destination, amount, threshold, and safety boundary. This gives a clear picture of the tool's behavior without requiring the agent to infer side effects.

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

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

Three short sentences cover the action, the amount, the constraint, and the recommended context for use. Every sentence contributes concrete information, and the key behavior is front-loaded.

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

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

Given no parameters, sparse annotations, and no output schema, the description still explains when to call, what it does, where funds move, how much, and what it cannot do. Nothing necessary for correct invocation is missing.

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

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

This tool has zero parameters, so parameter semantics are largely not applicable. The description helps by making the action fully deterministic and removing any need for a caller to supply additional 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 uses a specific verb phrase — 'Move a little USDC from the trading subaccount back to the WALLET' — and clearly identifies the condition and exact reserve amount. It also differentiates itself from siblings like deposit_to_subaccount by making the transfer direction explicit.

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

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

It provides a precise trigger ('when the wallet is at or below $0.55') and an explicit use case ('Use after a transaction fails for lack of gas'). The restriction that it cannot send funds anywhere else makes the limits of use unambiguous.

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

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

The description substantially discloses behavioral traits beyond the readOnlyHint annotation: it lists exactly what will be reported (both address forms, subaccount, permissions) and explicitly states what it 'CANNOT' do, such as withdraw, create wallets, reveal keys/mnemonics, or switch accounts. This helps an agent understand the tool as safe and non-mutating. It aligns with the readOnlyHint, so there is no contradiction.

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

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

The description is dense but well-organized: front-loaded with the action ('Report what this session controls'), then detailed specific outputs, then explicit can't-do list, then a terse 'Call this first' usage tip. Every sentence carries useful information, including the clarifying parenthetical 'the same 20 bytes.'

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

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

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

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

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

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

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

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

The description clearly identifies the tool's purpose with a specific verb and resource: 'Report what this session controls.' It enumerates the exact contents (master account in both cosmos/EV M forms, subaccount, trade/read-only status, auth scope, permissions). This distinguishes it from all siblings by establishing it as session introspection, not market data or trading.

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

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

The description gives explicit usage context: 'Call this first, and use it to answer what is my address?.' This tells an agent when to invoke it, though it does not explicitly discuss exclusions or alternatives. Since there are no sibling tools that obviously duplicate this introspection role, concise context is sufficient.

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