CoinRithm Agent Trading

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

The description goes well beyond annotations, detailing paper trading specifics such as virtual funds, execution costs, taker fees, slippage, and the non-guarantee of exchange fills. This provides rich behavioral context for the agent, with no contradictions to annotations.

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

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

The description is front-loaded with the core action and then adds relevant context. It is slightly verbose with detailed execution cost explanations, but still reasonably concise for the information provided.

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 annotations and an output schema, the description is complete. It covers purpose, prerequisites, environmental constraints, and behavioral details sufficiently for an agent to correctly invoke the tool.

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

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

Schema description coverage is 100%, so the schema already fully describes parameters. The description adds no additional parameter semantics beyond what is in the schema.

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

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

The description clearly states the verb 'cancel' and the resource 'open spot order by id', and adds the effect 'releases frozen funds'. It distinguishes from sibling tools like 'place_spot_order' and 'list_open_orders' by explicitly being a cancellation action.

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

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

The description mentions the required scope 'trade:spot' and specifies that it is 'Paper trading only', which guides when to use the tool. However, it does not explicitly state when not to use or suggest alternative tools.

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

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

Annotations already indicate destructiveHint=true, idempotentHint=true. The description adds significant behavioral context: execution cost (taker fee, half-spread, slippage), paper-only nature, virtual funds, and that it is 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 relatively long but front-loaded with the main action and key points. Every sentence adds value, though some details about execution models could be condensed. Still efficient for the complexity.

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

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

Given the tool's complexity (paper trading simulation, execution costs, idempotency), the description covers all necessary aspects. It explains the execution model with enough detail for an AI agent to understand behavior. Output schema exists but description does not need to repeat 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?

Schema covers all 4 parameters with descriptions (100% coverage). The description adds extra context for fraction (how to use) and idempotencyKey (required, replay semantics). Could be slightly more explicit for agentTrace, but overall good.

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 action (close or partially reduce), the resource (mock futures position), and includes specific details like fraction behavior and required field. It distinguishes from sibling tools by focusing on futures and mentioning paper trading execution details.

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 close/reduce a position) and what is required (positionId, idempotencyKey). It mentions the required scope (trade:futures) and that it is paper trading only. It does not explicitly state when not to use or provide direct comparison to alternatives, but the context is clear.

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

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

Annotations already declare readOnlyHint and openWorldHint. The description adds context such as the return fields and the workflow relationship to pm_quote, but also includes paper trading details that are not strictly about this tool's behavior. 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 front-loads the core purpose but includes verbose details about paper trading costs and execution models that are more relevant to trade tools. Could be more concise without losing essential information.

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

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

The description covers the purpose, return fields, workflow, and mock environment context. With an existing output schema and good annotations, it provides sufficient completeness for a discovery 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% and all parameters have clear descriptions. The tool description adds minimal extra meaning beyond stating default sources and sort, which are already in the schema. Baseline score applied.

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' and the resource 'prediction markets' with specifics on sources and return fields. It distinguishes from sibling tools like pm_quote and open_pm_position by positioning itself as a discovery step.

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 call pm_quote before open_pm_position, indicating the correct workflow. Also clarifies that this is discovery only and for paper trading, providing 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?

Adds significant behavioral context beyond annotations: limit of 1,000 rows, privacy (no public Arena user can see), paper trading, and detailed execution cost model. 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?

Concise and well-structured: front-loaded with primary action, then covers filters, privacy, paper trading, and execution costs. 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?

With an output schema present and 8 parameters (including nested objects), the description covers all necessary context: limit, privacy, filters, trading nature, and cost details. Complete 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%, so parameter descriptions already exist. The description adds context about using filters for runId/decisionId but does not elaborate on each parameter. 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 (export), resource (private ledger rows), and scope (up to 1,000, for the calling API key). It differentiates from siblings like get_agent_ledger and export_run_evidence by specifying privacy and scope.

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

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

Provides explicit guidance on using filters for reproducible evaluation, states it's paper trading only, and explains the execution cost model. Does not explicitly mention alternatives but gives clear context for when to use.

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

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

The description fully discloses behavioral traits beyond annotations: the bundle includes specific items, privacy level (private, not public), and the nature of paper fills (execution costs, no exchange fill guarantee). Annotations already indicate readOnlyHint=true and destructiveHint=false, and the description consistently adds value 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 a single paragraph that fronts the main purpose and then provides details. It is dense but each sentence adds value. Could be slightly more concise, 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?

