CoinRithm Agent Trading

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

The description adds 'releases frozen funds' and details about paper trading and execution costs, providing context beyond annotations. No contradiction with annotations (destructiveHint=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 verbose, including tangential details about paper execution policies and costs that could be omitted or moved elsewhere. The essential information is present but not 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 the output schema and annotations, the description covers cancellation scope and funds release. However, it lacks details on error behavior (e.g., if order already canceled) and is not fully complete for an agent.

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 mentions 'by id' but does not add semantic meaning beyond the schema's description of orderId and agentTrace.

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', using a specific verb and resource, and distinguishes from siblings like place_spot_order and open_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?

It mentions 'Requires the trade:spot scope' as a prerequisite and 'Paper trading only', providing clear context for when to use. However, it does not explicitly mention alternatives or when not to use.

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

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

Annotations mark destructiveHint as true, and the description reinforces that the tool closes or reduces positions. It adds extensive detail about execution cost, taker fees, and that it's a rehearsal cost, providing transparency beyond annotations.

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

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

The description is relatively long and includes detailed execution model information that may be extraneous for an AI agent. The core purpose is front-loaded, but the text could be more concise.

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

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

Given the tool has 4 parameters (2 required), nested objects, and an output schema, the description provides sufficient context: paper trading, required scope, idempotency, and execution costs. It covers all essential aspects for correct usage.

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

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

The input schema covers all parameters with clear descriptions. The description adds context by explaining the fraction parameter and the requirement for idempotencyKey, slightly enhancing meaning 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 'Close or partially reduce a mock futures position' which is a specific verb+resource. It distinguishes itself from siblings like open_futures_position and set_futures_sl_tp by focusing on closing/reducing.

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

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

The description specifies that idempotencyKey is REQUIRED and notes paper trading only. However, it does not explicitly tell when to use this tool versus alternatives like open_futures_position or set_futures_sl_tp, 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, open-world, non-destructive. Description adds significant detail about return fields, decisionEligible meaning, execution cost policy, and fee structure. 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 front-loaded with main purpose. While lengthy, each sentence adds value (return fields, dependencies, fees). Could be slightly more concise but effectively structured for a complex 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?

Given 6 optional parameters and an output schema, the description provides comprehensive context: what it does, what it returns, usage order, fee structure, and paper trading policies. Very complete.

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

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

Schema coverage is 100% with each parameter having a description. The tool description does not add extra meaning beyond the schema for the parameters, 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 finds active-open prediction markets from Kalshi and Polymarket, with specific return fields. It distinguishes from siblings like pm_quote and open_pm_position by noting this is discovery only.

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

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

Explicit guidance: use this for discovery, then call pm_quote before open_pm_position. Also mentions paper trading context, though no explicit when-not-to-use, the dependency chain is clear.

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

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

The description extensively discloses behavior beyond annotations: export limit, private availability, paper trading nature, virtual funds, execution cost details (taker fees, slippage, policy version). All align with readOnlyHint and destructiveHint. 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 longer than necessary, including detailed execution model explanations and disclaimers. While well-structured (purpose first, then filters, then caveats), some sentences are verbose and could be trimmed for brevity without losing essential 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 8 parameters and nested objects, the description covers key aspects: row limit, privacy, paper trading context, and filter usage. Output schema exists, so return format is handled. It lacks mention of pagination for high-volume exports but is otherwise complete for selection and 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 100% with descriptions, so baseline is 3. The description adds value by highlighting runId and decisionId filters for reproducible evaluation, giving them context beyond the schema. It does not cover all 8 parameters but the schema already handles them.

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 title and description clearly state the tool exports private agent ledger rows as JSON, with a limit of 1,000 rows. It specifies the data scope (calling API key's private ledger) and distinguishes it from siblings like get_agent_ledger (which likely returns the ledger for viewing).

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 filters (runId, decisionId) for reproducible evaluation and clarifies data privacy. However, it does not compare with sibling tools such as get_agent_ledger or export_run_evidence to guide selection. The guidance is clear but not exhaustive.

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 reveals behavioral traits: the bundle includes sanitized ledger rows, execution assumptions, and fee details. It clarifies that data is private and paper trading only, and adds context on execution costs and policy, which annotations do not cover.

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, then elaborates on contents and constraints. It is slightly verbose with financial details (fees, policy) but each sentence adds value. Could be more concise without losing essential context.

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 (nested object, output schema present), the description covers the tool's purpose, contents, limitations (paper trading, private), and execution model. It is comprehensive enough for an agent to decide usage without additional explanation.

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

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

Schema description coverage is 100%, so the baseline is 3. The description mentions 'for a specific agentTrace.runId' but does not add new meaning beyond the schema's parameter descriptions. No examples or syntax details are provided.

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

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

The description clearly states the action: 'Export one private reproducibility bundle for a specific agentTrace.runId.' It specifies the resource (runId) and distinguishes from siblings like export_agent_ledger by focusing on reproducibility bundle and paper trading restrictions.

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 context on when to use (paper trading, private data) but does not explicitly contrast with export_agent_ledger or other export tools. It implies usage via constraints like 'Paper trading only' and 'No public Arena user can see this data.'

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, openWorldHint=true, destructiveHint=false. The description aligns fully and adds significant context: explains paper execution policy, cost model (taker fees, slippage), and that the result is a 'rehearsal cost, not an exchange fill guarantee.' This goes well beyond annotations, providing deep behavioral insight without contradiction.

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

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

The description is efficient (6 sentences) and front-loaded with purpose. It covers essential points but includes a dense paragraph on execution policy that could be streamlined. Overall, it is appropriately sized for the tool's complexity, with minimal 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's complexity (5 params, nested objects, output schema present), the description covers purpose, usage constraints, behavior, and execution policy. It does not explain the output schema or provide explicit relationship to sibling quote tools, but it is sufficiently complete for an AI to select and invoke 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?

Input schema has 5 parameters with 100% description coverage. The description adds only marginal value beyond the schema, such as reiterating leverage range and margin minimum, but does not provide new meaning or usage details for individual parameters beyond what is already 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 explicitly states 'Read-only futures quote: entry price, notional, size, liquidation price, and eligibility.' It uses a specific verb ('quote') and resource ('futures'), and distinguishes from siblings like spot_quote and pm_quote by emphasizing its read-only nature and timing ('always quote before opening').

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: 'always quote before opening' and constraints on leverage (1-20) and margin (>=10). It also states 'Paper trading only — virtual funds (50,000 mUSD).' However, it does not explicitly exclude alternatives or compare to sibling quote tools, such as when to use spot_quote or pm_quote 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?

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds substantial behavioral details: explains it returns only calling key's rows, describes paper execution policy, fee structure, and states it's not an exchange guarantee. 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 front-loaded with the core purpose and then adds necessary details about fees and policies. It is somewhat lengthy but efficient for the complexity, earning its sentences 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 an output schema and 10 parameters, the description covers key aspects: data types, key scope, paper trading context. It lacks some operational details like pagination defaults (covered in params) but is sufficient for an audit 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% with all 10 parameters documented. The description provides high-level context (e.g., agentTrace metadata) but does not add specific parameter semantics beyond the schema. 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 'List this API key's private execution ledger' and enumerates specific data types (reads, quotes, writes, etc.). It distinguishes from siblings by highlighting key-scoped access and paper trading only, differentiating from tools like get_my_trades or export_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 explicitly says 'Use this to audit a reproducible paper-trading run' and 'Paper trading only', providing clear context. It does not explicitly state when not to use or list alternatives, but the paper trading and key-scoped nature implies 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?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description supplements this by detailing paper trading constraints, execution policy, and cost structure, adding significant behavioral context beyond the annotations.

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

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

The description is front-loaded with the essential purpose, but the lengthy explanation of paper execution costs (several sentences) could be condensed. It is informative but somewhat verbose for a tool description.

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 detail return values. It adequately covers scope (public, paper), data fields, and execution model, leaving no major gaps for agent decision-making.

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 100% of the single parameter with a basic description. The tool description adds value by connecting the handle to the leaderboard and providing an example, clarifying where to obtain valid 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 identifies the tool's purpose: retrieving a single agent's public Arena profile by handle. It lists specific data returned (rank, PnL, trade counts, win rate) and distinguishes it from the sibling get_arena_leaderboard by referencing the 'handle' field from that 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 states 'Public data only — no account or key identity' and 'Paper trading only — virtual funds', clarifying appropriate contexts. It does not explicitly name alternatives but implies when not to use it (real trading, private data).

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

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

Annotations already provide readOnlyHint=true and destructiveHint=false, but the description adds extensive behavioral context: it's public data, paper trading with virtual funds, execution cost details, minDecidedTrades gate, window scoping, and demo/house agent seeding. This goes well beyond annotations and is transparent about 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 informative but quite verbose, covering execution costs and paper mechanics. While the first sentence delivers the core purpose, the length may overwhelm some agents. It could be more structured, but 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?

Given the complexity (3 parameters, output schema exists), the description is very complete. It covers scope, window implications, min trades gate, execution details, and what the output contains (sparkline, badges, etc.). The presence of an output schema reduces the need to describe return values, yet the description still provides a good overview.

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 significant meaning beyond the schema. For example, it explains the window parameter in detail: 'Pass window='7d'|'30d' for the weekly/monthly board — re-ranked by PnL realized inside the window'. It also clarifies defaults and pagination behavior for page and pageSize.

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 resource ('public Agent Arena leaderboard') and the action (get it), with specific scope: 'opted-in agents ranked by total realized PnL (mUSD) across spot, futures, and prediction markets'. It also distinguishes from sibling tools by recommending pairing with get_performance and get_arena_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?

The description states when to use ('Use it to see the field and where you stand') and mentions alternatives (get_performance, get_arena_agent). It also includes context about paper trading and that it's not financial advice. However, it does not explicitly state when NOT to use this tool or provide a clear decision tree.

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, so the agent knows it's safe. The description adds that it is paper trading only with virtual funds and details execution costs, which provides extra behavioral context beyond the annotations.

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

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

The description is front-loaded with purpose and prerequisite, but then includes extensive execution cost details that may be extraneous for a read-only data tool. It is verbose but structured logically.

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, 1 required, output schema exists), the description covers purpose, prerequisites, parameter details, and behavioral context. The execution cost disclosure is complete but perhaps overly detailed.

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 significant value by explaining the range parameter with exact candle counts and reminding to use resolve_symbol for coinId. This goes beyond the schema descriptions.

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

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

The description clearly states it returns OHLCV candles for indicator/momentum strategies, specifying the resource and format. It distinguishes from siblings by focusing on candle data for technical analysis, with no other sibling tool serving this exact purpose.

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

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

The description explicitly instructs to use resolve_symbol first to get coinId, which is a clear prerequisite. It also explains the range parameter mapping. However, it does not provide explicit when-not-to-use guidance or alternatives beyond the implicit use case for strategies.

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, openWorldHint=true, destructiveHint=false. The description adds significant behavioral context: explains the paper trading simulation, execution costs, taker fees, rehearsal cost, and that it's not financial advice. This goes well beyond annotations to disclose data quality 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 then provides necessary detail about granularity and execution model. While somewhat lengthy, every sentence adds value. It is well-structured but could be slightly more concise.

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

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

Given the tool has 3 parameters, an output schema (indicated), and is a read-only data retrieval, the description fully covers what the tool does, its parameters, output format (date and usdValue for daily, cumulative for realized), and important context (paper trading, execution costs). 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?

Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining the behavior of 'granularity' (daily returns one point per day, realized returns intraday points per event with cumulative total) and 'days' look-back window range and default. This enriches the parameter understanding, justifying a 4.

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 resource ('Wallet equity time series for the paper account') and verb ('Get'). It distinguishes from siblings by specifying it's for performance review over time and narrating results, distinct from get_portfolio or get_positions which are current state.

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: for reviewing performance over time and narrating results. It distinguishes between daily (standard) and realized (active intraday agents) granularities. It also states 'Paper trading only' and mentions the look-back window. While no explicit 'when not to use' or alternatives are listed, the context and granularity descriptions provide clear usage 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 adds significant behavioral context beyond the annotations (readOnlyHint=true): paper trading only, virtual funds, not financial advice, and detailed execution cost policies for different order types. This helps the agent understand the simulation nature, though annotations already indicate non-destructive read.

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 data list, then covers prerequisites, paper trading, and execution costs. It is somewhat long but each part adds value, especially for behavioral transparency. Could be trimmed slightly without losing key info.

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 the input requirements, output components, prerequisites, paper trading context, and fee disclosure comprehensively. No obvious gaps for a context-gathering 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 the schema already describes both parameters (coinId and agentTrace). The description adds the prerequisite to use resolve_symbol for coinId and explains output content (e.g., prediction markets), but doesn't add new parameter-specific 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 it provides 'Compact factual context for ONE coin to form a thesis' and lists specific data points (price, changes, market cap, etc.), distinguishing it from siblings like get_candles or resolve_symbol. It explicitly instructs to call resolve_symbol first, reinforcing its unique role.

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

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

It explicitly says to call resolve_symbol first and notes that it provides facts only, for thesis formation. It does not explicitly list when not to use it, but the context of paper trading and the list of siblings imply its specific use case. Could be improved by mentioning alternatives like get_candles for historical data.

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 extensively details behavioral traits beyond annotations: paper trading with virtual funds, execution cost modeling, fee structures, and the polling mechanism via 'asOf'. Annotations (readOnlyHint, openWorldHint, destructiveHint) are consistent and supplemented with rich 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?

The description is well-structured, front-loading the core purpose and usage. While verbose, each sentence provides essential context for an AI agent (paper trading details, execution model). Minor redundancy in execution fee breakdown.

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 (4 params, output schema, many siblings), the description covers all necessary aspects: purpose, usage, behavior, parameter semantics, and special considerations (paper trading, polling). It is self-contained and complementary to the schema and annotations.

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 4 parameters fully. The description adds value by explaining the cursor pattern for 'updatedSince' and the context of 'agentTrace' (trace metadata). This goes beyond the schema descriptions.

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

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

The description clearly defines the tool as a unified realized-PnL log of closed trades across venues, acting as the agent's memory. It distinguishes from siblings like 'get_positions' (open positions) and 'get_performance' (aggregated metrics).

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 to use it for reviewing performance before deciding the next move and explains the polling pattern with 'updatedSince'. While it doesn't list explicit when-not-to-use scenarios, the context is clear and covers the primary use case.

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

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

Annotations declare readOnlyHint=true, openWorldHint=true, destructiveHint=false. The description adds significant context beyond annotations, detailing that it uses virtual funds, applies a specific execution policy (paper_execution_v1), and describes execution costs. This enriches the agent's understanding of the tool's 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?

The description is concise but packed with necessary details. It is front-loaded with the core purpose and then elaborates on constraints and execution model. The 'Not financial advice' sentence is slightly redundant but minor.

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

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

Given the complexity of the tool (realized PnL, trade counts, win metrics, execution policy), the description covers all relevant aspects: output fields, limitations (closed trades, paper only), and execution model. The presence of an output schema makes this complete.

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

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

Schema coverage is 100% with one optional parameter (agentTrace) well-described in the schema. The description does not add additional meaning beyond what the schema provides; it only reiterates the return structure. Baseline 3 is appropriate given 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 calling key's own realized performance: total + per-venue realized PnL...', providing a specific verb (get) and resource (own realized performance). It distinguishes from siblings by focusing on the agent's own realized PnL and trade statistics, which sets it apart from tools like get_portfolio or get_my_trades.

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

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

The description implies usage for the agent's own performance and specifies conditions: 'Paper trading only' and 'Closed trades only'. However, it does not explicitly compare with alternative tools or state when not to use it, leaving some room for 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 declare readOnlyHint=true and destructiveHint=false. The description goes far beyond these by detailing the paper execution model, fee structure, slippage, and the fact that fills are rehearsals, not guarantees. This extensive disclosure of behavioral traits provides high transparency without contradicting 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 long (multiple sentences) and includes extensive detail about execution models and fees. While the first sentence front-loads the main purpose, the subsequent detail could be streamlined or moved to an output schema. The wordiness reduces conciseness, though 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?

Despite its length, the description is complete: it explains what the tool returns, the paper-only nature, and the behavioral quirks of fills. An output schema exists (not shown), which reduces the need to document return values, but the description already does so. The only minor gap is a lack of guidance on usage versus 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?

Schema coverage is 100%, and all three parameters (fiat, locale, agentTrace) are described in the schema. The description does not add new semantic meaning to the parameters; it focuses on the output and behavior. With full schema coverage, a 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 it returns a 'lean, PII-free paper account summary' and enumerates the specific components (walletId, equity, PnL, orders, progression). This is a specific verb ('Get') and resource, and implicitly distinguishes from sibling 'get' tools like get_wallet or get_performance by focusing on the paper trading summary.

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 'Paper trading only' and 'Not financial advice,' providing some context on when to use. However, it does not explicitly state when not to use this tool or suggest alternatives. For a tool that is one of many 'get' tools, more explicit guidance on choosing between get_portfolio and get_wallet or get_performance would improve the score.

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

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

The description adds significant behavioral context beyond the annotations (readOnlyHint, openWorldHint, destructiveHint). It details mock data, virtual funds, execution costs, fees, slippage, and the rehearsal cost nature. This provides a comprehensive understanding of the tool's behavior 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 main purpose and well-structured. It is somewhat lengthy but each sentence adds necessary detail. A slight reduction could improve conciseness, but overall it 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?

Given the tool's complexity (3 parameters, nested objects, output schema exists), the description covers all necessary context: what positions are returned, how to poll for changes, paper trading nature, and execution model. It is complete without relying solely on the 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?

With 100% schema coverage, the schema already documents parameters well. The description adds value by explaining the purpose of 'updatedSince' for polling, venue-specific position contents (unrealized PnL, liquidation distance, mark), and the optional nature of agentTrace. This goes 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 tool lists open and historical positions for a venue, distinguishing between futures and pm with specific mock data details. It is a specific verb+resource action that differentiates from sibling tools like 'close_futures_position' or 'open_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 the tool (to list positions), provides context for polling with the 'asOf' and 'updatedSince' parameters, and clarifies it's for paper trading only. However, it does not explicitly state when not to use it or mention alternative tools among the siblings.

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

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

Annotations already indicate readOnlyHint=true, and the description adds extensive behavioral details: the wallet is paper-only, virtual funds, execution cost model, and that fills are rehearsals. No contradictions with annotations; the description enhances transparency beyond structured fields.

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

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

The description is lengthy (about 10 sentences) and includes excessive detail on execution costs, which may be tangential. While well-structured front-loading core purpose, it is not concise and could be trimmed for clarity.

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

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

Given the two optional parameters, high schema coverage, and presence of output schema, the description provides sufficient context: purpose, wallet structure, paper trading environment. It is complete for correct tool usage, though slightly over-informative.

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 descriptions for both coinId and agentTrace. The description does not add new meaning beyond the schema; it reiterates the optional coin filter but without extra depth. 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 verb 'Get' and the resource 'raw cash balances' with specific details about USDT and frozen partitions. It also distinguishes from sibling tools like get_portfolio by focusing solely on cash and frozen funds, not positions or trades.

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 notes that this is for paper trading only with virtual funds, providing clear context. However, it does not mention when not to use this tool or provide explicit alternatives among siblings, though the purpose is specific enough to guide correct selection.

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, and the description adds significant context: paper trading only, virtual funds, execution cost disclosure under paper_execution_v1 policy. It also explains delta polling with asOf. 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 the core purpose in the first sentence. It then explains parameters and polling before detailing paper trading policies. While a bit verbose on execution costs, each sentence adds useful context for an 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 (4 parameters, output schema present), the description covers all necessary aspects: purpose, parameter usage, polling, paper trading context, and execution model. It is self-contained and supports correct 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?

Schema coverage is 100%, so parameters are already documented. The description adds value by explaining the default behavior for coinId (omit for all) and the polling mechanism for updatedSince. This goes beyond the schema's basic 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 it lists open spot orders, specifies the verb 'list', and provides distinction by mentioning omission of coinId for all orders. It differentiates from siblings like cancel_spot_order or place_spot_order by focusing on read-only listing.

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

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

Provides clear guidance on when to use the tool (to list open orders) and how to use parameters like coinId for filtering and updatedSince for delta polling. However, it does not explicitly contrast with related tools like get_my_trades or spot_quote, leaving some inference 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?

Extensive disclosure beyond annotations: scope, server-flag gating, idempotency, leverage/margin constraints, side-aware SL/TP corridors, paper trading nature, virtual funds, execution costs, and contract model. 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?

Description is lengthier than average but every sentence adds value and critical details. Structure is logical: action, scope, constraints, best practices, execution model. Slightly verbose but not wasteful.

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, output schema present, paper trading simulation), the description fully covers purpose, constraints, execution model, and agent guidance. No gaps for 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?

