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

Discloses critical behavior: collateral is adjusted automatically (extra funds sent or refunded) when value changes. No annotations are provided, so the description fully covers the behavioral traits.

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, well-structured sentences. Front-loaded with the core action, then efficiency benefit, then constraint, then collateral behavior. 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 output schema and 5 parameters, the description covers all essential information: purpose, constraints, parameter details, and behavioral side effects. An agent can correctly invoke the tool.

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

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

All parameters are already described in the schema, but the description adds contextual details like microunits for price/quantity and default slippage, enhancing understanding beyond the schema.

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

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

The description clearly states the tool edits an unfilled order in-place, specifying the modifiable fields (price, quantity, slippage). It distinguishes itself from the alternative cancel+recreate approach, 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 it is faster and cheaper than cancel+recreate, and that it only works on orders with zero filled quantity. Provides clear context for when to use this tool versus 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 discloses key behavioral traits: it refunds USDC/tokens and approximately 0.957 ALGO collateral. Since no annotations are provided, the description carries the full burden, and it does so adequately. It does not, however, detail any potential side effects or irreversibility beyond the refund.

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 two sentences, no filler, and the main purpose is front-loaded. Every sentence adds 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?

For a tool with three parameters, no nested objects, no output schema, and a straightforward action (cancel), the description fully covers what the agent needs: what it does, what parameters are required, and what the result is (refunds). It is complete in context.

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

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

With 100% schema description coverage, the schema already documents each parameter. The description adds value by explaining the source of escrowAppId and clarifying orderOwner as the Algorand address that created the order, going beyond the schema's generic 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 'Cancel an open order' with specific verb and resource. It provides necessary details like parameter sources and refund behavior. However, it does not explicitly distinguish from sibling tools such as 'amend_order' or 'claim', which handle related order actions.

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 on required parameters (escrowAppId, orderOwner) and where to obtain them (from create_limit_order or get_open_orders for escrowAppId). It does not mention when not to use this tool or provide alternatives, which would improve the score.

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

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

The description discloses key behavioral traits: winning tokens redeem at 1:1 USDC, losing tokens are burned. This is critical beyond the schema, as it informs the agent of the financial impact. No contradictions with annotations (none provided). It could further mention irreversibility or fee implications, but the provided info is substantial.

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

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

The description is extremely concise: two sentences front-loaded with the primary action, followed by outcome details. Every sentence adds value, with 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?

For a simple claim tool with no output schema, the description covers the essential context: resolved market, outcome token redemption, and outcome consequences. It is complete enough for an agent to understand the tool's function, though it could explicitly mention the prerequisite of owning outcome tokens.

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 adds no new parameter information. The description does not elaborate on parameters beyond what the schema already provides (e.g., amount is in microunits, assetId is the outcome token ASA ID). Thus, it meets the baseline but does not exceed it.

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

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

The description clearly states the verb 'Claim', the resource 'USDC', and the method 'by redeeming outcome tokens'. It also distinguishes the tool from siblings (e.g., merge_shares, split_shares) by specifying the context of a resolved market and the outcome of winning vs losing tokens.

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

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

The description explicitly states when to use the tool: 'from a resolved market'. It implies that the user must hold outcome tokens to redeem, providing clear context. However, it lacks explicit when-not-to-use or alternative tools for related operations (e.g., splitting or merging shares before claiming).

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 collateral lock amount (~0.957 ALGO, refundable), return value (escrowAppId), and suggests saving it for cancel_order. This provides essential behavioral context beyond a simple 'place order' statement, especially given no 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 tightly written sentences: purpose, unit explanation with collateral info, and return value instruction. No fluff, front-loaded with key 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?

Covers all 5 parameters (via schema), explains units, collateral, and return value. No output schema exists, but description tells the agent what to expect. Minor gaps: no mention of balance requirements or order lifecycle post-placement.

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 concrete examples for price and quantity (e.g., '500000 = $0.50'), clarifying the microunits concept beyond the schema descriptions. While 100% schema coverage provides baseline, the examples significantly enhance understanding.

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

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

Clearly states the action ('Place'), the resource ('limit order on a prediction market'), and includes specific details about units and return value. This distinguishes it from sibling tools like create_market_order or cancel_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?