Given the tool has an output schema (covering return values) and rich annotations, the description completes the picture: explains what the bundle contains, privacy, paper trading constraints, and execution cost details. No obvious 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 description coverage is 100%, so baseline is 3. The description mentions 'for a specific agentTrace.runId' but does not add new parameter-specific details beyond what the schema already provides (e.g., runId required, agentTrace optional). The context about bundle contents is indirectly helpful but not parameter-focused.

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

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

The description explicitly states the verb 'Export', the resource 'private reproducibility bundle', and the scope 'for a specific agentTrace.runId'. It clearly distinguishes this tool from siblings like 'export_agent_ledger' by specifying the unique bundle contents (sanitized ledger rows, execution assumptions, 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?

The description provides important context: paper trading only, virtual funds, and execution cost details. It mentions that no public Arena user can see the data. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., export_agent_ledger) and does not 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 declare readOnlyHint true; description reinforces no mutation. It adds critical context: paper trading with virtual funds, execution cost model including fees and slippage, and that it's 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?

Description is front-loaded with core purpose. However, it is somewhat lengthy due to detailed execution cost explanation. Every sentence is valuable, but could be slightly more concise.

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

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

Given that an output schema is present, the description covers return values, constraints, behavior, and edge cases (paper trading, fees). It is complete for a read-only 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%, so each parameter has its own description. The tool description restates leverage range and margin minimum already in schema, adding no new semantic 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?

Description clearly states it provides a read-only futures quote with specific fields (entry price, notional, size, liquidation price, eligibility). It distinguishes itself from mutation tools like open_futures_position and from pm_quote and spot_quote by specifying 'futures' and 'read-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?

Description instructs to 'always quote before opening', sets constraints (leverage 1-20, marginMusd >= 10), and notes paper trading only. It does not explicitly compare siblings, but the purpose is sufficiently differentiated.

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 significant behavior beyond annotations: details contents, per-key scoping, paper trading specifics (execution costs, no exchange guarantee), and trace metadata. Annotations already indicate read-only, non-destructive, and open world, which description complements.

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

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

Front-loaded with the main purpose, but the description is verbose with detailed paper trading execution costs that could be condensed. Some redundancy, though informative.

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

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

Given complexity (10 params, nested objects, output schema exists), description covers purpose, usage, behavior, and scope well. Mentions key fields and constraints, though output schema handles return details.

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. Description adds no significant parameter-specific detail beyond schema, only high-level references to optional trace metadata.

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 verb ('List') and resource ('private execution ledger'), specifying contents (reads, quotes, writes, etc.) and distinguishing from siblings by noting it only returns rows for the calling key.

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

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

Explicitly states usage for auditing paper-trading runs and clarifies paper trading only with virtual funds, providing clear context. Does not explicitly exclude alternatives but is specific enough.

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

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

The description goes far beyond annotations by detailing execution costs, taker fees, slippage, and the paper-trading nature. It provides a transparent account of how realized PnL is computed and what 'rehearsal cost' means, which is critical for correct interpretation.

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

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

The description is front-loaded with the core purpose in the first sentence, then adds necessary details. It is slightly verbose but each sentence adds value, and the structure is logical.

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

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

Given this is a read-only tool with an output schema, the description thoroughly explains returned data and the paper-trading execution model. It provides complete context for an agent to understand the tool's behavior without needing external references.

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 for 'handle'. The main description adds an example value but does not significantly enrich the parameter semantics 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 it returns a single agent's public Arena profile by handle, listing specific data (rank, PnL, trade counts, win rate). It distinguishes itself from the sibling 'get_arena_leaderboard' which returns a list.

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

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

The description specifies it is for public data only, paper trading, and not financial advice, implying it's safe and low-stakes. However, it does not explicitly state when to prefer this tool over siblings like get_arena_leaderboard.

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. Description adds extensive context: paper trading, virtual funds, execution costs, min-decided trades threshold, and that it's not financial advice. No contradictions.

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

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

Front-loaded with purpose, but includes very detailed execution cost explanation that could be separate. While informative, it is verbose.

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 thoroughly explains ranking criteria, window behavior, public data scope, and caveats. Output schema exists, so return values are covered.

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 parameter descriptions. Description adds value by explaining window behavior (reranking by in-window PnL) and scoping of counts/winRate/sparkline.

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

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

