CoinRithm Agent Trading

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

Annotations indicate destructiveHint=true, but the description adds substantial behavioral context: releases frozen funds, paper trading execution costs, and that results are a rehearsal cost not an exchange guarantee. This fully informs the agent of consequences.

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

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

The description is front-loaded with the main action, but includes a lengthy paragraph on execution costs that could be more concise. While every sentence adds value, the length reduces 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?

Given the output schema exists, the description covers purpose, scope, and behavioral traits well. However, it omits details about error scenarios (e.g., cancelling a non-existent order) and rate limits, leaving minor gaps.

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

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

Schema coverage is 100% and describes both parameters (orderId with type and constraints, agentTrace with sub-properties). The description does not add additional meaning beyond the schema, 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 clearly states 'Cancel an open spot order by id (releases frozen funds).' It specifies the verb (cancel), resource (spot order), and the effect (releases funds), which distinguishes it from sibling tools like place_spot_order or list_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?

The description includes scope requirements ('Requires the trade:spot scope') and context ('Paper trading only — virtual funds... Not financial advice.'). It implicitly guides usage by describing the paper trading environment, but does not explicitly contrast with alternatives.

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

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

Beyond annotations indicating destructive and idempotent behavior, the description details execution costs, fee structures, and paper trading specifics, providing rich behavioral context that aids correct invocation.

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

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

The description is front-loaded with the core action but becomes lengthy with detailed execution cost explanations. While informative, some detail could be omitted or moved to a usage note.

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

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

Given the tool's complexity (partial closes, fees, paper trading), the description covers purpose, parameters, behavioral details, and required scope. Missing explicit error handling or return value description, but output schema may compensate.

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 100% schema coverage, the description adds clarity on fraction semantics (explicit range) and emphasizes the idempotencyKey requirement, going beyond the schema's parameter descriptions.

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

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

The description clearly states the tool's verb (close/reduce) and resource (mock futures position), distinguishes partial vs full close, and implicitly differentiates from sibling tools like open_futures_position or set_futures_sl_tp.

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 mentions required parameters (idempotencyKey), required scope (trade:futures), and the paper trading context. However, it does not explicitly state when not to use this tool or provide alternative tool names for similar actions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds substantial context about what the tool returns (source, slug, outcomeExternalMarketIds, freshness, volume/liquidity/spread, decisionSupport) and the paper trading execution model (fees, slippage). This goes beyond the annotations, though some execution details are more relevant to other tools. No contradiction with annotations.

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

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

The description is well-structured, starting with the main purpose, then listing return fields, workflow guidance, and paper trading details. It is somewhat long but each sentence adds value. The front-loading of the core function is effective. Minor conciseness improvements could be made by moving execution cost details to trade-related tools.

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

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

Given the complexity (6 parameters, enums, nested objects, output schema), the description is complete. It explains the tool's role in the workflow, return fields, and the paper trading context. The output schema exists, so detailed return value descriptions are not required. The description covers all necessary aspects for an agent to use the tool correctly.

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

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

Schema description coverage is 100%, so each parameter has a description. The tool description does not add significant details beyond the schema for individual parameters, but it provides overall context for how the tool is used. Baseline of 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Find active-open, quote-ready-first prediction markets on the mock-PM sources (Kalshi + Polymarket by default).' It specifies the verb 'Find', the resource 'prediction markets', and includes key qualifiers like 'active-open' and 'quote-ready-first'. It distinguishes from sibling tools by explicitly stating it is for discovery only and directing the agent to call pm_quote next.

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

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

The description provides explicit workflow guidance: 'This is discovery only — call pm_quote with one returned outcomeExternalMarketId before open_pm_position because pm_quote is the final eligibility source.' It also clarifies that it is for paper trading with virtual funds and not financial advice, setting clear expectations for when and how to use the tool.

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

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