The description implies use for limit orders that require collateral and can be cancelled, but does not explicitly compare to alternatives like market orders or provide when-not-to-use scenarios.

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 no annotations, the description adds valuable behavioral context: collateral lock (~0.957 ALGO) and return fields (escrowAppId, matched quantity, fill price). However, it omits fee behavior, partial fill handling, and error conditions.

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 with the purpose front-loaded. No redundant information—every sentence provides unique value (purpose, units/behavior, return values).

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 return values (escrowAppId, matched quantity, fill price) in the absence of an output schema, and mentions collateral lock. However, it lacks details on what escrowAppId is used for, potential partial fills, or what happens if no counterparty exists.

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 descriptions cover 100% of parameters, but the description adds concrete unit examples (e.g., 500000 = $0.50) that clarify the microunit format, going beyond the schema's minimal 'Price in microunits'.

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: place a market order with auto-matching. It distinguishes from sibling tool 'create_limit_order' by using the verb 'place' and specifying 'market order' with auto-matching.

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 immediate execution via 'auto-matching' but does not explicitly state when to use this tool over alternatives like 'create_limit_order'. No when-not or exclusions are provided.

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

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

The description fully discloses the tool's behavior: it returns a guide with specified content. No annotations are provided, but the description sufficiently conveys it is a read-only informational tool.

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

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

Two concise sentences with no redundancy; front-loaded with the main purpose and followed by usage advice.

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

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

Despite lacking output schema, the description specifies what the guide covers (data model, units, orderbook mechanics, workflows, pitfalls), making the return value clear and complete for the tool's purpose.

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

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

Tool has zero parameters, so baseline score of 4 applies. No parameter documentation 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?

Description clearly states 'Returns the Alpha Arcade agent guide' with specific topics, distinguishing it clearly from sibling tools which are all action-oriented (amend, cancel, order, etc.).

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

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

Explicitly advises 'Read this before interacting with prediction markets,' providing clear contextual 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?

No annotations provided, so description carries full burden. Discloses requirement for ALPHA_API_KEY, clarifies input format (UUID vs marketAppId), and mentions return shape (same as websocket orderbook_changed.orderbook). Adds behavioral context beyond schema, though could additionally state that it is a read-only operation.

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?

Four short, clear sentences front-loaded with purpose, followed by key constraints (API key, input type, output shape). No redundant or irrelevant information; every sentence earns its place.

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

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

Tool is simple with 1 parameter and no output schema. Description adequately covers purpose, auth, input clarification, and return shape. Missing details on error handling or rate limits, but for a low-complexity tool, this is reasonably complete.

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

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

Only one parameter, marketId, with full schema coverage (100% described). Description adds crucial clarification that input is the Alpha market ID (UUID) and not marketAppId, which adds meaning beyond the schema description. Baseline 3 upgraded due to 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?

Describes fetching a full processed orderbook snapshot from the Alpha REST API for a market. Clearly distinguishes input (Alpha market ID UUID) from marketAppId, which differentiates it from sibling tools that might use the latter. Verb 'Fetch' combined with resource 'full processed orderbook snapshot' is specific.

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?

Implies usage for fetching a static snapshot, but does not explicitly state when to use this tool versus alternatives like get_orderbook or stream_orderbook. No direct exclusions or comparison to 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?

No annotations are provided, so the description carries the full burden. It discloses the return format (summary fields, prices in dollars) and the special structure for multi-choice markets, adding value beyond a simple fetch statement.

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

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

The description is concise with only three sentences. It front-loads the primary purpose and then adds essential details without waste. Every sentence earns its place.

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

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

Given no output schema and no parameters, the description is largely sufficient. It covers the return fields and highlights the multi-choice market nuance. The reference to an external 'agent-guide' resource is a minor gap, but overall complete.

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

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

The input schema has zero parameters, so no parameter description is needed. The baseline score is 4, and the description does not need to compensate for any missing parameter details.

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 ('Fetch all live markets') and lists the returned fields (id, title, marketAppId, prices, volume), distinguishing it from sibling tools like get_market (single market) and stream_live_markets (streaming).

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 a specific usage hint for multi-choice markets (use options[].marketAppId for trading), but does not explicitly state when to use this tool versus alternatives 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?

