CoinRithm Agent Trading

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

Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds beyond that: it clarifies the effect of releasing frozen funds, the required scope, and the paper trading limitation. No contradictions.

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

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

Two sentences cover purpose, effect, scope, and environment. Every sentence is essential. 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?

With one well-documented parameter, explicit schema coverage, and an output schema present, the description fully covers purpose, effect, scope, and environment. 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% with a clear description of orderId as 'Open order id.' The main description mentions 'by id' but adds no additional meaning 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 action ('Cancel'), the resource ('open spot order'), and the effect ('releases frozen funds'). It distinguishes from sibling tools like 'place_spot_order' and 'list_open_orders' by focusing on cancellation.

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

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

The description specifies the required scope ('trade:spot') and that it is paper trading only ('virtual funds'). This provides clear context for when to use the tool, though it does not explicitly state when not to use it or mention 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?

Discloses key behaviors beyond annotations: paper trading only, virtual funds, need for idempotencyKey, and scope requirement. 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?

Three sentences pack all essential info without waste. Front-loaded with main action, then details. Every sentence adds value.

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

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

Given the tool is for mock trading, has annotations, and schema descriptions cover parameters, the description fully covers context: idempotency, scope, virtual funds, and fraction behavior.

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% parameters. Description adds meaning by clarifying fraction range and optionality, and emphasizing idempotencyKey requirement, surpassing 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?

Description clearly states the tool closes or partially reduces a mock futures position. It specifies the resource and action, distinguishing it from sibling tools like 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?

Provides clear usage conditions: fraction in (0,1], idempotencyKey required, requires trade:futures scope, paper trading only. No explicit 'when not to use' but context is sufficient; alternatives are implicitly clear.

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

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

Annotations already provide readOnlyHint and destructiveHint. The description adds context about the mock sources, return fields, and that it is discovery only. It does not contradict 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 concise sentences covering purpose, returns, and usage guidance. No redundant information. Front-loaded with the core action.

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

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

Covers all needed aspects: what it does, what it returns, workflow hints, source defaults, and disclaimers. Output schema exists, so return values are documented elsewhere.

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 add extra semantics beyond what the schema already provides for each parameter. It correctly focuses on overall purpose.

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 ('Find'), the resource ('active-open, quote-ready-first prediction markets'), and the scope ('Kalshi + Polymarket by default'). It differentiates from siblings like pm_quote and open_pm_position by specifying that 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?

Explicitly tells the agent to call pm_quote after discovery before opening a position, and mentions that it is paper trading and not financial advice. No alternative siblings are needed; the workflow is clearly defined.

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

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

Annotations already mark readOnlyHint=true and destructiveHint=false. The description adds 'Never mutates state', 'Paper trading only', 'virtual funds (50,000 mUSD)', and 'Not financial advice', providing 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?

Two sentences, front-loaded with key information. Every sentence adds value: tool purpose, output fields, usage hints, and disclaimers. No wasted words.

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

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

Output schema exists, so description focuses on what it returns (entry price, notional, etc.) and key constraints. Covers usage context, safety, and paper trading environment. Missing details like error handling but overall adequate for the tool's simplicity.

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

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

Schema coverage is 100%, so baseline is 3. The description repeats schema constraints (leverage 1-20, marginMusd >= 10) but adds no new parameter semantics beyond what the schema provides.

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

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

The description clearly states 'Read-only futures quote' and lists specific outputs (entry price, notional, size, liquidation price, eligibility). It distinguishes from siblings like open_futures_position by emphasizing it is a non-mutating query 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 advises 'always quote before opening' and constraints (leverage 1-20, marginMusd >= 10). It implies usage context (before opening a futures position) but does not mention specific alternatives like spot_quote or pm_quote.

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, non-destructive, open-world. The description adds value by clarifying it's public data only, no identity needed, paper trading with virtual funds, and not financial advice – details not in annotations.

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

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

Two sentences, no wasted words. The first sentence immediately states purpose and key details; the second adds important limitations. Perfectly front-loaded and 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 is simple (one parameter, read-only, output schema exists), the description covers all necessary context: purpose, parameter usage, data scope, and caveats. 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 enhances the parameter by explaining its source (from get_arena_leaderboard) and providing an example handle, adding meaning beyond the schema description.

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

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