The description discloses many behavioral traits beyond annotations: maximum 1,000 rows, privacy, paper trading context, virtual funds, execution cost details (taker fees, slippage, rehearsal cost). No contradiction with annotations (readOnlyHint=true).

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 and front-loaded with the key purpose. Every sentence adds value, but it is relatively long. Minor deduction for verbosity.

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

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

Given 8 parameters, no required params, 100% schema coverage, and an output schema, the description covers purpose, constraints, behavioral details, and output format (JSON). It is complete for a data export tool.

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

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

Schema coverage is 100%, so baseline is 3. The description adds a high-level suggestion to filter by runId or decisionId but does not provide additional parameter meaning beyond the schema's descriptions.

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

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

The description clearly states the verb (export), resource (private ledger rows), scope (up to 1,000), format (JSON), and caller restriction (calling API key). It differentiates from siblings like get_agent_ledger and export_run_evidence by specifying 'private' and 'for the calling API key'.

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 tells when to use filters ('for reproducible evaluation') and warns that data is private and for paper trading only. However, it does not explicitly state when not to use this tool or compare it to alternatives like get_agent_ledger.

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

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

Annotations declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true. The description adds substantial behavioral context beyond annotations, such as the contents of the bundle, privacy constraints, paper trading details, and execution cost mechanics. No contradiction with annotations.

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

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

The description is relatively long but efficiently structured. The first sentence captures the core purpose, subsequent sentences provide necessary behavioral details (fees, constraints). While verbose, every sentence adds value given the tool's complexity.

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

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

The description covers the tool's purpose, contents, constraints (paper trading, virtual funds, privacy), and execution cost model. With output schema present, return value details are not needed. The description is complete for the tool's scope.

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

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

Schema coverage is 100% with clear parameter descriptions. The tool description does not add significant meaning beyond the schema; it references 'agentTrace.runId' but that is already documented. Baseline score of 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Export one private reproducibility bundle for a specific agentTrace.runId.' It specifies the verb 'export', the resource 'private reproducibility bundle', and the binding to 'runId'. This distinguishes it from sibling tools like 'export_agent_ledger' and 'get_agent_ledger'.

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 does not provide explicit guidance on when to use this tool versus alternatives. It mentions 'No public Arena user can see this data' and 'Paper trading only', but these are disclaimers rather than usage recommendations. No comparison with sibling tools is made.

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

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

Annotations indicate readOnlyHint=true and destructiveHint=false. The description goes beyond by detailing paper trading, virtual funds, execution costs, fee structures, and the fact that it never mutates state. No contradiction with annotations.

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

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

The description is somewhat lengthy but well-structured with front-loaded purpose. Each sentence adds value, though the execution cost explanation could be more concise. Still effective.

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 presence of an output schema, the description does not need to explain return values. It covers all necessary context: constraints, paper trading environment, fee behavior, and safety (non-mutating). Complete for a quote tool.

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

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

All 5 parameters have schema descriptions covering 100% of the input. The description does not add significant per-parameter meaning beyond what is already in the schema, meeting the baseline for high coverage.

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

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

The description clearly states the tool is a read-only futures quote providing entry price, notional, size, liquidation price, and eligibility. It uses specific verbs and resources, and distinguishes itself from siblings like open_futures_position and close_futures_position.

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

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

The description explicitly says 'always quote before opening,' indicating when to use. It also provides constraints (leverage 1-20, marginMusd >= 10) and clarifies paper trading environment. It does not explicitly list alternative tools but the context is clear.

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

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

Annotations (readOnlyHint=true, destructiveHint=false) already indicate safe read-only behavior. The description adds valuable context: only rows for the calling key are returned, paper trading nature, execution cost details (taker fees, slippage, etc.), and that fills are not guarantees. This goes well beyond the annotations.

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

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

While front-loaded with the core purpose, the description becomes verbose when detailing execution costs and paper trading rules. Some of this detail could be shortened or moved to a separate section, but it is still logically structured.

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

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