The description clearly states the tool returns a ranked list of agents by realized PnL, with per-venue breakdown, and distinguishes it from siblings like 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?

Explicitly says to use to see the field and where you stand, and mentions pairing with get_performance and get_arena_agent. Does not explicitly state when not to use, but context implies it's for public leaderboard viewing.

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

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

Annotations already indicate readOnlyHint and no destructiveness. The description adds valuable behavioral context: paper trading only, virtual funds, execution costs, and non-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 comprehensive but somewhat verbose, including detailed execution cost explanations that could be condensed. Purpose is front-loaded, but overall length exceeds necessary conciseness.

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

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

Given the output schema exists, the description adequately covers prerequisites, range details, and behavioral caveats. It is complete for a data retrieval tool with clear annotations and schema.

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

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

Schema coverage is 100%, so parameters are documented. The description adds meaning beyond schema—explaining range as both lookback and resolution mapping, and reinforcing coinId lookup via resolve_symbol.

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

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

The description clearly states the tool provides OHLCV candles for indicator/momentum strategies, specifies the need to call resolve_symbol first, and distinguishes itself from siblings by focusing on data retrieval, not orders or 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 resolve_symbol first and explains the range parameter's mapping to lookback and resolution. It does not explicitly state when not to use the tool, 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, openWorldHint=true, destructiveHint=false. The description adds significant behavioral context: it operates on paper trading only, uses virtual funds, and explains execution costs (taker fees, slippage, etc.) that affect the realized PnL. This goes beyond annotations and fully discloses the nature of the data.

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

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

The description is front-loaded with the core purpose and then explains parameters and context. It is somewhat lengthy but every sentence adds value, especially the detailed execution cost information. Could be slightly more concise but well-organized.

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, full schema coverage, annotations, and presence of an output schema, the description is comprehensive. It covers purpose, parameter explanations, paper trading context, execution model, and disclaimers. No missing information is apparent.

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 meaningful semantics for both parameters: for granularity, it explains the difference between daily and realized modes with explicit use cases; for days, it clarifies the look-back window. This adds value beyond the schema descriptions, justifying a 4.

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

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

The description clearly states it returns a wallet equity time series for a paper account. It uses specific verb+resource ('wallet equity time series') and distinguishes from siblings like get_portfolio or get_performance by focusing on historical performance over time. The explicit mention of 'basis for reviewing performance over time and narrating results' clarifies its purpose effectively.

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 for when to use each granularity mode (daily for general review, realized for active intraday agents) but does not explicitly compare with sibling tools or state when not to use this tool. It implies use for historical performance review but lacks direct alternatives guidance.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true. The description goes well beyond by detailing the paper trading nature, virtual funds, execution costs, taker fees, slippage, and that results are rehearsal costs not exchange fill guarantees. There is no contradiction with annotations, and the description adds substantial behavioral context.

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

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

The description is long but every sentence carries important information: what data is included, the prerequisite, the paper trading context, and execution model details. It is front-loaded with the core purpose. It could be slightly more structured (e.g., bullet points) but remains efficient with 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 output schema exists, the description does not need to detail return values. It thoroughly explains what is included (price changes, market cap, sentiment, prediction markets with depth details, similar coins). It also covers the paper trading execution model. This is complete for an informational context tool with rich annotations.

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

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

Schema description coverage is 100% for both parameters (coinId and agentTrace). The description adds value by explaining the prerequisite to use resolve_symbol for coinId, and for agentTrace it restates the schema description. The additional prerequisite guidance raises it above the baseline of 3, though it does not provide deep parameter-specific examples.

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

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

The description clearly states it provides 'compact factual context for ONE coin' including price, changes, market cap, category tags, sentiment, Fear & Greed, prediction markets, and similar coins. It uses specific verbs and resources, and distinguishes itself from sibling tools by being a comprehensive context-gathering tool rather than a specific price or order function.

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

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

The description gives explicit prerequisite guidance: 'Call resolve_symbol first to get the coinId.' It also sets context by stating 'Paper trading only' and 'Facts only — no generated thesis.' However, it does not explicitly mention when to use this tool versus specific alternatives like get_candles or discover_pm_markets, which are available, slightly limiting the completeness of usage guidance.

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

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