The description clearly states the tool retrieves one agent's public Arena profile by handle, listing specific data fields (rank, PnL, trade counts, win rate). It distinguishes itself from the sibling get_arena_leaderboard by focusing on a single agent.

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

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

The description implies when to use (for a single agent's profile) and provides context (public data, paper trading, not advice). However, it does not explicitly state when not to use or list alternatives beyond the leaderboard reference.

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

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

Annotations (readOnlyHint, openWorldHint, destructiveHint) already provide a safety profile. The description adds behavioral context: ranking requires minDecidedTrades, demo/house agents seed the board, data is public and paper trading, and it explicitly states 'Not financial advice.' No contradiction.

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

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

The description is informative but slightly lengthy. It front-loads the main purpose and uses concise sentences, though some details (e.g., demo/house agents) could be streamlined. Still, every sentence adds value.

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

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

Given the output schema exists (as per context signals), the description explains what the tool returns (leaderboard with per-venue breakdown, win rate) and covers edge cases (minDecidedTrades, demo/house agents). It is 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?

The input schema covers both parameters (page, pageSize) with descriptions, achieving 100% coverage. The description adds no additional parameter-specific meaning, 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 returns the public Agent Arena leaderboard ranked by PnL, with per-venue breakdown and win rate. It distinguishes from siblings like get_arena_agent and get_performance by specifying their different scopes (drill into one handle vs. own scorecard).

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

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

The description advises when to use it ('see the field and where you stand') and suggests pairing with other tools (get_performance, get_arena_agent). While it doesn't explicitly state when not to use it, the context (public data, paper trading only) implies limitations.

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

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

Annotations provide readOnlyHint, openWorldHint, destructiveHint. Description adds that it applies to paper account and virtual funds, and notes it's not financial advice. 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 with no filler. Front-loaded with the key purpose and data format. Every sentence adds value.

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

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

Given output schema exists (context: has output schema true), description explains return format and use case. Simple tool with one parameter—description covers all necessary context.

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

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

Schema description for 'days' parameter already provides range and default. Description reinforces this by reiterating the range and default, adding context about look-back window.

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 returns daily wallet equity time series with specific fields (date, usdValue). Distinguishes from sibling tools like get_performance or get_portfolio which are not time series of equity.

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

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

Explicitly says 'Paper trading only — virtual funds' and 'days = look-back window (1-365, default 30)', providing usage context. Does not explicitly state when not to use or list alternatives, but the purpose is clear.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false. The description adds important behavioral context: 'Facts only — no generated thesis' and 'Paper trading only — virtual funds (50,000 mUSD). Not financial advice.' This goes beyond the annotations.

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

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

The description is a single sentence that front-loads the core purpose and then lists included data. It is concise given the amount of information, though could be broken into multiple sentences for readability.

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

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

Given the tool's complexity (multiple data points) and the existence of an output schema, the description adequately covers the essential context: what data is returned, prerequisite (resolve_symbol), and caveats (paper trading, not financial advice). It is complete for an informed 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 description coverage is 100%, and the schema already describes the coinId parameter similarly. The description mentions the context is for 'ONE coin' and briefly hints at the output, but does not add significant semantic 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 explicitly states it provides 'compact factual context for ONE coin to form a thesis' and enumerates specific data points (price, changes, market cap, categories, sentiment, fear & greed, prediction markets, similar coins). This clearly distinguishes it from sibling tools like resolve_symbol (which resolves coin IDs) and other 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 instructs to 'call resolve_symbol first to get the coinId', providing a clear prerequisite. It also includes context about paper trading and disclaims financial advice, but does not explicitly state when not to use this tool or compare it to alternatives.

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

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

Annotations declare readOnlyHint=true and destructiveHint=false, already indicating safety. The description adds context: the tool returns a log of closed trades with realized PnL, most-recent first, and clarifies it is paper trading with virtual funds, not financial advice. This goes beyond annotations without contradiction.

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

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

The description is three well-structured sentences. The first sentence front-loads the core purpose and scope. The second gives usage guidance. The third adds essential caveats. No redundant words; every sentence adds value.

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

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

Given the tool has 2 optional parameters with full schema coverage and an output schema, the description adequately covers what the tool does, what it returns, ordering, and scope (paper trading). It provides sufficient context for an agent 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?

Schema coverage is 100%, so the description does not need to repeat parameter details. The description adds no extra meaning for 'limit' or 'venue' beyond what the schema provides; it only mentions the ordering of results (most-recent first), which is not parameter-related. 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 defines the tool as a 'Unified realized-PnL log of CLOSED trades across venues' with explicit resource ('my trades') and action (get). It distinguishes from sibling tools by focusing on closed trades and paper trading, which is distinct from open orders, positions, or live 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 states when to use it: 'Use it to review performance before deciding the next move.' It also notes 'Paper trading only' as a constraint. While it doesn't explicitly list alternatives, the context of sibling tools implies different use cases (e.g., list_open_orders for open orders).

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

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

The description adds value beyond annotations by specifying that performance is realized, per-venue, and that win rate can be null until trades are decided. It also notes paper trading and virtual funds, providing behavioral context consistent with readOnlyHint.

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

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

The description is three sentences, front-loaded with the main purpose, followed by constraints and disclaimer. Every sentence is informative and concise, with no wasted words.

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

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

Given no parameters and presence of output schema, the description sufficiently covers purpose, constraints (closed trades, paper trading), and disclaimer. It could mention authentication requirement, but the term 'calling key' implies it.

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 in the input schema, so schema coverage is 100%. The description adds no parameter information, which is acceptable since none exist; baseline 4 is appropriate.

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

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

The description clearly states that the tool returns the calling key's own realized performance including total and per-venue PnL, trade counts, and win rate. It distinguishes itself from sibling tools like get_equity_curve and get_portfolio by focusing on realized performance and scope (closed trades, paper trading).

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

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

The description indicates the tool is for the calling key's own performance, covering closed trades only and paper trading. It implies when to use (for agent's own scorecard) but does not explicitly state when not to use or alternatives, though the context is clear.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds critical context: paper trading environment, virtual funds, and that equity remains USD-denominated. This supplements the annotations well.

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

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