Schema covers all parameters (100% coverage), but description adds valuable context like the side-aware corridor logic for stopLossPrice/takeProfitPrice and the requirement for idempotencyKey uniqueness.

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

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

Description clearly states it opens or adds to a mock futures position, specifying the verb and resource. It distinguishes itself from sibling tools like close_futures_position and futures_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?

Provides clear context: when to use (open futures), requirement to quote and confirm, and idempotency key usage. While it doesn't list alternative tools, it gives actionable guidance for correct invocation.

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?

Description goes beyond annotations by detailing server-flag gating (403 if disabled), paper trading nature, execution costs (taker fees, slippage), and the use of idempotencyKey for replay. This provides rich behavioral context beyond the basic annotations (readOnlyHint=false, idempotentHint=true, destructiveHint=false).

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

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

The description is reasonably concise given the complexity, with critical information front-loaded (binary outcomes, scope, idempotency, min stake). Each sentence adds value, though it could be slightly tightened without losing clarity.

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

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

Given the tool's complexity (9 parameters, 5 required, nested objects), the description covers gating, scoping, constraints, paper trading specifics, cost details, and idempotency behavior. An output schema exists, so return values need not be explained. The description is complete and thoroughly sets expectations.

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 comprehensive parameter descriptions. The description adds overall context (e.g., side behavior, idempotencyKey requirement) but does not significantly enhance individual parameter meanings beyond what the schema already provides. 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 'Open a mock prediction-market position (binary outcomes only)', which is a specific verb+resource. It distinguishes itself from sibling tools like pm_quote (quoting) and spot/futures orders by focusing on binary PM positions.

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

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