Annotations already indicate readOnlyHint, destructiveHint, and openWorldHint. The description adds significant context: paper trading only, virtual funds (50,000 mUSD), execution cost details, and that asOf is returned for cursor-based polling. This goes well 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 thorough but somewhat verbose, including detailed execution cost notes that could be considered extraneous. It front-loads the main purpose but could be more concise.

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

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

Given the annotations and output schema (stated as existing), the description covers what the agent needs: paper trading environment, cursor polling, and performance review context. No gaps identified for a read-only data retrieval tool.

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

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

Schema coverage is 100% so parameters are documented. The description adds value for updatedSince by explaining how to use it with asOf. For limit and venue, it repeats schema info. Overall, it enhances understanding of the polling parameter 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 it is a 'Unified realized-PnL log of CLOSED trades across venues, most-recent first,' specifying the verb (get), resource (trades), and scope (closed trades). It distinguishes from siblings like get_performance and get_positions by focusing on realized PnL and closed 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?

Explicitly says 'Use it to review performance before deciding the next move' and explains the updatedSince parameter for polling. It implies usage for performance review but does not explicitly list alternative tools for 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 indicate readOnlyHint, openWorldHint, destructiveHint. The description adds substantial behavioral detail beyond annotations: it explains paper trading context, closed trades only, that win rate is null until trades are decided, and details the execution cost model (taker fees, slippage, rehearsal nature). It does not contradict any annotation.

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

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

The description is front-loaded with key purpose and then provides necessary detail. It is somewhat lengthy due to execution cost explanations, but every sentence adds value. Could be slightly more concise by moving execution details to a separate section, but as a whole it is well-structured and informative.

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

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

Given the presence of an output schema and the complexity of the tool, the description covers all essential aspects: what is returned (metrics), scope (closed trades, paper trading), important caveats (not financial advice, execution cost model), and the fact that fills are rehearsals. It fully prepares the agent for correct 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?

Schema coverage is 100% for the single optional parameter (agentTrace). The description does not mention this parameter, but the schema already documents it adequately. Baseline is 3 because the description adds no extra 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 opens with a specific verb+resource combination: 'The calling key's own realized performance' and enumerates the exact metrics returned (realized PnL, trade count, win/loss/neutral counts, win rate). It clearly distinguishes this from sibling tools like get_portfolio or get_positions by focusing on closed trades and the agent's 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 establishes clear context: 'Closed trades only — the scorecard for this agent' and 'Paper trading only — virtual funds... Not financial advice.' It implies when to use (for performance of the calling key) but does not explicitly state alternatives or when not to use, leaving room for improvement in exclusion guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds valuable behavioral context: the virtual nature, execution cost model with explicit fee structures (taker fees, half-spread, slippage), and the note that executionModel results are rehearsal costs, not exchange fill guarantees. This exceeds what annotations provide.

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

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

The description is reasonably concise given the complexity, starting with the main purpose and then detailing contents and execution cost. Every sentence provides useful information, though the execution cost section is somewhat dense. It could be slightly more structured (e.g., bullet points), but it's efficient overall.

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 all aspects of the tool's return (walletId, equity breakdown, PnL, open orders, progression) and explains the unique execution cost model. Since an output schema exists, the description does not need to detail exact return types. It provides enough context for an agent to use the tool correctly.

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

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

Schema description coverage is 100%, so baseline is 3. The description does not add new semantics for the parameters (fiat, locale, agentTrace) beyond what is already in the input schema. It mentions fiat display and equity denomination, but these are present in 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 starts with a specific verb-resource pair ('Get the lean, PII-free paper account summary') and enumerates the exact contents (walletId, equity, PnL, open orders, progression block). It clearly distinguishes itself from sibling tools like get_wallet (which likely returns only wallet info) by being a comprehensive portfolio summary.

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

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

The description explicitly restricts to paper trading ('Paper trading only — virtual funds') and adds 'Not financial advice.' However, it does not provide guidance on when to use this tool versus alternatives (e.g., get_equity_curve for equity history or get_performance for PnL). Usage context is implied 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?