No annotations are provided, so the description carries full burden. It mentions the return includes options for multi-choice markets, but does not state whether the tool is read-only, requires authentication, or has rate limits. Some behavioral detail is provided but not comprehensive.

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 purpose, no redundant words. Efficiently communicates the primary function and return 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?

For a simple fetch tool with one parameter and no output schema, the description adequately covers purpose, return value, and ID types. Could mention read-only nature or authentication, but overall sufficient given the tool's simplicity.

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

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

The single parameter marketId has 100% schema description coverage, and the description repeats the ID format already in the schema. The description adds no new parameter semantics beyond what the schema provides, earning 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 fetches full details for a single market by ID, with specific verb 'Fetch' and resource 'market'. It distinguishes from siblings like get_live_markets by specifying 'single market' and notes ID type differences.

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 (fetch single market details) but does not explicitly mention when not to use or compare with alternatives like stream_market or get_full_orderbook. No exclusion criteria or alternative tool names are provided.

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

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

With no annotations, the description partially discloses authentication behavior (walletAddress or ALPHA_MNEMONIC) but does not mention other traits like read-only nature, return format, or error handling.

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 two sentences with no unnecessary words. It front-loads the key purpose and adds a critical usage constraint 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 no output schema and no annotations, the description covers core functionality and a key requirement but lacks details on return format, error cases, or behavior when no orders exist.

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

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

Schema coverage is 100%, and the description adds value by clarifying the relationship between walletAddress and ALPHA_MNEMONIC environment variable, which is not evident from the schema alone.

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

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

The description clearly states the verb 'Fetch', the resource 'all open orders', and the scope 'for a wallet on a specific market'. This distinguishes it from sibling tools like get_orderbook or get_positions.

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

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

The description provides a usage requirement (must provide walletAddress or set ALPHA_MNEMONIC) but does not explain when to use this tool over siblings like amend_order, cancel_order, or get_orderbook.

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 no annotations, the description carries the full burden of behavioral disclosure. It explains the merging transformation (NO bids become YES asks, etc.), sorting order, and that it includes spread calculation. This provides good insight into what the tool does beyond just fetching 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 two sentences long, front-loads the purpose, and packs significant detail (merging logic, sorting, spread) without any wasted words. Every sentence adds value.

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

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

Given no output schema, the description explains the structure of the orderbook (merged, sorted, includes spread) adequately. However, it does not mention if there are limits on the number of orders returned or pagination, which might be needed for completeness. Overall, it covers the key aspects.

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

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

The only parameter, 'marketAppId', is fully described in the schema as 'The market app ID (number)'. The description does not add additional meaning beyond what the schema already provides, so it meets the baseline for high schema coverage.

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

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

The description clearly states the tool fetches the on-chain orderbook as a unified YES-perspective view, explicitly contrasting with a standard orderbook by describing the merging of all four sides. This distinguishes it from sibling tools like 'get_full_orderbook' which presumably returns the raw orderbook.

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

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

The description implies usage when a YES-perspective unified orderbook is needed, but it does not provide explicit guidance on when to use this tool versus alternatives like 'get_full_orderbook' or 'stream_orderbook'. No exclusion criteria or context for when not to use it is given.

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

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

No annotations are provided, so the description carries full burden. It describes the action as a fetch, implying a read-only operation. No additional behavioral details (e.g., authentication, rate limits, or data format) are disclosed, but for a simple retrieval tool, the description is adequate.

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 consists of two concise sentences with no extraneous information. It is front-loaded with the purpose, and each sentence adds essential information.

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

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

Given no output schema, the description could be more complete by mentioning the return format. However, for a straightforward fetch tool with a single parameter, the description covers the core functionality and prerequisites adequately.

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

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

The schema describes the walletAddress parameter with 100% coverage. The description adds value by explaining that the parameter is optional if the ALPHA_MNEMONIC environment variable is set, providing context beyond the schema.

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

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

The description uses a specific verb 'Fetch' and identifies the exact resource 'YES/NO token positions for a wallet across all markets'. This clearly distinguishes it from sibling tools like get_open_orders or get_live_markets, which focus on different resources.

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

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

The description explicitly states a prerequisite: 'You must provide walletAddress or set ALPHA_MNEMONIC.' This guides the user on how to invoke the tool. However, it does not explicitly discuss when to use this tool versus alternatives, though the uniqueness of the resource makes it implicit.

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

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