The description provides explicit usage guidance: requires trade:pm scope, idempotencyKey required, stake>=10, side defaults to yes, and instructs to quote first and confirm with the user. It also notes paper trading only. However, it does not explicitly state when NOT to use or list alternative tools for other order types like spot or futures.

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

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

Annotations indicate a write operation (readOnlyHint=false) but no destructiveness. The description adds extensive behavioral details: idempotency via key, required scope (trade:spot), paper execution costs, and execution policy version. 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 comprehensive but verbose (multiple sentences on execution cost details). The first sentence is concise and front-loaded, but the overall length could be reduced by half without losing essential guidance.

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 purpose, parameter nuances, idempotency, scope, paper-only nature, and execution model. Given 8 parameters, nested objects, and output schema existence, the description is thorough and leaves no major gaps for an AI agent to select or invoke 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 coverage is 100%, but the description adds critical context: coinId is UCID not ticker, limitPrice required for limit/stop, stopPrice only for stop, idempotencyKey semantics (replay original result). This goes well beyond the schema descriptions.

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

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

The title and description clearly state the tool places a paper spot order. It distinguishes from siblings like spot_quote (quoting) and cancel_spot_order (cancellation) by specifying it is for executing orders. The description also clarifies that coinId is a UCID, not a ticker, reinforcing purpose.

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

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