The description goes far beyond the annotations (readOnlyHint, openWorldHint, destructiveHint) by detailing the mock nature of data, execution cost models, fee structures, and the paper trading context. It also discloses that this is 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 front-loaded with the main purpose in the first sentence, but it is lengthy due to detailed execution cost and fee model explanations. While informative, some details could be abbreviated without losing essential guidance.

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

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

Given the presence of an output schema (not shown but referenced), the description covers all necessary aspects: venue-specific output, polling mechanism, paper trading constraints, fee disclosures, and mock data behavior. It provides sufficient context for an agent to use the tool correctly.

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

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

With 100% schema coverage, the description adds meaning beyond the schema by explaining how to use updatedSince (pass previous response's asOf) and elaborating on what each venue returns. However, for agentTrace it does not add much beyond the schema.

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

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

The description clearly states the tool lists open and historical positions for a venue, specifies the two venue options ('futures' and 'pm'), and describes what each returns. It effectively distinguishes from sibling tools like close_futures_position, open_futures_position, and get_portfolio.

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

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

The description provides explicit guidance on polling usage by instructing to pass the asOf value from the previous response to updatedSince. It also notes that this is paper trading only. While it doesn't explicitly list when not to use this tool, the context and sibling tools imply alternatives such as get_portfolio for overall portfolio overview.

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

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

Annotations indicate safe, read-only behavior. Description adds detailed behavioral traits: frozen partitions, paper trading nature, execution cost model (taker fees, slippage, etc.). No contradiction.

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

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

Description is verbose, especially execution cost details which seem tangential to a wallet query. While front-loaded with main purpose, it could be more concise.

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

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

Given annotations, schema, and output schema presence, description covers all necessary aspects: balances, optional filtering, paper trading, and execution model. No missing critical info.

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%. Description adds minor context for coinId ('Optionally include one coin asset'), but agentTrace is fully described in schema. Baseline 3 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?

Clearly states the tool gets raw cash balances with USDT and three frozen partitions. Specifically mentions optional coinId. Distinguishes from sibling tools (e.g., get_portfolio, get_positions) by focusing on 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?

Explains paper trading only and execution costs (rehearsal, not exchange fill). Provides context but does not explicitly compare to other tools or state when not to use.

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

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

Annotations already indicate readOnly and non-destructive. Description adds rich detail: delta polling via asOf/updatedSince, paper trading execution costs, fee structures, and 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?

Description is moderately long but well-structured: core action first, then filtering, polling, paper trading, execution model. Each sentence serves a purpose, though minor redundancy.

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

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

Given the tool's complexity (delta polling, paper trading, execution costs) and the presence of an output schema for return values, the description covers all necessary behavioral aspects for correct agent usage.

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

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

Schema coverage is 100%, but description adds meaningful usage guidance: coinId omission for all orders, updatedSince for delta polling, agentTrace for trace metadata. Exceeds baseline 3.

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

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

The description clearly states the tool lists open resting spot orders, with explicit mention of optional filtering by coinId. It distinguishes from sibling tools like cancel_spot_order and 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?

Provides clear usage context: paper trading only, virtual funds, delta polling mechanism. However, does not explicitly compare with alternatives like get_positions or get_portfolio for broader portfolio views.

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 key behaviors not in annotations: required scope (trade:futures), server flag gating, idempotency key usage, leverage and margin constraints, atomic SL/TP with corridor rules, paper trading nature, and execution cost details. It goes well beyond annotations with no contradictions.

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

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

The description is dense but not overly long; it front-loads the core purpose and then details. While some may find it lengthy, every sentence adds necessary context for a complex trading tool. Minor improvement could be more bullet-point structure.

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

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

Given the tool's complexity (8 parameters, nested object, output schema present), the description covers all critical aspects: scope, idempotency, constraints, atomic SL/TP, paper trading, and execution model. It is sufficient for an AI agent to use correctly.

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

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

With 100% schema coverage, the description adds critical context: idempotencyKey required and unique, leverage and margin ranges reinforced, and detailed side-aware corridor constraints for stopLossPrice/takeProfitPrice that the schema lacks. This significantly aids correct parameter usage.

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

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

The description clearly states the action ('Open (or add to)') and the resource ('a mock futures position'), with specific verb and resource. It distinguishes itself from sibling tools like close_futures_position and set_futures_sl_tp by focusing on opening.

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

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

The description advises to 'Quote first and CONFIRM with the user' and clarifies paper trading scope. While it implies when to use, it does not explicitly contrast with alternatives like futures_quote for quoting, but it sufficiently guides the agent.

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

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

The description adds significant context beyond annotations: requires trade:pm scope, server-flag gating, idempotency key required, stake minimum of 10, side semantics with payout explanation, paper trading only with virtual funds, and detailed execution costs. 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 fairly long but front-loads the purpose and key requirements. However, it includes detailed execution cost information that could be more concise or relegated to the output schema. Still, it is well-structured and clear.

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

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

Given the tool's complexity (7 params, output schema exists), the description covers scope, gating, idempotency, side semantics, paper trading nature, and execution costs. It does not explicitly mention the need to discover markets first, but that is implied by the 'outcomeExternalMarketId' parameter. Overall 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%, so baseline is 3. The description adds value by explaining the side enum in detail ('NO pays out if it resolves false; fills at 100 minus the outcome probability') and emphasizing idempotencyKey requirement, which is already in the schema but reinforced.

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 for binary outcomes only, using specific verbs and resource. It distinguishes from siblings like 'open_futures_position' and 'place_spot_order' by specifying 'binary outcomes only' and '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?

The description explicitly instructs to 'Quote first and CONFIRM with the user,' implying the need to use the quote tool (pm_quote) before acting. It also notes the idempotency key requirement for replay safety, but does not explicitly mention when not to use it or compare to alternatives like spot orders.

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

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

With minimal annotations (readOnlyHint=false, destructiveHint=false), the description fully discloses behavioral traits: paper trading, required scope, execution costs, no guarantee of exchange fills, and idempotency replay behavior.

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

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

The description is front-loaded with the core action and each sentence adds value, though length could be slightly reduced without losing information. Still efficient for the complexity.

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

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

Given 8 parameters, nested objects, and output schema present, the description covers paper trading scope, execution model, fees, idempotency, and required user confirmation, leaving 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%, but the description adds critical meaning beyond schema: coinId is a UCID not ticker, limitPrice/stopPrice requirements, and idempotencyKey uniqueness. This elevates from baseline 3.

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' and distinguishes itself from siblings like spot_quote (quotes only) and cancel_spot_order by specifying paper trading and required user confirmation.

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 confirm with the user before calling and explains idempotency key usage for retries, providing clear context. It does not explicitly list alternatives for real trading but implies paper-only scope.

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 elaborates extensively on what the tool returns (outcomes, probabilities, price snapshots, crossSourceMatches, referenceProbability, whale trades, related events, news) beyond the `readOnlyHint` and `openWorldHint` annotations. It adds context about free access and no API key requirement.

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 yet efficient, with every sentence providing valuable context. It is well-structured, front-loading key information and using clear separations for advanced details like `crossSourceMatches` and `referenceProbability`.

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 (indicated by context), the description does not need to explain return values. It covers input parameters, usage context, behavioral traits, and references related tools. The tool's complexity is fully addressed.

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

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

The input schema already provides 100% description coverage for all three parameters (fiat, slug, source). The description does not add significant new meaning beyond restating the schema details, such as listing venues and default fiat. Therefore, 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 it retrieves full detail for one prediction-market event by venue and slug. It distinguishes from the sibling `pm_quote` by specifying 'This is the cross-venue research view; for tradability use 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?

Explicit usage guidance is provided: it's the research view, use `pm_quote` for tradability. Also notes it's free and requires no API key, clearly indicating when to use this tool over others.

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 beyond annotations: free public search, no API key required, returns specific data fields, and research-only warning. 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?

Two well-structured sentences, first front-loading purpose and scope, second adding output details and usage guidance. No waste.

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

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

Given 7 optional parameters and output schema, description covers purpose, scope, output, and trade guidance. Complete for a search tool.

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

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

Schema coverage is 100%, so baseline 3 is appropriate. Description lists return fields but adds no extra detail on parameters beyond 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 tool searches prediction-market events across all seven venues, with specific verb+resource and explicit differentiation from sibling discover_pm_markets.

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 when to use (broader search) and when not (for trading, use discover_pm_markets + pm_quote), and notes research-only purpose.

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 this is a safe read operation. The description adds valuable behavioral context: volume is on each venue's own basis, monetary totals cover only real-money venues, and the data is self-computed aggregates requiring attribution. It also provides a methodology URL for deeper detail. 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 a single, well-structured paragraph that front-loads the core purpose (statistics overview) and lists metrics and venues. Each sentence adds essential information without redundancy. The methodology link and citation note are efficiently included. No wasted words.

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

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

For a read-only aggregate statistics tool, the description covers key aspects: data type, scope, attribution, and technical notes (volume basis, real-money vs play-money). The presence of an output schema (not shown in the input) reduces the need to describe return values. A minor gap is that it does not explicitly mention the 'fiat' parameter's effect, but the schema covers that. Overall, sufficiently complete for an overview 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 a single optional parameter 'fiat' with a description. Schema coverage is 100%, so the description is not required to add parameter details. The description does not mention this parameter or clarify its interaction with the data (e.g., which currencies are supported), but it implicitly relates to monetary totals. The description adds no new parameter-specific 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 it provides free public cross-venue prediction-market statistics, enumerating specific metrics (total/open/closed market counts, volume, liquidity) and seven named venues. This distinguishes it from sibling tools like pm_data_event (which likely focuses on a single event) and pm_data_whales (which likely tracks large trades). The purpose is specific and 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 notes that the tool is free, public, and requires no API key, which guides usage for simple queries. It also mentions the need to cite CoinRithm when quoting statistics. However, it does not explicitly contrast with sibling tools (e.g., when to use pm_data_overview vs pm_data_event), so it lacks explicit alternatives 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 annotations already mark it as read-only, open-world, and non-destructive. The description adds value by explaining data attribution (Polymarket vs. Kalshi), the threshold (roughly $1k+ notional), and the disclaimer that it is information, not a recommendation. It fails to mention rate limits or whether updates occur in real-time.

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—three sentences that front-load core functionality (what, scope, ordering, fields) and include necessary caveats. No superfluous language.

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

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

Given the tool has no parameters and an output schema likely exists, the description sufficiently covers the tool's behavior: scope (top 50, $1k+), ordering, fields, data sources, and authentication needs. It manages expectations with a disclaimer, making it complete for a simple data-retrieval tool.

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

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

The tool has no parameters, and the schema coverage is 100% (empty schema). The description compensates by detailing the output structure (fields and ordering), fulfilling the need for parameter semantics entirely.

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

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

The title and description clearly state the tool's function: retrieving the latest large prediction-market trades. The description specifies the data included (side, outcome, USD value, price, market question, event) and the scope ($1k+ notional, newest first, top 50), distinguishing it from sibling tools like pm_data_events.

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

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

The description notes that no API key is required and that it is a free public tape, indicating ease of use. It sets expectations by describing the data source (Polymarket wallet-attributed, Kalshi anonymized). However, it does not explicitly state when to use this tool versus alternatives like pm_data_events or when not to use it.

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

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

Adds significant detail beyond annotations: paper trading, virtual funds, execution cost model, rehearsal cost. No contradiction with annotations (readOnlyHint=true, destructiveHint=false).

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

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

Front-loaded with purpose, then detailed but necessary information. Slightly verbose due to execution model details, but each sentence adds value. A bit long but 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?

Comprehensive for a 6-param tool with output schema: covers usage, constraints, side behavior, paper trading details, execution cost. Output schema exists, so return values not needed.

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

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

Adds meaning beyond schema: side explanation (NO fills at 100 minus probability), stakeMusd minimum (10), and agentTrace as optional private metadata. Schema coverage is 100%, making this extra 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?

The description clearly states 'Read-only PM quote for a binary outcome' and lists specific outputs, distinguishing it from sibling tools like spot_quote and futures_quote. It explicitly notes never mutating state.

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

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

Provides clear guidelines: stakeMusd must be > 0, side semantics, paper trading only, virtual funds. Does not explicitly compare to sibling tools but implies use for quoting before 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?

Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false. The description adds significant detail about paper trading: virtual funds, execution costs, taker fees, slippage, and that results are rehearsal costs not exchange guarantees. No contradiction with annotations.

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

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

The description is relatively long but each sentence adds value: core purpose, usage guidance, paper trading details. It is front-loaded with the most critical information. Could be slightly more concise, but still 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 complexity of resolving symbols with disambiguation, and with output schema present, the description covers purpose, usage, behavioral details (paper trading, execution costs), and parameter semantics comprehensively. It leaves no gaps for an agent to misuse this tool.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by clarifying the main parameter 'q' with examples (BTC, bitcoin, Ethereum) and explaining that it accepts symbol, slug, or name. The agentTrace parameter is described as 'Optional private trace metadata stored in the caller's ledger', consistent with 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 'Resolve' and resource 'human symbol/slug/name to coinId', with examples ('BTC', 'ethereum'). It distinguishes from siblings by stating this tool should be used first to get coinId for wallet/quote/order tools, and that UCIDs should not be guessed.

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 'Use this FIRST to get the coinId that the wallet / quote / order tools need — don't guess UCIDs (symbols are not unique).' It provides clear context but does not explicitly state when not to use it or list 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?

The description goes beyond annotations by detailing the side-aware trigger behavior (long vs short), how triggers are fired by a per-minute worker, that close results in full position closure at mark with realized PnL, and paper trading specifics including execution costs. No contradiction with annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true).

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

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