With no annotations, the description should disclose behavioral traits. It mentions API key requirement and return fields, but does not state if it's a read-only operation, rate limits, or other side effects. It's adequate but incomplete.

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 two sentences: the first states the main purpose, and the second adds key details (API key, shape similarity). 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 no output schema, the description covers the return fields, API requirement, and relationship to a sibling tool. It is fairly complete, though could mention if there are any limitations or sorting.

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

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

There are zero parameters, so the baseline is 4. The description does not add parameter information, but none is needed. It correctly notes that no parameters are required.

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 'Fetch' and resource 'reward markets', and specifies it returns markets with liquidity rewards, distinguishing it from sibling `get_live_markets` by noting the same shape but different filtering.

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 API key requirement and notes that it shares shape with `get_live_markets`, providing implicit context for when to use it, but lacks explicit when-not-to-use or alternative selection 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?

With no annotations provided, the description carries full burden. It only states the basic action, but does not disclose behavior for unequal amounts, fees, or whether the operation is destructive (tokens burned), leaving gaps for the agent.

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 with one sentence and a formula, front-loading the core action without any unnecessary text.

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 output schema, the description does not explain return values or prerequisites. It is adequate for a simple operation but lacks completeness for error conditions or required account state.

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 both parameters described. The description adds no further semantic context beyond the schema, so baseline 3 applies.

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 (merge equal YES and NO tokens) and the result (back into USDC with the formula 1 YES + 1 NO = 1 USDC), distinguishing it from siblings like split_shares.

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 usage context is implied by the formula, but there is no explicit guidance on when to use this tool (e.g., closing positions) or when not to (e.g., if amounts are unequal), and no mention of 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?

No annotations are provided, so the description carries the full burden. It does not disclose whether the tool is read-only, destructive, requires authentication, or has side effects like consuming the order or updating balances.

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

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

Two sentences, no fluff, front-loaded purpose. 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?

Despite 4 required params and no output schema or annotations, the description does not explain return values, error cases, or prerequisites beyond get_orderbook. An agent lacks information on what the tool returns upon success.

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 minor context (microunits, get_orderbook) but mostly repeats schema descriptions (e.g., quantityMatched in microunits is already in schema).

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

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

The description clearly states the verb 'propose a match' and the resources involved: an existing maker order and the configured wallet as taker. It distinguishes from sibling tools like amend_order or cancel_order by being specific to matching an existing 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?

The description implies when to use by mentioning how to find the maker parameters via get_orderbook. However, it does not explicitly state when not to use or compare with alternatives like create_market_order.

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?

No annotations exist, so the description carries full burden. It discloses the exact conversion ratio and that the split is equal. This is useful behavioral context beyond what the schema provides (which only lists parameters).

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, zero waste. Front-loaded with action and essential detail. Every sentence earns its place.

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

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

The description is sufficient for a simple split operation with two well-documented parameters. It does not mention return values or prerequisites, but given no output schema and low complexity, minimal gaps exist.

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: it clarifies that 'amount' is in microunits and provides the conversion example (1000000 = $1.00). This exceeds schema descriptions.

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

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

The description uses a specific verb ('Split') and resource ('USDC into equal YES and NO outcome tokens'), clearly distinguishing it from sibling tools like merge_shares. It also provides a concrete conversion rate (1 USDC = 1 YES + 1 NO).

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 the tool is for creating outcome tokens from USDC but does not explicitly state when to use it vs alternatives (e.g., when to split vs merge). No exclusions or context triggers are provided.

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

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

The description discloses that it uses WebSocket, collects events for a specified duration, and returns specific data fields. However, it lacks details about side effects (likely read-only), connection management, resource impact, or error scenarios. Since no annotations are provided, the description carries full burden but is only moderately transparent.

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 two sentences long with no wasted words. The first sentence defines the action, mode, and output, while the second provides a practical use case. Information density is high and 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?

For a simple tool with one optional parameter and no nested objects or enums, the description covers the input (duration) and output (accumulated changes) adequately. It lacks details on WebSocket lifecycle (e.g., how to stop, connection timeout) but is reasonably complete given the low complexity and absence of output schema or 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?