The description provides explicit usage guidance: requires user confirmation, paper trading only, and idempotency key behavior. It lacks explicit alternatives (e.g., use open_futures_position for futures), but the tool name and sibling set imply context. The coverage is strong but not perfect.

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 substantial context beyond annotations: free/public, no API key, computation details (24h before resolution, >=24h history), and pending status for low sample. Fully consistent with readOnlyHint and openWorldHint.

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 paragraph but front-loaded with key purpose. Every sentence adds value, though could be slightly more structured. Overall appropriately sized 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?

With output schema present, description covers all necessary context: what metrics are returned, pending condition, and usage. No gaps given the simple parameterless interface.

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, and schema coverage is 100%. Baseline is 4 per rubric. Description adds no parameter info, but none needed.

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

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

The description clearly states it provides a per-venue forecast-accuracy scorecard with specific metrics (calibrationError, sampleSize, etc.), and distinguishes from siblings by focusing on calibration rather than other data like overview or events.

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 recommends using this tool to answer 'which venue forecasts best' with evidence, and notes that low-sample venues appear in pending. This gives clear when-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?

Annotations declare readOnlyHint=true, openWorldHint=true, destructiveHint=false. The description adds critical behavioral details: orientation is never price-inferred, merged canonicals still resolve with a mergedInto pointer, lineage is append-only with newest first. No contradictions.

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

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