The description is thorough but verbose, containing details about paper fills, execution costs, and disclaimers that could be shortened or moved to a separate section. It is front-loaded with the core purpose, but overall could be more concise.

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

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

Given the tool's complexity (side-aware triggers, paper trading, execution model), the description covers all necessary aspects: parameter behavior, firing mechanism, fill discovery, required scope, and financial disclaimers. The presence of an output schema is noted but not required to be described here.

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

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

With 100% schema description coverage, the description adds significant value by explaining the side-aware behavior (long needs liq < SL < mark < TP; short inverted), the meaning of null and omitted fields, and the overall process. This enriches the schema-provided descriptions.

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

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

The description clearly states the tool's purpose: 'Set or clear resting stop-loss / take-profit triggers on an OPEN mock futures position.' It uses specific verbs ('set', 'clear') and identifies the resource ('futures position'), distinguishing it from siblings like open_futures_position and close_futures_position.

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

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

The description explains when to use the tool, such as on an OPEN position, and provides context like 'paper trading only', 'requires the trade:futures scope', and behavior of parameters (positive sets, null clears, omitted unchanged). It does not explicitly compare to alternatives but the context is sufficient for an AI agent to decide.

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 all relevant behaviors: read-only (consistent with readOnlyHint), paper trading with virtual funds, execution cost details (taker fees, half-spread, slippage), and that price age is informational. It goes well beyond the annotations.

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

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