Given the tool's complexity (10 parameters, nested objects, output schema), the description covers purpose, usage, behavioral nuances, and parameter context well. It lacks only a brief mention of what the output schema contains, but the presence of an output schema mitigates this need.

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

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

Schema coverage is 100% with clear descriptions for all 10 parameters. The tool description does not add additional semantic value to the parameters beyond what the schema already provides, which meets the baseline for high coverage.

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

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

The description clearly states 'List this API key's private execution ledger' and enumerates the types of data included (reads, quotes, writes, etc.). It distinguishes this tool from siblings by specifying it is private to the calling key and for paper trading only, making its purpose unambiguous.

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

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

The description explicitly says 'Use this to audit a reproducible paper-trading run. Paper trading only — virtual funds (50,000 mUSD).' It also includes caveats about costs and that it's not financial advice. It does not explicitly mention when not to use it or list alternatives, but the context is strong enough for an AI to infer appropriate usage.

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

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

Beyond annotations (readOnlyHint=true, destructiveHint=false), the description adds context about paper trading, virtual funds, execution costs, and that it's not financial advice. No contradictions.

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

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

The description is detailed but well-structured, covering purpose, data, and caveats in a logical flow. Could be slightly more concise, but every sentence provides useful information.

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

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

Given the presence of an output schema, the description adequately covers all necessary context: data returned, public nature, paper trading, execution costs, and limitations. Complete for a read-only profile 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 100% schema coverage, the description adds value by explaining that handle comes from get_arena_leaderboard and providing an example, clarifying its origin beyond the schema.

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

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

The description clearly identifies the tool as retrieving one agent's public Arena profile by handle, specifying the data included (rank, PnL, trade counts, win rate). It distinguishes from get_arena_leaderboard by focusing on a single agent.

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

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

States that it returns public data only and is for paper trading, setting clear expectations. Does not explicitly mention when to use alternatives, but the sibling tools list includes get_arena_leaderboard for handles.

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 read-only, open-world, non-destructive behavior. The description adds substantial context: paper trading, virtual funds, execution cost modeling, per-venue breakdown, min decided trades gate, sparkline, badges, and more. No contradictions with annotations.

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

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

The description is quite verbose and covers many details. It is structured with main purpose first, but the length could be trimmed. However, every sentence serves a purpose, so it earns a neutral score.

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

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

Given the tool's complexity and the presence of an output schema, the description is fully complete. It explains what the tool does, how to use it, its limitations (paper trading, min trades), and details about the data returned. No gaps remain.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the window parameter's effect on re-ranking and scoping of other fields. It also clarifies the default values for page and pageSize. This exceeds baseline.

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

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

The description clearly identifies the tool as retrieving the Agent Arena leaderboard ranked by realized PnL with per-venue breakdowns and win rate. It distinguishes itself from sibling tools like get_performance and get_arena_agent by explaining their complementary roles.

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

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

The description states when to use the tool ('see the field and where you stand') and explains the window parameter for weekly/monthly boards. It pairs with other tools but lacks explicit when-not guidance. Score reduced slightly for missing exclusion criteria.

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 behavioral details: candles are oldest to newest, timestamps in seconds, price in fiat, volume in USD, and range mapping. However, the long explanation of paper trading execution costs is irrelevant and potentially misleading for a read-only data tool.

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 lengthy and includes a large paragraph on paper trading execution costs that is irrelevant to getting candles. This bloats the description and reduces readability. The essential information is front-loaded, but the unnecessary details detract from conciseness.

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

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

Given the complexity (4 params, output schema exists), the description covers parameter mapping, data format, and prerequisites. The paper trading context is noted. However, the irrelevant execution cost explanation adds noise but does not critically undermine completeness. An output schema exists, so return values need not be explained.

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

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

Schema has 100% coverage, but the description adds significant value beyond schema: it provides detailed mapping of range values (1H=60x1-minute, etc.), clarifies that fiat defaults to USD, and explains that coinId must come from resolve_symbol. This greatly helps the agent select correct parameter values.

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

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