The description is a single paragraph but is well-structured with clear mode explanations. It is concise given the complexity, though it could be slightly more organized with bullet points. No wasted sentences.

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 (dual mode, merge handling, stable identity), the description covers all essential aspects: listing vs. detail, orientation caveat, merged resolution, lineage format. Output schema exists, so return values need not be described.

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%. The description adds meaning beyond schema: explains that key can be UUID or slug, that limit and cursor apply only in list mode, and that cursor uses previous pagination.nextCursor. It clarifies the behavior of each parameter 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?

The description clearly states the tool provides a 'stable cross-venue identity for one real-world question', distinguishing it from venue-specific tools like pm_data_event. It uses specific verbs and resources: 'page the directory', 'resolve', 'track one question across venues'.

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 two modes (omit key to list, pass key for full record) and explicitly states when to use: 'Use this to track one question across venues by a durable identity instead of re-matching venue slugs yourself.' It provides clear usage context but lacks explicit 'when not to use' statements.

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 crucial behavioral context: it is free public, no API key required, the orientation is human/aggregator-reviewed (never price-inferred), and it includes quality checks like requirePriced. 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 starts with the core purpose, then details parameters and methodology, and ends with disclaimers. Every sentence adds value, though it could be slightly more concise for a quick scan. Still, it is well-organized and 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 the tool's complexity (9 parameters) and the presence of an output schema, the description is remarkably complete. It explains the output structure (e.g., deltaPoints, matchedOutcomeCount), the methodology behind delta calculations, and the quality floor. The agent has a thorough understanding to use this tool effectively.

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, baseline is 3, but the description adds significant value by explaining parameters in context, such as sort options with their meanings (e.g., 'max_outcome_delta_desc avoids multi-leg basket noise'), and detailed explanation of requirePriced. This goes beyond the schema's descriptions, earning a 4.

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 defines the tool as providing 'cross-venue disagreement clusters' for prediction markets, explaining that it shows events matched as the same question across venues. It distinguishes itself from a sibling tool (pm_quote) by stating that pm_quote is for tradability of one specific outcome, which helps the agent select the correct 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 explicitly tells the agent when to use pm_quote instead (for tradability of one outcome) and advises caution on requirePriced (research/debug only). However, it does not cover when to use other sibling tools like pm_data_calibration or pm_data_event, limiting the differentiation.

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 and openWorldHint; the description adds that no API key is required and explains how to interpret key output fields (crossSourceMatches, referenceProbability). This adds value beyond annotations, though it does not mention potential 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?