While the description is lengthy, every sentence provides valuable information. It is front-loaded with the core purpose and then delves into specific behavioral details. Minor redundancy could be trimmed, but overall it is 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?

Given the tool's complexity and the presence of an output schema (implied from context signals), the description is highly complete. It covers all necessary aspects: what the tool returns, how to use parameters correctly, and behavioral constraints. 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 covers 100% of parameters, but the description adds practical meaning: explains coinId as UCID (must use resolve_symbol), side as buy/sell, and quantity > 0. This enhances the schema's formal descriptions with actionable context.

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

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

The description clearly states it provides a read-only spot market quote with execution price, cost, balance, and fill eligibility. It distinguishes itself from related tools like place_spot_order ('quote before placing order') and implicitly from siblings like futures_quote 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 gives explicit guidance: use before place_spot_order, never mutates state, paper trading only, not financial advice. It also warns that coinId is a UCID and advises using resolve_symbol first. However, it does not explicitly state when not to use it (e.g., for futures or PM markets), which would be ideal.

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 includes extensive paper trading details (virtual funds, fees, slippage) that are irrelevant to a read-only identity tool. Annotations (readOnlyHint=true) are correct, but the description confuses the tool's behavior with trading execution.

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 unnecessarily long and includes off-topic paper trading mechanics. While it starts with the core purpose, the extraneous detail harms conciseness.

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

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

A simple tool with one optional parameter; the description should be brief and focused. Instead, it includes irrelevant trading details and doesn't explain how to use the agentTrace parameter, making it incomplete.

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

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

Schema coverage is 100% and the one optional parameter (agentTrace) is well-documented in schema. Description adds no additional parameter information, meeting the baseline.

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

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

The description clearly states it returns identity info (userId, keyId, scopes, agentName, agentModel). It distinguishes from sibling tools that focus on trading, ledger, or market data.

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

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

Explicitly says 'Use this first to confirm what the key is allowed to do.' Provides context about paper trading, but doesn't contrast with alternatives like get_agent_ledger.

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