The description clearly states it provides OHLCV candles for indicator/momentum strategies, with a prerequisite (resolve_symbol). It is specific about the resource and verb, though it does not explicitly differentiate from sibling tools, but among the list, no other tool seems to provide candle 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 mentions a prerequisite (resolve_symbol first) and notes it is for paper trading only, but does not provide explicit guidance on when to use this tool vs alternatives, nor any exclusions.

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

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

Beyond the annotations (readOnlyHint, openWorldHint), the description discloses important behavioral details: fee model, paper trading nature, execution cost, and non-financial advice. This adds significant value for correct agent invocation.

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 structured and informative, but slightly verbose with detailed fee explanations that might be auxiliary. It is front-loaded with purpose but could be trimmed for conciseness.

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

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

Given the tool's complexity (3 parameters, nested object, output schema exists), the description covers usage scenarios, constraints (paper only, fee model), and behavioral nuances, making it complete for an agent to use correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description enhances parameter meaning by explaining the 'realized' granularity's cumulative behavior and the purpose of 'days', adding context beyond the schema.

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

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

The description clearly states the tool returns a wallet equity time series for the paper account, distinguishing it from siblings like get_performance. However, it does not explicitly compare or differentiate from similar tools, missing a chance to further aid agent selection.

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

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

The description provides explicit guidance on when to use each granularity (daily vs. realized) and mentions the paper-only context, but it does not discuss when to avoid this tool or suggest alternatives, leaving some ambiguity.

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

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

Annotations already indicate read-only and non-destructive behavior. The description adds context about paper trading (virtual funds, execution costs) and states facts-only output. There is no contradiction. It goes beyond annotations by explaining the simulated nature, though some details about execution costs are tangential for a data retrieval tool.

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

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

The description is front-loaded with the main purpose but becomes verbose with paper trading details that could be separate. Although clear, it could be trimmed by moving the execution cost notes to tool-level 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?

Given the complexity and output schema availability, the description covers most aspects of the returned data (prediction markets with specific fields, similar coins). However, it mentions 'executionModel in quote/trade results' which may be confusing since this tool does not trade, and it does not describe error handling.

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

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

Input schema covers both parameters (coinId and agentTrace) with descriptions. Schema coverage is 100%, so the description adds minimal extra meaning beyond repeating the resolve_symbol advice. No additional parameter details are provided in the description.

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

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

The description explicitly states it provides 'compact factual context for ONE coin' listing specific data points (price, changes, market cap, category tags, sentiment, Fear & Greed, prediction markets, similar coins). It clearly distinguishes from sibling tools like resolve_symbol (which only gets coinId) and trading 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 advises 'Call resolve_symbol first to get the coinId' as a prerequisite and notes 'Facts only — no generated thesis' to clarify when it is appropriate. It does not explicitly name alternatives, but the context implies it is for pre-trade research, not for execution. The paper trading disclaimer sets expectations.

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

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

The description fully aligns with annotations (readOnlyHint, openWorldHint, destructiveHint) and adds valuable behavioral context beyond them: it explains paper trading with virtual funds, execution cost model (taker fees, slippage, etc.), and the nature of executionModel as a rehearsal cost. No contradictions with annotations.

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

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

The description is relatively long but well-structured: it opens with the core purpose, then explains usage and polling, then adds paper trading caveats. Every sentence provides necessary context (disclaimers, execution model). It could be slightly more concise but front-loads the most critical information effectively.

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 presence of an output schema (not shown but indicated), the description appropriately focuses on input behavior and caveats. It covers polling mechanism, venue filtering, execution cost details, and fee structures. For a trade history log, this is comprehensive: it tells the agent exactly what to expect and how to leverage the tool for performance review.

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

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