The description is long but well-structured, front-loading the main purpose and key fields, then providing usage advice. Every sentence adds value, though it could be slightly more concise without losing information.

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

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

Given the complexity, schema coverage, existence of output schema, and sibling tools, the description thoroughly covers what the tool returns, how to use it, and how it relates to other tools (pm_quote, pm_data_*), making it complete for an AI agent.

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 context for the detail parameter (default vs full) and implies the source and slug are identifiers. It goes beyond schema by explaining when to use different parameter values, earning 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 clearly states the tool provides free public details for one prediction-market event by venue and slug, listing specific return fields (outcomes, probabilities, etc.) and distinguishing it from pm_quote for tradability.

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 tells when to use this tool ('cross-venue research view') and when to use alternatives ('for tradability use pm_quote'), along with guidance on using the detail parameter ('Set detail=full only when the untouched provider-rich record is needed').

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; description adds that it is free public search with no API key required, and details the return fields including referenceProbability, quality, and crossPlatform. Also notes that blocked markets remain visible but cannot drive paper opens or alerts, which is useful behavioral context beyond annotations.

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

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

Description is well-structured: opens with core purpose, contrasts with sibling, lists return values, explains special fields, and closes with usage guidance. It is somewhat verbose but each sentence adds value. Minor redundancy could be trimmed, but overall efficient for 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?

Given the tool's complexity (7 optional parameters, output schema exists, many siblings), the description is highly complete: it covers scope, return structure, differentiation from siblings, and usage constraints. It explains specialized fields like referenceProbability and quality without needing to detail the output schema, which is already provided.

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 baseline is 3. The description does not elaborate on individual parameters beyond what the schema provides; it focuses on overall behavior. No additional parameter meaning is added, so score remains at baseline.

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

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

Description clearly states the tool performs a free public search over prediction-market events across all 12 venues, explicitly contrasting with the sibling discover_pm_markets which is scoped to paper-tradeable venues. The verb 'search' and resource 'prediction-market events' are specific, and the scope is clearly defined.

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

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

Provides explicit guidance: use for research/data only; to trade, use discover_pm_markets and pm_quote instead. Also mentions pm_data_event for all outcomes and full evidence, distinguishing between tools in the pm_data_* family.

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 and openWorldHint. The description adds significant behavioral context: no API key required, source-aware freshness with a health endpoint, volume reporting methodology, monetary totals covering only real-money venues, and a citation requirement for the self-computed aggregates. 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?