Two sentences, no redundancy. First sentence efficiently lists the returned data, second provides constraints and disclaimer. All content earns its place.

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

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

With an output schema present, return value explanation is unnecessary. The description covers purpose, constraints (paper-only), and behavioral details. For a simple read-only tool with two optional parameters, it is fully sufficient.

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 parameters with descriptions. The description adds minimal extra value by noting that equity stays USD-denominated regardless of fiat parameter, but this is a minor addition beyond what the schema provides.

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

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

The description clearly identifies the tool as retrieving the paper account dashboard, listing specific data including equity, PnL, balances, orders, and history. This distinguishes it from sibling tools like get_wallet, get_performance, get_positions, etc.

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 states 'Paper trading only — virtual funds', providing clear context for when to use. Includes 'Not financial advice' disclaimer. No direct mention of alternatives, but the sibling list implies availability of other tools for different contexts.

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, destructiveHint=false, and openWorldHint=true. The description adds critical context: it's paper trading with mock data, virtual funds (50,000 mUSD), and not financial advice. It also reveals per-venue return specifics, going 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, no wasted words. Front-loaded with the core purpose, then specifics. Each sentence adds value: purpose, venue-specific details, and important caveats.

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 (context signals), the description doesn't need to detail return values. It fully explains the tool's purpose, venue differentiation, mock nature, and constraints. Comprehensive for a low-complexity tool.

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

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

The schema has 100% coverage (single enum parameter with description). The description enhances this by explaining what each venue returns, adding meaning beyond the simple 'which venue' description.

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

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

The description specifies the exact function: listing open and historical positions for a venue. It distinguishes between two venue types (futures and pm) and details the data returned (unrealized PnL, liquidation distance, mark). This clarity differentiates it from sibling 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 clearly states that it lists positions for a venue and provides examples. It implicitly guides usage by specifying venue choices, but lacks explicit 'when not to use' or alternative suggestions. However, the paper trading caveat serves as important context.

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

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

Annotations readOnlyHint=true and destructiveHint=false declare safety. Description adds details about return structure (USDT, frozen partitions) and paper trading context. 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 cover purpose, return details, optional parameter, and usage context. No fluff, highly efficient.

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

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

Given an output schema exists, description covers all necessary aspects: what is returned, optional parameter, and environment constraint. Complete for a read-only wallet 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 has 100% coverage for the single optional parameter, and description adds an example (coinId '1' = BTC). This aids understanding beyond the schema's description.

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

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