Schema coverage is 100% with good descriptions for each parameter. The description enhances the updatedSince parameter by explaining its practical use (polling with asOf), and confirms that venue filtering is supported. It adds value beyond the schema by clarifying the cursor pattern, but the schema already handles most semantic information.

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 unified realized-PnL log of closed trades across venues, sorted most-recent first. It distinguishes itself from sibling tools like get_positions (open positions) and list_open_orders (open orders), and uses specific language like 'unified', 'realized-PnL', and 'closed trades' that precisely define its scope.

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

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

The description explicitly advises using this tool 'to review performance before deciding the next move', and provides clear guidance on the updatedSince parameter for efficient polling (pass asOf back from previous response). It does not explicitly mention when not to use it or compare to specific alternatives, but the context implies it's for closed trades review.

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

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

Beyond annotations (readOnlyHint, openWorldHint, destructiveHint false), the description adds significant behavioral details: paper trading with virtual funds, execution cost model, and that win rate is null until decided trades. This exceeds what annotations provide, ensuring the agent understands the context and limitations.

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

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

The description is front-loaded with the core purpose and key results, then expands on execution details. While slightly verbose, each sentence adds essential context, and the structure is logical.

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 presence of an output schema and no required parameters, the description covers all necessary aspects: tool purpose, return metrics, scope (closed/paper), and execution nuances. It is fully sufficient for an agent to invoke correctly.

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

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

The only parameter (agentTrace) has full schema coverage (100%), so the description does not need to add parameter-level details. The description adds no additional semantics beyond the schema, meeting the baseline for high coverage without exceeding it.

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

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

The description clearly states the tool returns the calling key's own realized performance for closed trades, including specific metrics like PnL, trade count, win/loss counts, and win rate. It distinguishes itself from sibling tools by specifying 'closed trades only' and 'paper trading only', making its purpose unambiguous.

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

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