The schema already documents the single parameter 'durationMs' with a description (how long to collect events in ms, default 5000), achieving 100% coverage. The tool description adds no additional semantic information about the parameter beyond what the schema provides, so the 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 collects real-time market probability changes via WebSocket for a duration and returns accumulated data. It specifies what the output includes (market ID, probability patches, spread/midpoint updates) and gives a use case ('seeing which markets are active right now'). However, it does not explicitly distinguish itself from sibling streaming tools like stream_market or stream_orderbook.

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

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

The description implies usage for real-time monitoring (e.g., 'useful for seeing which markets are active right now') but provides no explicit guidance on when not to use it, prerequisites, or alternatives. There are no exclusions or comparisons to other tools.

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

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

Discloses key behavioral traits: WebSocket connection, returns first change event, times out, requires slug. No annotations provided, so description carries full burden. Missing details on error handling or connection lifecycle, but adequate for basic usage.

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 sentence front-loads core functionality and method. Second sentence adds timeout and identifier requirement. Highly efficient.

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

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

Covers all essential aspects for a simple watch tool: action, method, timeout, identifier distinction. Lacks output structure description, which could be inferred. No annotations to supplement. Adequate for the tool's simplicity.

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

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

Schema coverage is 100%, but description adds value by clarifying that slug is the market slug, not the market app ID. Timeout default is noted. Adds meaningful context 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?

Clearly states verb (watch), resource (single market), method (WebSocket), and output (first change event). Explicitly distinguishes the identifier (slug vs app ID) from potential confusion.

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?

Describes the core usage (watch single market via WebSocket) and timeout behavior. Does not explicitly state when not to use or name alternatives, but sibling tool names provide implicit 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?

With no annotations, the description must disclose behaviors. It mentions WebSocket, real-time, speed, and return shape. But it is ambiguous whether the connection streams updates or provides a single snapshot. The tool name 'stream' suggests continuous, but description says 'snapshot'. It does not mention authentication, rate limits, or what happens on timeout. Transparency is adequate but not complete.

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

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

The description is three short sentences, each adding distinct information: purpose, performance comparison, and return shape plus input requirement. No wasted words; front-loaded with the core action.

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

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

For a tool with 2 params and no output schema, this description covers key behavioral aspects (WebSocket, speed, return shape reference) and input semantics. It relies on the user knowing get_full_orderbook's output, but the summary list of fields (bids, asks, spread, YES/NO) provides sufficient context. The ambiguity about streaming vs snapshot keeps it from a 5.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by explaining 'slug' is the URL-friendly market name (not app ID), clarifying its usage. It does not add details for 'timeoutMs' beyond schema. This extra context justifies 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 the tool's purpose: 'Get a real-time orderbook snapshot for a market via WebSocket.' It specifies the return shape and differentiates from the sibling get_full_orderbook by noting same shape but faster via WebSocket. The verb 'Get' and resource 'orderbook snapshot' are 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 provides context for when to use this tool: 'Faster than on-chain reads (~5s vs ~10s)' and states it returns the same data as get_full_orderbook, implying use when speed is needed. It also clarifies the input requirement: 'Requires the market slug...not the market app ID.' However, it does not explicitly exclude alternatives or specify when not to use it, missing a full guide.

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?

No annotations are provided, so the description carries the full burden. It mentions WebSocket, first event, and timeout, but does not explain behavior after timeout (no event? error?), whether it is a one-shot connection, or reconnection handling. Adequate but not thorough.

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 two sentences, front-loaded with the core action, and contains no extraneous words. Every sentence serves a purpose.

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 uses WebSocket and has a timeout, the description does not explain what the return value looks like or what happens on timeout (e.g., error vs null). No output schema exists, so more detail would be helpful. Adequate but 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%, so the baseline is 3. The description adds value by clarifying that walletAddress is required only if ALPHA_MNEMONIC is not set, and notes the default timeout. This provides context beyond the schema.

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

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

The description clearly states the tool watches a wallet for order changes via WebSocket and returns the first change event. It distinguishes from sibling stream tools like stream_market or stream_orderbook by specifying the scope (wallet orders).

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

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

The description specifies the prerequisite: must provide walletAddress or set ALPHA_MNEMONIC. However, it does not explicitly state when to use this tool versus alternatives like stream_market or stream_orderbook, nor does it mention 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.