Description clearly states the tool retrieves raw cash balances including USDT and frozen partitions, and optionally a coin asset. This distinguishes it from sibling tools like get_portfolio or get_equity_curve.

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 states 'Paper trading only — virtual funds (50,000 mUSD)', providing clear context for when to use. Does not mention alternatives or when not to use, but the environment constraint is sufficient.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds that this is a paper trading environment with virtual funds and a disclaimer, which provides useful behavioral context beyond what annotations convey.

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

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

Three concise sentences front-load the purpose and key constraints. Every sentence adds value: purpose, requirement, and environment/disclaimer. No unnecessary words.

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

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

Given the tool's simplicity, presence of annotations, full input schema, and output schema, the description covers all necessary context: what it does, the required parameter, and the paper trading environment. No gaps remain.

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

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

Schema coverage is 100% with detailed descriptions for both parameters (limit and coinId). The description only reiterates that coinId is required, adding no new semantic information 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 'List open (resting) spot orders for ONE coin', specifying the verb and resource, and distinguishes from sibling tools like cancel_spot_order or place_spot_order. It narrows scope to a single coin, avoiding ambiguity.

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

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

The description implies usage by stating 'coinId is required' and 'Paper trading only', but lacks explicit guidance on when to use this tool versus alternatives like get_my_trades or spot_quote. No exclusions or conditional logic are provided.

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

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

The description adds significant behavioral details beyond annotations: scope requirement, server-flag gating (403), idempotency requirement, isolated margin constraints, and paper trading with virtual funds. No contradiction with annotations.

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

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

The description is concise with five sentences, each serving a distinct purpose: purpose, scope, gating, idempotency, constraints, quoting advice, and disclaimer. No wasted words.

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

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

Given the tool's complexity, the description covers purpose, prerequisites, constraints, behavioral notes, cross-tool dependencies (resolve_symbol), and disclaimer. Output schema is present, so return values need not be 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%, so baseline is 3. The description adds value by emphasizing idempotencyKey uniqueness, leverage/margin constraints, and the tip about quoting first, which is above baseline but not fully exhaustive on all parameters.

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

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

The description clearly states the tool opens or adds to a mock futures position. It distinguishes itself from sibling tools like close_futures_position, futures_quote, and open_pm_position by emphasizing paper trading and the need to quote first.

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 quote first and confirm with the user, specifying a prerequisite. It also notes the required scope (trade:futures), the paper trading limitation, and that it's not financial advice, giving 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?

The description discloses that the tool is for paper trading only with virtual funds (50,000 mUSD), that it is server-flag gated (may return 403), and that it is not financial advice. This adds valuable behavioral context beyond the annotations, which already indicate idempotency and non-destructive nature. No contradiction.

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

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

The description is concise with 5 front-loaded sentences. Each sentence serves a purpose, though the structure could be slightly more organized (e.g., grouping constraints). Overall 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 has 5 required parameters, a complete schema, and annotations, the description fully covers critical aspects: mock nature, minimum stake, idempotency, server gating, and user confirmation. It is comprehensive for a non-destructive write operation with an 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?

The schema has 100% description coverage, setting a baseline of 3. The description reinforces that idempotencyKey is required and stakeMusd >= 10, but adds little new meaning beyond what the schema provides.

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

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

The description clearly states 'Open a mock prediction-market position (binary outcomes only).' It uses a specific verb ('Open') and resource ('prediction-market position'), and is distinct from sibling tools like 'open_futures_position' and 'pm_quote'.

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

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

The description instructs the user to 'Quote first and CONFIRM with the user' and specifies requirements like idempotencyKey and minimum stake. While it implies a workflow (use pm_quote first), it does not explicitly state when not to use this tool or list specific 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?

Adds critical behavioral details beyond annotations: user confirmation required, virtual funds, and disclaimer. No contradiction with annotations (readOnlyHint=false etc.).

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 three succinct sentences with essential info, front-loaded with purpose. Every sentence adds value with no redundancy.

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

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

Given 6 parameters, 2 enums, and presence of output schema, the description covers all critical context: paper trading, scope, confirmation, parameter nuances. No gaps remain.

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

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