The description is front-loaded with the main purpose and provides all necessary details in a logical order. While slightly lengthy, every sentence adds value, covering scope, alternatives, freshness, methodology, and access requirements.

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 role as an aggregated overview, the description comprehensively explains what data is included, how it's computed, freshness characteristics, and limitations. It also directs to a health endpoint and methodology URL, which is complete for understanding the tool's capabilities and constraints.

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 with a description for the single optional 'fiat' parameter. The description mentions 'fiat currency code' and implies default 'usd' but does not add substantial new semantics beyond the schema. 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 'Free public cross-venue prediction-market statistics' and lists specific aggregated metrics (total/open/closed market counts, volume, liquidity). It distinguishes itself from the sibling tool pm_data_event by directing users there for full event evidence, making the purpose unambiguous and differentiated.

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 recommends using pm_data_event for full event evidence, providing an alternative. It also gives context on freshness and methodology, but does not exhaustively list when not to use this tool versus other siblings.

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, indicating a safe read operation. The description adds valuable context: it is free, public, and requires no API key. It also explains the data's purpose and comparability. 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 extremely concise: two sentences that front-load the primary function and follow with usage guidance. Every word adds value, and it avoids redundancy with the schema or 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 presence of an output schema, the description need not explain return values. It provides a complete picture: what data is returned, when to use it (before comparisons), and constraints (free, no key). The sibling tools are numerous, but this description sufficiently distinguishes its role.

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 a single parameter 'fiat' with a description in the schema itself, achieving 100% coverage. The tool description does not add new information about this parameter, so it meets the baseline of 3. It does not detract but does not enhance 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 providing free public methodology and comparable coverage for each prediction-market venue, listing specific data elements (source kind, metrics, volume bases, etc.). It distinguishes itself from sibling tools by focusing on comparability and methodology, addressing the need before comparing venue totals.

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 when to use the tool: 'Use this before comparing venue totals so a completed-day figure is never described as rolling 24h and play-money points are never described as USD.' It also mentions no API key required, implying ease of use. However, it does not explicitly exclude other scenarios or name alternative tools, which would elevate the score.

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 that no API key is required and specifies output fields. 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?

Two sentences, front-loaded with key details and usage guidance. 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?

Covers output content, usage context, and authentication; no parameters to explain. Fully adequate for its purpose.

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 in schema, so description does not need to add param info. Baseline 3 for high coverage, but no missing info; slight bonus for clarity on what the output includes.

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

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

Clearly states the tool returns per-venue ingest health metrics (freshness tier, lag, etc.) across all CoinRithm sources, distinguishing it from sibling tools like pm_data_sources.

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 checking this before using a quote or claiming cross-venue coverage, and warns that a venue in the catalogue does not guarantee live freshness.

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 valuable behavioral context: no API key required, data captured since a specific date, rolling 90-day window, and crucial detail that gaps are null not zero. This goes beyond annotations.

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

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

The description is moderately long but well-structured with key details front-loaded. It could be slightly more concise (e.g., 'bounded to a rolling ~90-day window' is clear but verbose), but overall it is efficient and informative.

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 zero parameters, readOnly and destructive hints, and an output schema, the description is complete. It explains venue inclusion/exclusion, date range, gap handling, and purpose. No additional context is needed.

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 (0 params, 100% schema coverage). The description does not need to add parameter information. It is well-complemented by the schema, earning a baseline of 4.

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 global daily prediction-market volume trend, specifying one point per UTC day, and distinguishes between real-money and play-money venues. This provides a specific verb+resource with clear 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 states the use case: 'see whether cross-venue prediction-market activity is growing or shrinking over time.' It also explains what is excluded (play-money venues) and how gaps are handled. However, it does not directly contrast with siblings or state when not to use this tool.

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

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

Annotations already signal readOnlyHint and non-destructive. The description adds valuable context: free public tape, newest-first ordering, specific fields, and venue attribution differences (Polymarket wallet-attributed, Kalshi anonymized). This goes beyond annotations.

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

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

Three sentences pack all necessary information without redundancy. Front-loaded with purpose, followed by details and disclaimers. Every sentence adds value.

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

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

Output schema exists, and description enumerates all returned fields. With annotations covering safety and schemas covering parameters, this description is complete for a simple data retrieval tool.

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

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

Schema coverage is 100% for the single parameter 'limit', with a clear description in schema. The tool description adds no additional parameter details, 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?

Description uses specific verb 'Get latest' and resource 'prediction-market whale trades'. It clearly defines the scope ('large trades, $1k+ notional') and distinguishes from sibling tools like pm_data_calibration or pm_data_canonical by focusing on recent whale activity.

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 'No API key required' and 'information, not a recommendation', implying low barrier and advisory nature. However, it does not explicitly state when to use this tool versus alternatives like pm_data_overview or 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?

Annotations declare readOnlyHint true and destructiveHint false; description adds detail on paper trading, simulated execution costs, and that no state is mutated. This provides useful clarity 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?

Description front-loads purpose but is lengthy and includes some extraneous detail on paper execution policy. Still well-structured and informative.

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 output schema exists, description covers all necessary aspects: read-only, parameters, paper trading, behavioral notes on openBlocked, and execution cost model. An agent can correctly invoke the 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%, but description adds meaning: stakeMusd must be >0 and min 10, side details, outcomeExternalMarketId case-sensitive. AgentTrace description duplicates schema but offers context.

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

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

The description clearly states it is a read-only quote for binary outcomes, listing key return fields. It distinguishes from sibling quote tools like spot_quote and futures_quote by specifying prediction market context and read-only nature.

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

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

Provides guidance on side parameter (no side for NO, omitted for YES), stakeMusd minimum (10), and explains openBlocked as a preview of rejection. Lacks explicit when-not-to-use or alternatives, but context implies use before opening a position.

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 claims 'needs only the read scope, never moves funds', contradicting the annotation readOnlyHint=false. Additionally, it includes lengthy irrelevant details about paper execution costs that confuse the tool's actual 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?

The description is overly verbose, including irrelevant sections about paper trading and execution costs that do not pertain to reporting a non-opened opportunity. It could be significantly shortened without losing essential 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?

