CoinRithm Agent Trading

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

Adds context beyond annotations: mentions fund release (consistent with destructiveHint) and paper trading restriction. Annotations already indicate destructiveness, so description adds valuable behavioral nuance.

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 waste: first states action and effect, second adds constraints and disclaimer. Extremely concise 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?

Sufficient for a simple cancellation tool with one parameter and an output schema. Could mention response details, but output schema likely covers that. Missing notes on idempotency or rate limits, but acceptable.

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?

Only one parameter (orderId) with schema coverage 100%, and description does not add extra meaning beyond the schema's 'Open order id.' 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 'Cancel', the resource 'open spot order', and the effect 'releases frozen funds', distinguishing it from sibling tools like place_spot_order.

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?

Specifies required scope (trade:spot) and notes paper trading only, providing context. However, it does not explicitly mention when not to use or alternatives, like using a different tool for futures 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?

Discloses idempotency requirement, required scope (trade:futures), paper trading only with virtual funds, and that it's not financial advice. Annotations indicate destructive and idempotent hints, and the description adds context beyond them 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?

Three sentences, each essential. Front-loaded with primary purpose, then fraction usage, then key requirements. 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 moderate complexity, annotations cover safety, output schema exists (not shown but present), and the description covers purpose, parameters, limitations (paper trading), and required scope. Complete 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?

All 3 parameters are described in the schema (100% coverage). The description adds extra guidance: 'fraction in (0,1] reduces partially; omit (or 1) for a full close.' and highlights that idempotencyKey is required, adding value beyond schema.

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

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

The description clearly states the tool's purpose: 'Close or partially reduce a mock futures position.' It specifies the action (close/reduce), resource (futures position), and distinguishes 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 context: it's for closing or partially reducing futures positions, with fraction usage explained. Mentions required idempotencyKey and paper trading nature. Lacks explicit when-not-to-use or alternatives, but the context 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 valuable context about being discovery-only, returning specific fields, and using mock-PM sources, exceeding annotation coverage.

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

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

Three sentences that are front-loaded with the core purpose, then workflow, then context. Every sentence contributes meaning 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?

With an output schema present, the description need not detail return values. It covers the essential discovery-use pattern, references needed subsequent tools, and provides enough context 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?

Schema coverage is 100%, so baseline is 3. The description does not elaborate on parameters beyond what the schema provides, but the overall tool context is clear. No additional parameter-specific meaning is added.

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

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

The description starts with a clear action verb 'Find' and specifies the resource 'active-open, quote-ready-first prediction markets' with sources. It distinguishes itself from siblings by outlining the subsequent steps, making the purpose unambiguous.

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

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

Explicitly states the tool is for discovery only and provides a concrete workflow: call pm_quote with the returned outcomeExternalMarketId before open_pm_position. Also clarifies paper trading and not financial advice.

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, destructiveHint=false, and openWorldHint=true. The description adds context: never mutates state, returns specific fields, paper trading with virtual funds, not financial advice. No contradiction with annotations. Slightly more explanation of the open world hint could be beneficial.

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 that front-load the purpose, then add usage constraints and context. 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?

With an output schema present (as indicated by context signals), the description does not need to explain return values. It covers purpose, usage, constraints, and behavioral context sufficiently for an agent to invoke correctly.

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

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