Adds meaning beyond schema: clarifies coinId is UCID not ticker, orderType options, and price requirements per order type. Schema covers 100% param descriptions, but description enhances clarity.

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

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

The description clearly states 'Place a paper spot order,' specifying the action and resource. It distinguishes from sibling tools like 'spot_quote' and 'cancel_spot_order' by focusing on order placement and emphasizing paper trading.

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

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

The description provides explicit usage context: paper trading, required scope ('trade:spot'), and user confirmation. It lacks explicit 'when not to use' but implies it through contrast with other tools.

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

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

Annotations already declare readOnlyHint=true. The description adds 'Never mutates state', 'Paper trading only', and lists output fields like decisionSupport, which adds behavioral context beyond the annotation.

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

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

Two sentences, each essential. The first sentence delivers the core purpose and outputs, the second adds critical usage notes. No wasted words.

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

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

The description covers outputs, usage constraints, and safety (paper trading, not financial advice). With an output schema, it doesn't need to detail return structure. It complements sibling tools like discover_pm_markets, so the context is sufficiently 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?

With 100% schema coverage, baseline is 3. The description adds specific constraint on stakeMusd (must be > 0, min to open is 10) and implies the role of source and slug, providing more meaning than the schema alone.

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 a binary outcome, listing specific outputs (entry probability, share estimate, etc.) and the verb 'quote' with the resource 'PM' distinguishes it from sibling tools like spot_quote 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?

The description provides context (quote, gauge tradability), includes a constraint (stakeMusd > 0, min 10), and notes it's paper trading and not financial advice. However, it does not explicitly state when to use vs. alternatives.

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

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

Annotations already declare readOnlyHint and destructiveHint. The description adds that it's paper trading only with virtual funds and not financial advice, which is useful behavioral context not conveyed by annotations. 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?

Three sentences: purpose, usage guidance, and context. Every sentence earns its place. Front-loaded with key verb and resource. 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?

With output schema present, the description covers the main behavior (resolve to coinId with alternatives and tags). It gives sufficient context for an agent to use it effectively, though a bit more detail on handling alternatives could be added.

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 the 'q' parameter described. The description provides examples (BTC, bitcoin, Ethereum) but adds limited new semantic information 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 resolves symbols/slugs/names to a coinId, which is a specific verb-resource combination. It distinguishes itself from sibling tools (orders, positions, quotes) by its unique purpose of providing the coinId needed by other 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?

Explicitly says 'Use this FIRST' and warns against guessing UCIDs because symbols are not unique. This provides clear when-to-use and when-not-to-use guidance, referencing the need for coinId in sibling tools.

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

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

Declares 'Never mutates state', consistent with annotations (readOnlyHint, destructiveHint). Adds that price age is informational, providing 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?

Efficient sentences, front-loaded with core purpose. Slightly dense but no wasted words. One sentence could be merged, but overall well-structured.

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

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

Covers read-only nature, paper trading, coinId resolution, and disclaimer. Output schema exists so return values not needed. Adequate for a quote tool with moderate complexity.

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

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

Schema coverage is 100%, description adds minimal extra: coinId is UCID not ticker. Side and quantity meanings are mostly redundant with schema. Baseline 3 with negligible added value.

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, lists outputs (price, cost, balance, eligibility), and distinguishes from place_spot_order and sibling quote tools (futures_quote, pm_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?

Explicitly recommends using before place_spot_order, warns about coinId format needing resolve_symbol, and notes paper trading. Lacks explicit when-not-to-use but context is clear.

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

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

Annotations already indicate read-only and non-destructive. Description adds valuable context: paper trading only with virtual funds and a disclaimer. No contradictions.

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

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

Two sentences: first states purpose concisely, second gives usage guidance and important caveats. No unnecessary words.

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

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

With zero parameters and an output schema (implied), the description explains what is returned and provides usage context. Complete for the tool's simplicity.

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

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

No parameters exist, so description doesn't need to add parameter information. Baseline of 4 is appropriate.

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

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

The description clearly states the tool returns identity information (userId, keyId, scopes). It uses a specific verb 'Return' and resource 'identity behind the configured API key'. This distinguishes it from sibling tools which are all trading-related.

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

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

Explicitly says 'Use this first to confirm what the key is allowed to do', providing clear when-to-use guidance. Also mentions paper trading environment. No need for exclusions as no sibling does the same function.

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