The description provides clear context on when to use the tool (for the agent's own realized performance on closed paper trades). It implicitly excludes alternatives (e.g., open trades, live trading) but does not explicitly name sibling tools or state when not to use it.

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

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

The description goes well beyond annotations (readOnlyHint=true, destructiveHint=false) by detailing the paper trading simulation, execution cost model, fee structure, and that fills are rehearsed. This provides critical behavioral transparency for an agent to understand the tool's limitations and nuances.

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

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

The description is front-loaded with the core purpose and key fields, then adds necessary behavioral details. It is slightly long but every sentence adds unique value (e.g., execution model disclosure). Could be trimmed slightly, but effective.

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

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

Given the tool's complexity (simulated paper trading with execution modeling), the description covers all necessary context: what is returned, that it's paper only, and the execution cost details. Output schema exists, so no need to explain return format. Complete for an agent to use correctly.

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

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

Schema coverage is 100%, and the description does not add meaning to the parameters (fiat, locale, agentTrace) beyond what the schema already provides. For high schema coverage, baseline is 3; the description adds no extra parameter insight.

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

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

The description uses specific verb 'Get' and clearly identifies the resource: 'lean, PII-free paper account summary' with enumerated fields (walletId, equity, PnL, orders, progression). It distinguishes from siblings like get_wallet or get_performance by specifying 'paper trading only' and detailing unique contents.

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

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

The description states the tool is for paper trading only and returns a summary, providing implicit usage context. However, it does not explicitly state when not to use it or compare to alternative tools among the siblings (e.g., get_wallet for real accounts). The 'Not financial advice' is a disclaimer but not a guideline.

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 read-only, non-destructive. Description adds crucial behavioral details: mock positions, fee structures, execution model, and polling behavior. 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?

Description is detailed but every sentence adds value; front-loaded with main purpose. Slightly lengthy but justified by the complexity of the tool's behavior.

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

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

Covers purpose, venue differences, polling, paper trading constraints, fee disclosure, and execution model. Output schema is present, so return values are not required. Complete for a multi-venue position list tool.

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

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

Schema coverage is 100%. Description enriches each parameter: venue explains return differences, agentTrace documents private trace metadata, updatedSince explains polling cursor usage.

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

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

Description clearly states the tool lists open and historical positions for a venue, with venue-specific explanations for 'futures' and 'pm'. It distinguishes from sibling tools that handle orders, trades, or positions modification.

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

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

Provides clear context for usage: paper trading, virtual funds, polling mechanism with 'updatedSince'. Does not explicitly contrast with alternatives but the listing vs. action distinction is 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 already mark it as read-only and non-destructive. The description adds valuable context about the execution cost model for paper fills, which affects the reported balances. This goes beyond the annotations to disclose how the data is computed.

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 somewhat verbose, especially with details about execution costs that may be tangential to the core function. The first sentence is concise and clear, but the later sentences add length without being essential for tool invocation.

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

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

The description covers the tool's purpose, its restrictions (paper trading), and the components of the balance. Although an output schema exists, the description still provides useful context about what the balance includes. It is fairly complete for a simple 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?

The input schema already provides descriptions for both parameters (coinId and agentTrace) with 100% coverage. The description does not add significant additional meaning to the parameters beyond what the schema offers. Baseline score of 3 is appropriate.

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

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

The description specifies exactly what the tool does: 'Get raw cash balances: USDT available plus the three frozen partitions...' and mentions the optional coin asset. It clearly differentiates from sibling tools like get_portfolio or get_performance by focusing on raw cash balances and paper 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 explicitly states 'Paper trading only — virtual funds (50,000 mUSD). Not financial advice.' This provides clear context for when to use the tool. However, it does not explicitly state when not to use it or compare to alternative tools.

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

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

Annotations indicate read-only and non-destructive. Description adds essential context: paper trading only, virtual funds, execution costs, and fees. 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?

Clear front-loading of core purpose, but later details on execution costs are verbose and could be moved to a separate note. Still structured and readable.

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 output schema and annotations present, the description covers all necessary aspects: purpose, parameter usage, behavioral quirks, and delta polling. Complete for a 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?

All parameters are described in schema (100% coverage). Description adds clarity: omitting coinId returns all orders, and explains updatedSince polling pattern.

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 lists open spot orders, specifies filtering by coinId, and mentions delta polling with asOf. It distinguishes from sibling tools by focusing on listing resting 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 explains when to omit coinId (all orders) vs pass one to filter, and describes delta polling mechanism. However, does not compare with alternatives like get_positions or get_my_trades.

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 idempotent and non-destructive mutation. The description adds extensive details: server-flag gating, execution cost (taker fee, slippage, rehearsal cost), paper trading nature, and side-aware corridor for SL/TP. No contradiction with annotations.

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

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

The description is comprehensive but verbose, including lengthy execution cost details and disclaimers. While well-structured, it could be more concise without losing critical information.

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

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

Given the tool's complexity (8 params, nested objects, output schema), the description covers auth, idempotency, parameter constraints, side-aware behavior, paper trading details, and execution costs. Fully complete for an agent to use correctly.

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

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

Schema coverage is 100%, but the description adds meaningful context: side-aware corridor for SL/TP, idempotencyKey uniqueness, coinId requiring resolve_symbol, and agentTrace as optional metadata. Enhances schema understanding.

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

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

The description clearly states the verb 'Open (or add to)' and the resource 'mock futures position', distinguishing it from sibling tools like close_futures_position and set_futures_sl_tp.

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

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

The description specifies required auth (trade:futures scope), idempotency key usage, leverage/margin constraints, and advises to 'Quote first and CONFIRM with the user.' It does not explicitly list alternatives or when-not-to-use, but provides clear context.

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

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

Discloses scope requirements, server-flag gating, idempotency, minimum stake, side semantics, and detailed execution cost model (taker fees, slippage, etc.). No contradiction with annotations; adds substantial value beyond them.

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

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

Description is dense but well-organized, starting with core purpose then adding constraints and details. Every sentence adds value; slightly verbose but appropriate for the 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?

Given 7 parameters, nested objects, and output schema existence, the description covers all essential behavioral aspects: paper trading, execution costs, quoting prerequisite, and server gating. No gaps identified.

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

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

Schema covers all parameters, but description adds critical context: idempotencyKey requirement, stakeMusd minimum, and side interpretation (NO fills at 100 minus probability). Enhances understanding without redundancy.

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 specifies the exact action 'open a mock prediction-market position (binary outcomes only)'. It clearly differentiates from siblings like open_futures_position and place_spot_order by focusing on binary prediction markets and paper 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?

Explicitly instructs to 'Quote first and CONFIRM with the user', and notes 'Paper trading only — virtual funds (50,000 mUSD)'. Does not explicitly contrast with alternatives like pm_quote, but the guidance is clear and practical.

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

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

Provides extensive behavioral details beyond annotations: paper trading, execution costs, taker fees, slippage, and the execution model. Annotations only hint at non-idempotency, but description clarifies idempotency via key, adding critical 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-loaded with core purpose, then detailed explanations. Some redundancy (e.g., 'paper trading only' repeated) but well-organized. Could trim execution cost details without losing value.

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

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

Covers idempotency, authorization, user confirmation, paper trading constraints, and execution model. With output schema available, complete for safe agent 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?

Adds meaning beyond 100% schema coverage: clarifies coinId is UCID not ticker, conditions for limitPrice/stopPrice, and idempotencyKey required behavior. All parameters are explained in 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?

Description opens with 'Place a paper spot order,' clearly stating the action and resource. It distinguishes from siblings by specifying 'paper trading only' and virtual funds, differentiating it from real order tools or quotes.

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 requires 'trade:spot' scope and instructs to 'CONFIRM with the user before calling.' Idempotency key behavior is explained, but no direct comparison to alternatives like 'spot_quote' or 'cancel_spot_order' is given.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false; the description reinforces 'Never mutates state' and adds detailed behavioral traits: paper trading, execution costs, fee structures, and the nature of the quote as a rehearsal cost. This exceeds annotation coverage.

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 core purpose and key details, but includes lengthy execution cost explanations that could be condensed. Overall, it is well-structured and informative without unnecessary repetition.

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

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

Given the tool's complexity (6 params, nested objects, output schema), the description covers purpose, constraints, behavior, and paper trading nature. It references executionModel results, aligning with output schema. Minor gaps in usage guidance against siblings prevent a perfect score.

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

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

Schema coverage is 100% with detailed descriptions for each parameter. The description adds context for the side parameter (NO fills at 100 minus probability) and mentions stakeMusd constraint, but these are largely redundant with schema. It does not significantly enhance meaning beyond schema, 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 clearly states the tool provides a read-only quote for a binary outcome prediction market, listing key metrics like entry probability, share estimate, max payout, and decisionSupport for tradability. It uses a specific verb ('quote') and resource ('PM binary outcome'), distinguishing it from sibling tools like futures_quote or spot_quote.

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

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

The description explains constraints (stakeMusd > 0, min to open 10), side parameter behavior (NO fills at 100 minus probability), and paper trading context. However, it does not explicitly contrast with sibling tools like futures_quote or spot_quote, nor state when to prefer this over them, though the PM focus 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?

The description discloses paper trading nature, virtual funds, non-financial-advice disclaimer, and detailed execution cost model (taker fees, slippage, etc.). This adds significant context beyond the readOnlyHint and destructiveHint annotations, with no contradictions.

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

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

The description is front-loaded with core purpose and then provides necessary caveats. It is slightly lengthy due to execution cost details, but each sentence serves a purpose. Could be trimmed slightly without losing value.

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

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

Given the output schema and annotations, the description fully explains the need for resolution, what the output contains, and behavioral attributes like paper trading and execution costs. It is comprehensive for the tool's complexity.

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

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

Schema coverage is 100% with clear descriptions for both parameters. The description adds minor context (examples for 'q' and emphasis on using this first) but does not significantly enhance understanding beyond the schema.

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

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

The description explicitly states the tool resolves a human symbol/slug/name to a CoinRithm coinId and provides disambiguating alternatives with CoinGecko tags. It clearly distinguishes from sibling tools that deal with orders, positions, and other operations.

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

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

Explicitly instructs to use this tool first to get the coinId for wallet/quote/order tools, and warns against guessing UCIDs since symbols are not unique. This provides clear when-to-use and when-not-to-use 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?

The description discloses detailed behavioral traits beyond annotations: triggers are fired by a per-minute worker, liquidation takes precedence, fire closes full position at mark with realized PnL, execution costs, and paper trading specifics. No contradiction with annotations.

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

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

The description is front-loaded with the core purpose and includes essential details. While lengthy, every sentence adds value (e.g., side-aware condition, execution model, paper trading specifics). Could be slightly trimmed but remains effective.

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 complexity, annotations, and output schema existence, the description covers all necessary aspects: behavior, side-awareness, execution triggers, paper trading limitations, cost model, and reference to executionModel. No gaps.

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

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

The input schema has 100% description coverage. The description adds value by explaining side-aware behavior and reinforcing the meaning of values (positive sets, null clears, omit unchanged), which goes beyond the schema's property descriptions.

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

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

The description precisely states the tool's action: 'Set or clear resting stop-loss / take-profit triggers on an OPEN mock futures position.' It uses specific verbs and resource, and clearly distinguishes from sibling tools like close_futures_position.

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

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

The description explains when to use (setting or clearing SL/TP on open positions), what parameter values mean (positive number sets, null clears, omitted unchanged), and constraints (paper trading only, not financial advice). It does not explicitly state when not to use alternatives, but the context is clear.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds extensive behavioral context: never mutates state, paper trading only with virtual funds, execution cost details including fees and slippage, and that price age is informational. No contradiction with annotations.

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

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

The description is somewhat long but front-loaded with the main purpose. Every sentence adds value, though the detailed fee explanation could be slightly more concise. Overall, it is well-structured for an AI agent.

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

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

Given the tool's complexity and the presence of an output schema (not shown), the description covers input semantics, behavioral nuances, and paper trading specifics thoroughly. The agent has enough information to use the tool correctly without external 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 has 100% coverage, so baseline is 3. Description adds value by clarifying that coinId is a UCID (not a ticker) and should be resolved via resolve_symbol, which goes beyond schema. It also explains side and quantity semantics succinctly. However, it does not mention agentTrace, which is already well-documented in schema.

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

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

The description clearly states it is a 'Read-only spot MARKET quote' providing live execution price, estimated cost, available balance, and fill eligibility. It distinguishes from sibling tools like place_spot_order by stating 'quote before place_spot_order instead of buying/selling blind' and implies separation from futures_quote and pm_quote by specifying spot.

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 advises to use before placing a spot order, and notes that price age is informational only. It also clarifies paper trading context and that it is not financial advice. However, it does not explicitly state when not to use this tool versus alternatives like futures_quote or pm_quote, but the context is clear enough.

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

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

Adds context beyond annotations (e.g., agentName/agentModel null until set, paper trading environment). However, the lengthy discussion of execution costs and fees is out of place for a read-only identity tool, reducing clarity.

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

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

Description is excessively long (5+ sentences) with irrelevant details about paper trading fees and execution models. Could be trimmed to focus on identity information without losing value.

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

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

Covers what the tool returns and its paper trading context, but the inclusion of unrelated trading details makes it over-complete. Output schema exists, so return values are already documented; the description adds unnecessary complexity.

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

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

Schema coverage is 100% for the single optional parameter (agentTrace), so baseline is 3. The description adds no information about this parameter, but the schema already fully describes it.

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

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

The description clearly states it returns the identity behind the API key (userId, keyId, scopes, agentName, agentModel). This distinguishes it from other trading tools. However, it includes extraneous details about paper trading and fees, which dilute the core purpose.

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

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

Explicitly says 'Use this first to confirm what the key is allowed to do', providing clear context for when to use. No exclusions or alternatives needed given the tool's unique role.

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