The description covers the self-reporting nature and idempotency but is marred by irrelevant execution details. Given the presence of an output schema, return values do not need explanation, but the tool's context is partially clear.

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 with descriptions. The description adds value beyond the schema by explaining the purpose of each 'kind', idempotency via 'decisionId', and the 'cohort' context, enhancing agent 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 it reports prediction-market opportunities evaluated but not opened, distinguishing it from sibling tools that handle trades or other data. The purpose is specific and actionable.

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

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

The description explains when to use the tool (for non-opened opportunities) and enumerates the three kinds with conditions. It implicitly excludes opened trades, but lacks explicit alternatives or 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?

Annotations already declare readOnlyHint and non-destructive, but the description adds rich behavioral context: paper execution policy, fees (taker, spread, slippage), calibration details, and the rehearsal nature of results, far exceeding what annotations alone provide.

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

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

The description is front-loaded with the core purpose, but includes a lengthy list of execution details that, while valuable, could be streamlined or moved to a separate documentation section. Still, each sentence adds necessary context for correct usage.

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 (output schema exists, parameters well-documented), the description covers purpose, usage, behavioral nuances, and execution semantics comprehensively, leaving no critical gaps for correct 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?

Both parameters ('q' and 'agentTrace') are fully described in the input schema (100% coverage). The description adds no additional semantics beyond restating the 'q' parameter's purpose, so 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 it resolves human-readable symbols/slugs/names to CoinRithm coinIds plus alternatives, using a specific verb 'Resolve' and resource 'symbol', distinguishing it from sibling tools that require coinIds.

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 obtain the coinId needed by wallet/quote/order tools, warns against guessing UCIDs, and mentions paper trading constraints, providing 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: triggers fired by per-minute worker, liquidation precedence, full position closure on fire, fill discovery via my_trades, execution costs, and that the executionModel is a rehearsal cost not a guarantee. Annotations already indicate idempotency and non-destructive, and description aligns perfectly.

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 operation, then provides necessary details in a structured manner. While it is lengthy, every sentence adds essential information about behavior, constraints, and execution. It could be slightly trimmed, but it earns its length.

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 (side-awareness, paper trading, execution model), the description covers almost all aspects: scope, constraints, fill discovery, cost implications, and that output is a rehearsal. It assumes some background knowledge (e.g., mark), but is complete for the tool's purpose.

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 description coverage, the baseline is 3. The description adds valuable context beyond the schema: side-aware ordering for SL/TP, the meaning of null/omitted values, and the requirement that positionId refers to an open position. This enriches the agent's 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 starts with a specific verb and resource: 'Set or clear resting stop-loss / take-profit triggers on an OPEN mock futures position.' It clearly distinguishes from siblings like close_futures_position and open_futures_position by focusing on SL/TP adjustment on an already open position.

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

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

The description explains the side-aware ordering (long needs liq < SL < mark < TP, short inverted) and the effect of null/omitted fields. It also states the required scope ('trade:futures') and that it's for paper trading only. However, it does not explicitly state when not to use this tool, though sibling context implies 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?

Matches annotations (readOnlyHint=true) and adds details: 'Never mutates state', paper trading specifics, execution cost policy, and that price age is informational. 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?

First sentence provides clear core purpose. Subsequent sentences add necessary context but are dense. Could be slightly more concise, but structure is logical and 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?

Covers read-only nature, return value fields, paper trading context, UCID clarification, and ordering guidance. Output schema exists, so return format is not required. Complete for the tool's complexity.

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

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

With 100% schema coverage, baseline is 3. Description adds crucial info for coinId ('UCID, not a ticker — use resolve_symbol first') and clarifies side semantics beyond the enum. Other params are adequately described 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?

Description clearly states 'Read-only spot MARKET quote' and lists specific outputs (execution price, cost, balance, eligibility). Distinguishes from siblings like futures_quote and pm_quote by specifying 'spot' and 'market'.

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 'quote before place_spot_order instead of buying/selling blind' and to resolve symbols before using coinId. Does not directly compare to siblings but implies when to use by naming the tool it precedes.

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, so the description should add behavioral context beyond that. Instead, it devotes most of its length to irrelevant paper trading execution details (fees, slippage, etc.), which have nothing to do with a whoami call. This extraneous info could mislead an AI agent into thinking the tool involves trading.

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 verbose and includes a long, irrelevant paragraph on paper trading execution costs. It fails to be concise; much of the content does not belong in a tool description and should be removed. Front-loading the core purpose is good, but the excessive length is detrimental.

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 does explain the return fields (userId, keyId, scopes, agentName, agentModel) and notes that agentName/agentModel are null until set. However, it includes unnecessary details about paper trading that are not relevant to this tool's operation, creating noise. With an output schema present, the description need not detail return values, but the irrelevant context reduces completeness.

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 'agentTrace' parameter, whose description is already provided in the schema. The tool description adds no additional parameter guidance, which meets the baseline expectation.

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 'Return the identity behind the configured API key' with specific fields (userId, keyId, granted scopes, agentName, agentModel), and the tool name 'whoami' is standard for identity. It is distinct from all sibling 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 explicitly says 'Use this first to confirm what the key is allowed to do', providing a clear primary usage context. However, it does not mention when not to use it or alternatives, but given there are no similar identity tools, this is acceptable.

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