Schema description coverage is 100%, so the schema already documents parameters. The description adds minimal value beyond parameter meanings (e.g., leverage and marginMusd constraints are already in 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 'Read-only futures quote' and lists specific returned fields (entry price, notional, size, liquidation price, eligibility). It distinguishes from sibling tools like spot_quote, pm_quote, and open_futures_position by its read-only nature and focus on futures quotes.

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

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

The description explicitly says 'always quote before opening', implying when to use this tool. It provides constraints (leverage 1-20, marginMusd >= 10) and context (paper trading, virtual funds). It could be improved by mentioning alternatives like spot_quote or pm_quote for other markets.

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 a safe read operation. The description adds valuable context: public data only, no account/key identity, paper trading with virtual funds, and a disclaimer. 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 concise at four sentences, each serving a purpose: first sentence identifies the output, second and third set constraints, fourth disclaims. No wasted words, and key information is front-loaded.

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

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

Given the tool's low complexity (one parameter, no nested objects) and the presence of an output schema, the description covers input, output, constraints, and usage context comprehensively. 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?

The input schema has 100% coverage with a clear description for `handle`. The description adds further value by stating the handle comes from `get_arena_leaderboard` and providing an example, making the parameter's origin and format clearer.

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's action: retrieving one agent's public Arena profile by handle. It specifies the output includes rank, PnL, trade counts, and win rate, distinguishing it from the sibling `get_arena_leaderboard` which lists all agents.

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 that the handle comes from `get_arena_leaderboard` and provides an example. It clarifies this is public data, paper trading only, and not financial advice, giving context on when to use. Lacks explicit when-not-to-use or alternative tools, but the sibling context and constraints are 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, openWorldHint, destructiveHint. The description adds important behavioral details: public data only, paper trading with virtual funds, qualification condition (minDecidedTrades), and demo/house agent seeding. 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?

Every sentence serves a purpose: purpose, ranking criteria, qualification, usage advice, data nature, disclaimer. Front-loaded with the main action. 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?

Given the presence of output schema and annotations, the description covers ranking details, conditions, limitations, and companion tools comprehensively. 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 descriptive parameter min/max. The description does not add parameter-specific detail beyond the schema but provides context about the data filtered by minDecidedTrades (not a parameter). Adequate.

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

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

The description clearly states it retrieves the public Agent Arena leaderboard, specifying the ranking metric (total realized PnL) and breakdown (per-venue, win rate). It distinguishes from siblings by mentioning 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?

It tells when to use the tool ('see the field and where you stand') and suggests companion tools. It does not explicitly state when not to use, but the context is clear.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds context about the paper account (virtual funds) and the output format, which enhances transparency without contradicting 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 concise (4 sentences) with no wasted words. It front-loads the main purpose and covers all key aspects efficiently.

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 (1 parameter, existing output schema) and annotations covering safety, the description is complete. It explains the output format, parameter, context (paper account), and includes a necessary disclaimer.

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% (the only parameter 'days' is fully described in the schema). The description essentially repeats the same information, adding no new semantic value beyond the schema.

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

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

The description clearly states the verb 'get' and resource 'equity curve', specifying it returns a daily wallet equity time series for the paper account. It distinguishes from siblings like get_performance and get_portfolio by emphasizing paper trading and virtual funds.

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 tool is for reviewing performance over time and narrating results, and notes it is for paper trading only with virtual funds. While it does not explicitly list alternatives, it provides clear usage boundaries and the disclaimer about not being financial advice.

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 valuable behavioral context: 'Facts only — no generated thesis' and 'Not financial advice,' confirming it is a read-only, factual tool. Paper trading disclosure is also beneficial.

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

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

The description is detailed but well-structured, front-loading the purpose and then listing outputs. While somewhat long, every part adds value. Minor redundancy with parameter instructions, but 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 presence of an output schema, the description fully covers what the tool returns: price, changes, categories, sentiment, Fear & Greed, prediction markets with specific attributes, and similar coins. No 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 coverage is 100% and description of coinId in schema is sufficient ('Coin UCID (e.g. "1" = BTC). Use resolve_symbol to find it.'). The description repeats this but adds no additional meaning, 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 that the tool provides 'Compact factual context for ONE coin to form a thesis' and enumerates specific data items (price, changes, market cap, categories, sentiment, Fear & Greed, prediction markets, similar coins). It distinguishes itself from sibling tools which are mostly order/position operations.

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

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

The description instructs to 'Call resolve_symbol first to get the coinId,' which is a prerequisite. It also notes 'Paper trading only — virtual funds.' While it lacks explicit 'when not to use' or alternative tools, the context is clear enough for 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 declare readOnlyHint and destructiveHint false, so the description's statement 'Paper trading only — virtual funds (50,000 mUSD). Not financial advice.' adds valuable behavioral context beyond the annotations, clarifying that the tool operates in a simulated environment.

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

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

The description is very concise, consisting of two sentences that front-load the essential information (what it does, how it's ordered, and the paper trading context). Every sentence adds value without redundancy.

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

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

Given the tool's simplicity (list closed trades with two parameters) and the presence of an output schema, the description covers all necessary aspects: the data returned, ordering, and usage context. It is complete and leaves no major 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 the schema fully documents both parameters. The description adds 'most-recent first' which implies default ordering but does not provide additional parameter semantics beyond what the schema already offers. Baseline score of 3 is appropriate.

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

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

The description clearly states it is a unified realized-PnL log of CLOSED trades across venues, most-recent first, and distinguishes it as the agent's memory of past actions and outcomes. The verb 'get' combined with 'my trades' and the specific scope make the purpose very clear.

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 it to review performance before deciding the next move,' providing clear when-to-use guidance. It also notes paper trading and virtual funds, setting expectations. However, it could more explicitly contrast with sibling tools like 'get_performance' or 'get_portfolio' to help the agent choose between them.

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 openWorldHint. The description adds value by detailing that it returns only closed trades, paper trading context (virtual funds of 50,000 mUSD), and that win rate is null until trades are decided. 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 that front-load the primary output (realized performance metrics), then scope (closed trades, scorecard for agent), and finally context (paper trading, disclaimer). Every sentence adds necessary information 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 an existing output schema, the description fully covers what the tool does, what data it returns, the scope (closed trades, paper trading, calling key), and includes a disclaimer. It is complete for an AI agent to understand invocation and interpretation.

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

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

The tool has zero parameters and schema coverage is 100%. The description does not need to explain parameters; baseline of 4 is appropriate as it adds no parameter information but none is needed.

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

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

The description clearly states the tool returns the calling key's realized performance with specific metrics (total+per-venue PnL, trade counts, win/loss/neutral, win rate). It distinguishes from siblings by specifying 'closed trades only' and 'paper trading only', making the purpose unambiguous.

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

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

The description implies when to use (to check own realized performance) but lacks explicit guidance on when not to use or direct comparisons to sibling tools like get_equity_curve or get_portfolio. The context is clear but not explicit.

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. Description adds that it's for paper trading with virtual funds and is 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, concise and front-loaded with key information. Every sentence adds value without redundancy.

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

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

Given the presence of an output schema, the description adequately covers what the tool returns. It mentions key components but could briefly differentiate from sibling tools for enhanced 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?

Both parameters (fiat, locale) are fully described in the schema (100% coverage). The description does not add additional meaning beyond what the schema already 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?

Description explicitly states it retrieves the paper account dashboard and lists specific components (equity, PnL, balances, orders, history), distinguishing it from sibling tools like get_wallet or get_performance.

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?

Clearly states 'Paper trading only' with virtual funds, implying use for paper accounts, but does not explicitly mention when not to use or name alternatives among 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 destructiveHint=false, but the description adds valuable behavioral context: it returns mock positions, explains venue-specific details (unrealized PnL/liquidation distance for futures, unrealized mark for pm), and confirms paper trading. 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 (two lines) and well-structured: first sentence states the core function, second provides venue-specific details, third adds paper trading context. 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 that an output schema exists, the description does not need to explain return values. It covers the tool's purpose, venue options, and the mock/paper trading nature, which is complete for a read-only tool.

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

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

The input schema has 100% coverage with a single required enum parameter 'venue'. The description adds meaning by explaining what each enum value returns, going beyond the schema's basic 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 'List open + historical positions for a venue,' specifying the verb and resource. It distinguishes between two venues ('futures' vs 'pm') and their return values, differentiating it from sibling tools that modify 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 explains when to use the tool (to list positions for a venue) and provides context about paper trading and virtual funds. While it does not explicitly mention when not to use it, the context is clear enough for agent decision-making.

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 behavioral traits: paper trading only, virtual funds of 50,000 mUSD, and non-financial advice disclaimer, 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?

Two sentences, front-loaded with main purpose, no fluff. Every sentence earns its place, efficiently conveying purpose, constraints, and disclaimer.

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 what is returned (USDT and frozen partitions) and the optional parameter. With output schema existing, return value details are not needed, but the description is still adequate for a simple read 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 a clear description of coinId parameter. The description adds 'Optionally include one coin asset' which slightly clarifies but does not add significant 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 the verb 'Get' and the resource 'raw cash balances', specifying USDT available and three frozen partitions. It distinguishes itself from sibling tools by being the only tool for wallet balances.

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: paper trading only, virtual funds, and optional coin inclusion. It does not explicitly state when not to use or list alternatives, but the paper trading constraint implies real trading exclusion.

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, so description adds value by specifying paper trading and virtual funds. However, it doesn't disclose additional behavioral aspects like rate limits or data freshness.

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

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

Two sentences, front-loaded with main function, concise and free of fluff. 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 presence of an output schema, description sufficiently covers purpose, constraints, and required parameter. No gaps for a simple list tool.

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

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

Schema coverage is 100% with good descriptions. Tool description reiterates that coinId is required, adding minimal extra 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?

Description clearly states it lists open spot orders for one coin, using specific verb 'list' and resource 'open spot orders'. Distinguishes from siblings by specifying 'for ONE coin' and noting paper trading 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 states coinId is required and that it's paper trading only, providing clear context. Does not explicitly list when not to use or alternatives, but the constraint is helpful.

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 non-read-only, idempotent, and non-destructive. The description adds important behavioral details: it is a mock/paper trade, server-flag gated (403 if disabled), idempotency key behavior, and the need to quote and confirm. It also notes 'Not financial advice.' 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 and front-loaded, using three sentences to convey the action, requirements, and warnings without unnecessary verbiage.

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 5 required parameters, output schema exists, and annotations are present, the description covers scope, gating, idempotency, constraints, usage instruction, and paper trading nature. A minor gap: it does not clarify behavior when adding to an existing position (e.g., margin consolidation).

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 add significant new meaning. It reiterates constraints already in schema (idempotencyKey uniqueness, leverage range, margin minimum). The emphasis on 'idempotencyKey is REQUIRED' is already clear from schema's required array.

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 opens or adds to a mock futures position, specifying it is for futures trading (as opposed to spot) and is paper trading only. It distinguishes from siblings 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?

The description provides clear context for use: requires trade:futures scope, idempotency key must be unique, leverage and margin constraints, and instructs to quote first and confirm. However, it does not explicitly exclude alternatives or mention when not to use this tool versus spot trading.

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 authentication scope, server-flag gating with potential 403, idempotency requirement, minimum stake, user confirmation step, virtual funds nature, and disclaimer. Adds significant context beyond annotations (readOnlyHint=false, idempotentHint=true, etc.) 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?

Compact description with front-loaded core purpose. Each sentence adds value: action, scope, gating, required field, constraint, usage instruction, disclaimer. No redundant or vague phrasing.

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 most aspects: what, prerequisites, constraints, usage flow, and financial disclaimer. Output schema exists, so return details are covered. Could mention error scenarios beyond 403, but overall complete for a well-annotated 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 parameters. Description reinforces that 'idempotencyKey is REQUIRED' and 'stakeMusd >= 10', and mentions that 'outcomeExternalMarketId' is returned by discovery. Adds minimal new meaning.

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

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

The description clearly states it opens a 'mock prediction-market position (binary outcomes only)'. The verb 'Open' and resource 'prediction-market position' are specific. It distinguishes from sibling tools like 'open_futures_position' and 'pm_quote' by specifying binary, mock, and paper trading.

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

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

Explicitly instructs to 'Quote first and CONFIRM with the user', implies use of 'pm_quote' before this tool. States requirement 'Requires the trade:pm scope' and context 'Paper trading only'. Does not explicitly list alternatives, but the flow 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 adds significant behavioral context beyond annotations: it clarifies paper trading (virtual funds), that coinId is a UCID not ticker, and that it's not financial advice. Annotations set openWorldHint=true but no contradiction; the description complements with needed caveats.

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—3 sentences, no filler. The main action is front-loaded ('Place a paper spot order'), and each subsequent sentence adds essential detail 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's simplicity and the presence of an output schema (not shown but noted), the description covers all necessary context: purpose, parameter nuances, required scope, confirmation requirement, and paper trading nature. No gaps for an agent to misuse 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% (baseline 3), but the description adds critical meaning: it explains coinId is a coin UCID not a ticker, specifies when limitPrice/stopPrice are required, and lists orderType options. This adds value beyond the schema's brief 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 'Place a paper spot order', specifying the verb (place) and resource (spot order). It distinguishes from sibling tools like cancel_spot_order and close_futures_position by explicitly noting 'paper trading only', making the tool's unique purpose unmistakable.

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 guidance: it is for paper trading only, requires the 'trade:spot' scope, and instructs to confirm with the user before calling. It does not explicitly list when not to use or compare to alternatives, but the context is sufficient for 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 provide readOnlyHint and destructiveHint; description adds paper trading, virtual funds, and market quality flags, enhancing 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?

Three sentences, front-loaded with purpose, no wasted words. Efficiently conveys all necessary information.

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

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

With output schema present, description focuses on input usage and behavioral context. Could mention output structure but not required; covers all key aspects for a quoting 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 but description adds specific constraint 'min to open is 10' beyond schema's exclusiveMinimum: 0, and explains the stake parameter 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 specifies a read-only quote for binary PM outcomes, listing specific values returned (entry probability, share estimate, etc.) and distinguishing it from sibling tools like spot_quote or 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?

States read-only nature, paper trading context, and a constraint on stakeMusd. Does not explicitly list when not to use or alternatives, but the context is clear.

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

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

Annotations already declare readOnly and non-destructive. Description adds that it returns disambiguating alternatives with tags, virtual funds, and not financial advice, enhancing transparency.

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 efficient sentences: function, usage guidance, and important caveats (paper trading, no financial advice). 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 the simple single-parameter tool with output schema, the description fully covers purpose, usage, and behavior. 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. The description provides examples ('BTC', 'ethereum') adding value. Baseline 3, plus examples justifies 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 it resolves human symbols/slugs/names to coinId with alternatives and tags, and explicitly tells agents to use it before other tools. This differentiates it from 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?

Provides explicit guidance: 'Use this FIRST to get the coinId that the wallet / quote / order tools need — don't guess UCIDs (symbols are not unique).' Also notes paper trading only.

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 never mutates state, consistent with annotations (readOnlyHint=true, destructiveHint=false). It adds context about price age being informational, paper trading limitations, and that quotes are for market orders. 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 logically structured, starting with the core purpose, then usage guidance, then behavioral notes. It is concise with no filler, though it could be slightly more compact. The key information is front-loaded.

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

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

Given the presence of an output schema (not shown), the description does not need to detail return format. It covers all essential aspects: purpose, usage context, parameter guidance, behavioral constraints, and disclaimers. Complete for a quote tool.

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

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

Schema coverage is 100% with descriptions for all three parameters. The description adds meaning: 'side' is explained as buy/sell effects, 'coinId' example given, 'quantity' clarified as base amount. 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 is a read-only spot market quote tool, listing what it provides (execution price, estimated cost, available balance, fill eligibility). It distinguishes itself from sibling tools like 'place_spot_order' and 'futures_quote' by emphasizing its read-only nature and use case.

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 the tool before 'place_spot_order' to avoid blind trading. It also warns that 'coinId' is a UCID not a ticker and advises using 'resolve_symbol' first. Mentions paper trading and virtual funds, though it does not explicitly state when not to use it.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful behavioral context: that the tool operates in a paper trading environment with virtual funds (50,000 mUSD) and includes a disclaimer. This enhances 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?

Three short sentences, each serving a clear purpose: return value, usage recommendation, and environmental context. No superfluous 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 zero parameters, existing annotations, and the presence of an output schema, the description covers all necessary aspects: what it does, when to use it, and the paper trading 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?

The tool has zero parameters, so schema coverage is 100%. The description adds value by explicitly naming the output fields (userId, keyId, scopes), which is not required but helpful.

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

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

The description uses specific verb 'Return' and lists concrete fields (userId, keyId, granted scopes). It clearly identifies the tool's function and distinguishes it from siblings which deal with trading, orders, and 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 explicitly advises to use this tool first to confirm API key permissions, providing clear usage context. While it doesn't mention when not to use, the recommendation is sufficient for this simple tool.

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