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

With no annotations, the description must carry the behavioral burden. It discloses that the tool returns reserve balances and pool details and is mainnet-only, but it does not describe errors, missing-pool behavior, or any rate-limit/permission considerations.

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 short and front-loads the main purpose and return content. The final tip about `earning_opportunities` is useful but somewhat tangential.

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 two-parameter read tool with full schema coverage and no output schema, the description is nearly complete: it states the purpose, return content, and mainnet availability. A little more detail on missing-pool or error behavior would make it fully complete.

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

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

Schema description coverage is 100%, so both required token parameters are already documented. The description adds the notion of a token pair but does not provide additional syntax, format, or validation details 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 states a specific verb and resource: get liquidity pool information from ALEX DEX, scoped to a token pair. It clearly implies a single-pool lookup rather than a list, but it does not explicitly name the sibling `alex_list_pools` to differentiate the two.

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 looking up a pool by token pair and notes the mainnet-only constraint. However, it does not explicitly say when to use this versus `alex_list_pools`, `alex_get_swap_quote`, or `alex_swap`.

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 behavioral burden. It discloses mainnet-only availability and the expected-output return, but does not state that it is read-only / does not execute a swap, nor does it cover quote expiry, fees, slippage, auth needs, or rate limits.

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

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

The description is compact and front-loaded with the core purpose and return value. The mainnet note earns its place; the earning_opportunities tip is slightly tangential but not disruptive.

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 three-parameter quote tool with no annotations and no output schema, it covers purpose and availability but underspecifies the return structure and quote behavior. Details such as output fields, fees, route, and quote validity are missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds useful meaning beyond the schema by specifying full contract IDs for tokens and giving a concrete example, though amountIn units remain documented only 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?

States a specific verb and resource: 'Get a swap quote from ALEX DEX' and explains it returns the expected output amount for swapping tokenX to tokenY. Clear, but it does not explicitly contrast itself with sibling tools such as alex_swap or other quote tools.

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

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

Mentions mainnet-only availability and implies use before a swap, but never states when to choose this over alex_swap, bitflow_get_quote, or pillar_direct_quote. The earning_opportunities tip is tangential and not usage guidance for this tool.

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

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

No annotations are provided, so the description must carry behavioral disclosure. It usefully states mainnet-only availability and lists return fields, but omits pagination/truncation behavior of limit, whether the listing is exhaustive, auth assumptions, and rate limits.

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

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

The description is front-loaded and mostly economical: purpose, return fields, usage, and mainnet constraint appear in order. The ending tip about earning_opportunities is slightly tangential to pool listing but remains short.

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 one-parameter tool with no output schema, the description covers purpose, returned fields, use case, and mainnet constraint. It still leaves limit/pagination behavior implicit, but the schema already documents the only parameter.

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 is only one parameter, limit, and schema description coverage is 100% with default and max documented. The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.

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

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

States a specific verb and resource: list all available trading pools on ALEX DEX, and clarifies it discovers swap token pairs. It implicitly separates itself from alex_swap by saying to use it before swapping, though it does not explicitly contrast with alex_get_pool_info.

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 this to find which tokens can be swapped before calling alex_swap, and notes ALEX DEX is mainnet-only. It gives a clear positive use case but no exclusions or comparison to alex_get_pool_info or quote 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?

With no annotations, the description carries the full disclosure burden for a mutating, fund-moving operation. It usefully discloses the mainnet-only constraint, but says nothing about whether a wallet must be unlocked, whether the swap is signed and broadcast automatically, that execution is irreversible, how the minAmountOut default of "0" exposes the user to unbounded slippage, or what the response contains. For a swap tool with zero annotation coverage this is a significant gap.

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 lines, front-loaded with the action and the mechanism; nothing is padded. The closing tip pointing at earning_opportunities is off-topic promotion rather than decision-relevant information, which is the only real 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?

For a mutating swap with no annotations and no output schema, the agent still needs to know the execution lifecycle (signing, wallet state, return value, failure modes). The mainnet note and token-format note cover part of that, but the safety-critical default of minAmountOut=0 and the expected response are left entirely to the schema and inference.

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 four parameters (tokenX, tokenY, amountIn, minAmountOut) are already documented, including the smallest-units note and slippage protection. The description only reinforces the contract-ID format for the token fields. No information about a required price-impact or deadline concept is added, 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?

Names a specific verb+resource ('Execute a token swap on ALEX DEX') and identifies the underlying AMM, which distinguishes it from DEX-agnostic siblings like call_contract. It does not, however, reference the sibling quote tool (alex_get_swap_quote) that an agent would normally pair with it, leaving some differentiation to inference among the many other swap tools (bitflow_swap, jingswap_*, stacks_market_*).

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

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

Gives two genuine preconditions: tokens must be full contract IDs, and the tool is mainnet-only. But it never says when to prefer this over bitflow_swap or jingswap flows, nor that a quote should be obtained first. Usage is implied by the pool/DEX mention rather than stated as 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 carries full behavioral burden and mostly delivers: it states read-only, no API key required, that papers are fetched from arXiv, filtered by minimum relevance score, grouped by topic, and returned inline as Markdown. It omits potential latency or failure behavior, but covers the essential non-obvious 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?

The description is front-loaded with the core action, then organizes details into digest structure bullets and a file-writing alternative. Most sentences earn their place, though the trailing earning_opportunities tip is unrelated to the tool's function and slightly dilutes focus.

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 what the agent needs: the input-to-output transformation, the digest structure, that the result is an inline Markdown string, that no file is written, and that no API key is required. Nothing essential for correct invocation is missing.

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 parameters are already well documented in the schema. The description adds only marginal parameter context by mentioning the min_score default and grouping behavior; it does not expand on date, categories, or max_results 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 uses a specific verb ('Compile') and resource ('Markdown digest from recent arXiv papers on LLMs and autonomous agents'), then elaborates the fetch-filter-group-compile pipeline. It is clearly distinguishable from sibling tools like arxiv_search (searching papers) and arxiv_list_digests (listing existing digests).

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 clear context: use this tool to compile an inline digest, and use the arxiv-research skill instead when you need timestamped digest files written to disk. It does not explicitly contrast with arxiv_search, but the inline-vs-file distinction provides concrete alternative 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 are supplied, so the description carries the full load and does so well: it declares 'Read-only', explains it reads the local filesystem of the MCP server host (a non-obvious constraint for remote agents), and clarifies it only lists paths rather than returning digest content. It says nothing about behavior on a missing directory or how many files typically exist, leaving a small gap.

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 core facts are front-loaded and efficient: what it lists, where, ordering, creation mechanism, and the key disambiguation from arxiv_compile_digest. The unrelated closing tip about earning_opportunities is off-topic filler that does not earn 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?

For a one-parameter read-only listing tool with no output schema, the description covers location, ordering, provenance, and the follow-up action ('read recent digests by file path'). Only edge-case behavior (missing directory, empty results, what a listing entry looks like) is unstated.

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 single 'limit' parameter already documents its 1-50 bounds and default of 10. The description adds nothing about the limit parameter (e.g. how it interacts with the newest-first ordering), 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?

States a specific verb and resource ('List recent arXiv digest files') plus the exact location (~/.aibtc/arxiv-research/digests/) and ordering (newest-first). It also names the sibling it is not (arxiv_compile_digest), so an agent can distinguish it without opening either schema.

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 routes the agent away from arxiv_compile_digest for persistence and explains that digests must be created via the skill CLI, which is the key usage decision. It does not state what to do if the directory is empty/missing or when arxiv_search would be the better alternative, so it stops short of full when/when-not 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 the full behavioral burden and does well: it discloses that the tool queries the public arXiv Atom API without an API key, is read-only, applies category boosts, scores papers against relevance signals, and returns counts plus ranked papers. It omits potential rate-limit or pagination behavior, keeping it from a 5.

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 main content is front-loaded and organized with clear paragraphs about purpose, scoring, defaults, and returns. However, the final line advertising earning_opportunities is unrelated promotional content that does not earn its place in a tool definition.

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?

There is no output schema, and the description compensates by explaining the return shape: total paper count, relevant paper count, top papers, and fields such as title, authors, abstract, link, relevance score, and tags. It is nearly complete, though rate limits and API failure behavior are not 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?

Schema description coverage is 100%, so the schema already fully documents min_score, categories, and max_results including defaults and bounds. The description reinforces default categories and category boosts, but it does not add parameter-specific syntax or behavior 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 states a specific verb and resource: fetch recent arXiv papers and score them for LLM/agent relevance. It clearly explains the scoring dimensions and default categories. It does not explicitly distinguish itself from sibling tools such as arxiv_compile_digest or arxiv_list_digests, which prevents a 5.

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?

Usage is implied through the description of relevance scoring and categories, but there is no explicit guidance on when to use this tool versus arxiv_compile_digest, arxiv_list_digests, or other research/news tools. The closing tip about earning_opportunities is unrelated and does not clarify usage.

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

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

With no annotations, the description carries the full disclosure burden: it correctly identifies this as a state-changing withdrawal that returns unfilled escrow (implying partially filled amounts stay filled) and that a wallet must be unlocked. It omits failure modes, whether cancellation is rejected for fully filled bids, and whether an on-chain transaction/fee is involved.

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 operational sentence and the auth prerequisite are front-loaded and free of redundancy. The trailing "Tip" about earning_opportunities is low-value filler but short enough not to obscure the core instruction.

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 one-parameter mutation with no annotations or output schema, the definition covers the action, the escrowed-funds effect, and the wallet prerequisite. Remaining gaps (fee/gas behavior, failure conditions for filled bids) are meaningful but not blocking for correct invocation.

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

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

Schema coverage is 100% and the single `side` enum is documented in-schema with the full yes/bonded vs no/idle semantics, so the description need not repeat it. It adds no extra meaning beyond the schema, which is the baseline-3 case for high coverage.

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

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

States a specific verb and resource ("Withdraw a resting bid") plus the concrete outcome ("get the unfilled escrow back"). It implicitly separates itself from atstake_place_bid/atstake_get_bid, though it never names those siblings explicitly.

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 prerequisite "Requires an unlocked wallet" is stated, and "resting bid" implies an open, unfilled bid is the target. There is no explicit when-not guidance or routing to alternatives like atstake_get_bid to confirm a bid exists; the earning_opportunities tip is promotional rather than routing.

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 and does declare the key traits: this is explicitly read-only and it discloses the authentication requirement (wallet unlock) plus the workaround of supplying an address. It does not cover failure modes, e.g. what happens for a nonexistent bid or an invalid side, which keeps it from a 5.

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 what-it-does and return-contents line is front-loaded and the unlock/address note follows logically. The trailing "Tip: call earning_opportunities" is cross-promotional and does not help an agent invoke this tool correctly, so it dilutes an otherwise tight definition.

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?

No output schema exists, so the description usefully summarizes the returned fields, and the auth/default behavior is covered. For a two-parameter read tool this is nearly complete; only edge-case behavior (invalid side, unknown bidder) is unaddressed.

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 both parameters are already documented, including the side enum mapping and the address default. The description only reinforces the address/unlock nuance and says nothing about `side`, so it sits at the baseline for a fully documented 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?

States a specific verb and resource ("Read a resting bid") and enumerates what the read returns: shares wanted, sBTC escrowed, and the implied price. This distinguishes it cleanly from the mutating siblings atstake_place_bid and atstake_cancel_bid without needing to name them.

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?

Gives concrete invocation context: it defaults to the unlocked wallet, which must be unlocked, and passing an address lets you read anyone without unlocking. It does not name alternative read tools (e.g. atstake_position) or state exclusions, so it falls short of a 5.

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 well: it explains the payout cap (smaller of credit and unpaid amount), claim-order payout behavior, and that unpaid remainder stays on the credit. It also discloses the unlocked-wallet requirement. It could be stronger by mentioning transaction finality or fee behavior, but the core claim semantics are clear.

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 claim action, then adds prerequisites and payout mechanics. It is generally efficient, though the trailing earning_opportunities tip is somewhat tangential. No major structural issues.

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 one-parameter claim tool without annotations or an output schema, the description covers the important behavioral constraints: vault redemption prerequisite, wallet unlock, payout cap, order, and remainder handling. It does not describe the return value or exact failure modes, but an agent has enough context to decide and invoke correctly.

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

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

Schema description coverage is 100%, and the only parameter's enum and meaning are fully documented in the schema. The description does not add meaning about the side parameter beyond the schema. Per the high-coverage baseline, a 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 names a specific verb+resource: claim the sBTC behind a credit earned by a passed proposal after market resolution. It also distinguishes the action from vault redemption by stating that it only works once the vault has been redeemed. An agent can identify the operation without opening the schema.

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 clear prerequisites and a key exclusion: only works once the vault has been redeemed, and requires an unlocked wallet. It also points to earning_opportunities as related discovery. It does not explicitly name alternative sibling tools such as atstake_legion_redeem_vault, so it falls short of a 5.

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 and does well: it discloses permissionless access, the 12-block deadline, expiration behavior, payout composition, gas payment by the caller, and wallet requirement. It does not explicitly cover failure modes such as calling before voting closes, calling after expiration, or calling an already-concluded proposal, but the core behavioral profile is clear.

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 and largely free of waste, with the core action and deadline stated immediately. The final tip about `earning_opportunities` is unrelated to invoking this tool and slightly dilutes 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?

For a complex, state-dependent, mutating tool with no annotations and no output schema, the description is quite complete: it explains timing, payout behavior, caller cost, permissionless access, and wallet prerequisites. It could still be stronger by stating what happens if the proposal is not yet closed or has already been concluded.

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 input schema already explains both parameters, including the side enum. The description adds no additional parameter-level syntax or meaning beyond what the schema provides, making the 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?

The description uses a specific verb and resource: “Settle a proposal and, if it passed, pay the proposer.” This clearly distinguishes the action from sibling tools like atstake_legion_vote or atstake_legion_claim_credit, which do different things.

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

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

It states the exact operational window (“opens the moment voting closes and stays open for 12 blocks”), the consequence of missing it (“EXPIRES, pays nobody, and can never be concluded afterwards”), and that the action is permissionless but necessary. It also gives the prerequisite (“Requires an unlocked wallet”).

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 present, the description carries the burden and does it well: it discloses that the call is non-mutating ('Read-only, no wallet needed') and explains that the returned outcome is a forecast computed over the current tally, not the on-chain result. It stops short of describing failure modes or data freshness beyond the block caveat.

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 what is returned, followed by the forecast caveat, then the read-only note — every core sentence earns its place. The trailing 'Tip' pointing at earning_opportunities is unrelated to retrieving a proposal and mildly dilutes focus.

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?

No output schema exists, and the description compensates by naming the fields returned and explaining how the predicted outcome is derived. That is enough to call it correctly; only edge cases such as an unknown proposal_id are left unaddressed.

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

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

Schema description coverage is 100%, and the enum for `side` is already explained in the schema. The description mentions tally and phase but adds nothing about how `side` or `proposal_id` behave, so the 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?

States a specific verb+resource ('One proposal in full') and enumerates exactly what comes back: claim, link, tally, phase, and predicted outcome. That distinguishes it immediately from the sibling atstake_legion_list_proposals, which lists proposals rather than resolving one.

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?

Gives clear situational context: use this before concluding to decide 'whether a conclude is worth the gas', and notes it is read-only with no wallet needed. It doesn't explicitly contrast against atstake_legion_list_proposals or atstake_legion_status, so the routing is implied rather than stated.

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 must carry the whole load — and it does state read-only and no wallet needed. It also discloses that data comes from the aggregated site render rather than the chain, which usefully implies possible staleness relative to the chain-direct sibling, and flags it as the cheap option. Missing pagination/result-size behavior keeps it at 4.

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?

Purpose is front-loaded in the first clause, followed by the sibling comparison and the safety note — good ordering. The trailing tip to call earning_opportunities is unrelated to listing proposals and is dead weight for an agent deciding whether to call this tool.

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

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

With no output schema and no annotations, the description still tells the agent what comes back (tallies, rationales, member roll, live status), that it is a safe read requiring no wallet, and where to go for finer-grained data. That is enough to invoke it correctly.

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

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

Schema coverage is 100%, so the two parameters are already documented and the baseline is 3. The description only obliquely gestures at the side filter via 'both legions' and never explains the ambiguous enum values (bonded/idle) or the phase values, so it adds little 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?

States a specific verb and resource (list every proposal in both legions) and immediately scopes what the payload contains: tallies, rationales, member roll. It explicitly contrasts itself with the sibling atstake_legion_get_proposal, so an agent can pick between them without reading schemas.

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?

Clear routing guidance: use this for the whole-board overview, use atstake_legion_get_proposal for per-proposal detail and the conclude forecast. That names the alternative and the condition that selects it. It doesn't mention when the side/phase filters should be used to narrow instead, which keeps it off a 5.

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 and does so: it discloses the payout (3,000 shares of your own side), the state constraints (one live proposal at a time plus cooldown and legion-wide interval), the balance requirement that legion_conclude re-reads, the consequence of selling out before conclusion (forfeited payout), ASCII-only inputs, and the unlocked-wallet requirement. It also spells out the acceptance criterion for the link — it must be public and reproducible, which is what a no vote is for.

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 purpose, then payout, then link discipline, then constraints — a sensible order. It is a touch padded: the sentence justifying the mechanism ('it pays people for checking Bitcoin and PoX-5...') is motivational rather than operational, and the trailing `earning_opportunities` tip is a cross-sell unrelated to proposing.

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 four-parameter mutation tool with no annotations and no output schema, coverage is strong on prerequisites, constraints, and consequences. The remaining gap is what the call returns — an agent is not told whether it gets a proposal identifier it would need for atstake_legion_get_proposal or atstake_legion_vote.

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 real meaning on top by telling the proposer that the link must actually support the claim, and that point-in-time evidence should be declared as such in the description rather than implied as a standing truth. The ASCII-only note duplicates schema text, and 'all three fields' is slightly loose against four parameters, but the semantic guidance on evidence quality is genuine added value.

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

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

States a specific verb and resource ('Open a proposal in a legion') and then defines what a proposal actually is — a claim about the market's subject, backed by a public link, voted on by other holders of your side. This is far beyond restating the name and lets an agent distinguish it from atstake_legion_vote, atstake_legion_list_proposals, and atstake_legion_conclude.

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?

Gives concrete preconditions and rate constraints: minimum share balance, unlocked wallet, one live proposal per proposer, a per-proposer cooldown, and a legion-wide interval between proposals. It never explicitly names a sibling (e.g. 'use atstake_legion_list_proposals to check existing proposals first' or 'use atstake_legion_vote to vote on others'), so it stops short of 5, but the when-to-use 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?

With no annotations, the description carries the full burden and delivers: it explains the state change (shares redeem at 1 sat into the credits pot, or are recorded as worthless if the side lost), that it pays the caller nothing, that it is permissionless and once-only, and the exact timing condition.

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 key action and scope are front-loaded in sentence one, and the wagering of preconditions follows logically. The lost-side sentence ('which is still the call that has to happen before anyone learns their credit pays zero') is a touch verbose for the value it adds.

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 no-annotation, no-output-schema mutation tool, the description covers effect, timing, cost, wallet requirement, and both win/lose outcomes. Nothing an agent needs to decide whether and how to call it is missing.

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 single enum parameter already documents all four values, so the schema does the explanatory work. The description contributes no additional detail about how 'side' selects the vault beyond the name-level notion of 'the legion's side'.

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 first sentence gives a concrete verb+resource: 'Turn a winning legion's leftover shares into sBTC.' The scoping ('legion's leftover shares', vault conversion) distinguishes it from per-user tools like atstake_redeem, though no sibling is named explicitly.

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?

Preconditions are spelled out: permissionless, once-only, callable only after the market resolves and all live proposals have settled, requires an unlocked wallet. It stops short of explicitly naming the alternative tool for individual (non-legion) redemption, so the agent must infer the boundary.

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 burden and discloses key behaviors: it is read-only, defaults to the unlocked wallet (which requires unlocking), and an address can be passed to read anyone without unlocking. It also explains that voting weight is the live share balance and that below the minimum you cannot propose or vote. It does not detail the exact return shape, but overall transparency is strong.

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-loads the core purpose, then layers in the weight gate, read-only behavior, wallet handling, and a helpful tip. Every sentence contributes to understanding; there is no filler.

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 key concepts an agent needs: weight, vault, rules, gates, and eligibility constraints. It does not list exact return fields, but for a status-check tool this is largely sufficient.

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

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

Schema coverage is 100%, so baseline is 3. The description adds useful meaning beyond the schema: it clarifies that weight is the share balance on the chosen side, read live from the market, and that passing an address avoids the need to unlock a wallet.

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?

States a specific verb and resource: reports where a legion stands and your eligibility to act, including weight, vault, rules, and gates. It does not explicitly differentiate from sibling status tools like atstake_market_status or legion_status, but the purpose is clear enough for an agent to understand what it returns.

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

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

Provides clear context for when to use it: checking your standing and whether you can propose or vote. It also points to atstake_mint_complete_set for buying weight if below minimum, but does not explicitly state when to use other status siblings instead.

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

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

With no annotations, the description carries the full burden and does: it discloses permanence and publicity of the rationale, one-vote-per-address, no self-voting, block-delayed voting window, and required preconditions (minimum share balance, unlocked wallet). It also warns there is no veto path, which is a non-obvious behavioral constraint.

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 core action and the no-veto rule are front-loaded and every paragraph carries substantive information. The closing tip promoting `earning_opportunities` is tangential to voting and is the one piece that doesn't directly earn 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?

Covers prerequisites, timing, vote semantics, and rationale expectations for a 4-parameter mutation tool with no output schema. The remaining gap is the unspecified `side`/`support` interaction and no indication of what the call returns once submitted.

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 all four parameters are already documented, establishing a baseline of 3. The description adds the notion of vote weighting by share balance, but it never clarifies the relationship between the `side` enum (yes/no/bonded/idle — which legion) and `support` (boolean up/down), which is the most ambiguity-prone part of 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?

States a specific verb (vote), resource (proposal), and the two components of the vote (share balance as weight, written rationale). It separates itself cleanly from siblings like atstake_legion_propose and atstake_legion_conclude by describing the voting act itself.

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 frames when to vote no: "There is no veto here: voting no while the window is open is the only way to stop a proposal," plus concrete criteria (unsupported link, standing truth from point-in-time evidence). Also states eligibility constraints (proposer cannot self-vote, one vote per address, window opens two blocks after propose), which is exactly the when/when-not guidance an agent needs.

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 and does so well: it explicitly states the tool is read-only and needs no wallet, and explains the market's settlement behavior, including that YES requires a Bitcoin SPV proof and NO can be triggered by resolve-idle after close. This gives an agent strong behavioral context beyond a bare label.

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 remains readable through its market-mechanics explanation. The final tip about earning_opportunities is mildly extraneous for this tool, but the overall structure is clear and mostly 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?

There is no output schema, no annotations, and no parameters, so the description must supply the missing context. It identifies the status fields returned and explains the market's resolution conditions, giving an agent enough information to call and interpret the result without needing additional structured documentation.

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 takes zero parameters, so the baseline is 4. The description does not need to explain parameter semantics and appropriately focuses on the returned market status instead.

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 states a specific subject and scope: the current status of the El Salvador PoX-5 prediction market, including claim, trading status, escrowed sBTC, and close height. This clearly distinguishes it from sibling tools such as atstake_position, atstake_get_bid, or atstake_resolve_idle, which act on positions, bids, or resolution rather than reading market state.

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

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

The description gives clear context that this is a read-only status check requiring no wallet, which helps an agent know when it is safe and appropriate to call. It does not explicitly name alternatives or state when not to use it, but the purpose is sufficiently clear for selection against 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?

With no annotations, the description carries the behavioral burden well: it discloses the burn of BONDED and IDLE sats, the sBTC return, the market-open constraint, and the unlocked-wallet requirement. It does not cover failure modes such as insufficient matched pairs or whether fees apply, so it falls short of complete transparency.

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

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

The core explanation is front-loaded and efficient: action, effect, constraint, and alternative appear in the first three sentences. The closing `earning_opportunities` tip is mildly extraneous for correct invocation and slightly dilutes focus.

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 one-parameter mutation with no annotations or output schema, the description covers the essential action, preconditions, limitation, and sibling alternative. It leaves out edge-case behavior such as partial fills, failure handling, or fees, but is otherwise complete enough to call correctly.

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

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

Schema description coverage is 100%, so the schema already documents `sats`. The description adds meaning by clarifying that the same `sats` amount is burned from both BONDED and IDLE and returned as sBTC, which is more than the schema's brief parameter note.

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 states a precise action: hand back a matched pair of shares, burn equal BONDED and IDLE sats, and return sBTC. It clearly distinguishes the operation from `atstake_redeem` by noting that this only works while the market is open. An agent can understand the resource and effect without opening the schema.

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

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

It gives an explicit alternative: after resolve, use `atstake_redeem`. It also states the precondition that the market must be open and the wallet must be unlocked, and clarifies that only the hedged part can be unwound, not the directional part.

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 and does so well: it discloses that this spends real sBTC, meters against the wallet's sats rail, requires an unlocked wallet, leaves the caller flat, and is reversible only before market resolution. These are exactly the behavioral traits an agent needs for a financial mutation.

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 definition is front-loaded with the core action and then layers the no-side-taking clarification, alternative routing, voting-weight use case, and operational requirements. Despite being longer than a minimal description, each sentence adds decision-relevant information for an agent.

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

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

For a one-parameter financial transaction with no annotations and no output schema, the description covers the important invocation and risk context: spend, auth, reversibility, purpose, and alternative tools. It could say more about the expected response or post-resolution irreversibility, but it is nearly complete for correct tool selection.

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 has 100% description coverage for the single sats parameter, including the fact that it mints shares of EACH side and has a 1,000 legion minimum. The description reinforces the per-sat share mechanics and minimum but adds no format or edge-case detail beyond the schema, so the 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 states a specific verb and resource: spend sBTC to mint a matched BONDED/IDLE pair. It also explicitly distinguishes the action from taking a directional view, making it easy to separate from sibling tools like atstake_place_bid.

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

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

It gives explicit when-to-use guidance: use this to stay hedged or to buy legion voting weight, and use atstake_place_bid instead when taking a directional view. It also names atstake_merge_complete_set as the reversal path before market resolution.

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 and does so well: it discloses that bids at or above par are rejected outright, that escrow is locked until a counterparty matches, that a match requires both sides to cover one sat per share, and that funds return in full via atstake_cancel_bid. It also flags the cost rail (wallet's sats balance) and the wallet-state prerequisite.

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?

It is front-loaded with the core action, then layers mechanics, constraints, and the cancellation path in short paragraphs that each carry information. The closing tip to call earning_opportunities is a promotional aside that does not help an agent invoke this tool correctly, which costs it the top score.

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 3-parameter mutation tool with no annotations and no output schema, the description covers the essentials an agent needs: prerequisites, failure mode (at/above par), lock semantics, and recovery via cancel. It does not say what the call returns or whether a bid can be modified rather than cancelled, leaving a small gap.

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 explains `side`, `amount`, and `total_sats` including the must-be-less-than-amount rule. The description reinforces the pricing formula (total_sats/amount, must be under 1) with economic reasoning, but adds little about the four enum values or units beyond what the schema states. 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 first sentence names a specific verb and resource — escrow sBTC into a resting bid for one side — and adds the defining scope constraint (below par). It is clearly differentiable from the other market tools in the sibling list (stacks_market_buy_yes/no, atstake_mint_complete_set) because it describes a resting escrowed order rather than an immediate purchase.

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

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

It gives concrete operating conditions: one resting bid per side at a time, requires an unlocked wallet, spends real sBTC. It also names the escape hatch (atstake_cancel_bid) and a related discovery tool. It stops short of explicitly stating when to prefer this over the immediate-buy siblings, so the alternative-selection guidance is implied rather than spelled out.

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 behavioral burden well: it explicitly says read-only and explains the unlock requirement for the default wallet versus address-based reads. It does not cover error behavior or rate limits, but discloses the key operational traits for a read 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?

The purpose is front-loaded, followed by useful interpretation guidance and then auth behavior. The explanation of flat book versus directional position is somewhat detailed for a one-parameter read tool, but it earns its place by clarifying the returned data.

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?

There is no output schema, so the description appropriately explains what the balances mean and how to interpret idle versus bonded balances. It is complete enough to call correctly, though it could say more about the outcome values or response shape.

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 single address parameter is already documented in the schema as defaulting to the unlocked wallet. The description reinforces that default and adds the useful nuance that a supplied address avoids unlocking, but adds no syntax or format detail 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 share balances and their value under each outcome, making the resource and result clear. It does not explicitly differentiate itself from sibling atstake tools such as atstake_get_bid or atstake_market_status, so a 4 rather than 5.

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

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

It gives concrete usage guidance: defaults to the unlocked wallet, which requires an unlocked wallet, while passing an address reads anyone without unlocking. It does not explain when to prefer this over sibling position-related tools, but the auth and parameter 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?

With no annotations, the description carries the full burden and does well: it discloses the payout rule, that BOTH sides are burned, that the burn is total and one-shot, and that an unlocked wallet is required. It doesn't cover failure modes such as redeeming an already-burned position or fee costs, so it stops short of a 5.

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 payout mechanics and preconditions are front-loaded and each sentence carries real information, including the useful idempotency warning. The trailing 'Tip: call earning_opportunities' is cross-promotional and does not help an agent decide how to invoke this tool, which costs it the top score.

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 zero-parameter mutation tool with no annotations and no output schema, the description supplies what matters: what the call does economically, when it is legal, what state it destroys, and the wallet prerequisite. Only fee/error behavior is left underspecified.

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 takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. The description adds nothing parameter-related, which is appropriate here since nothing exists to document.

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 names a specific verb ('Cash a resolved position') and resource, then defines the exact payoff mechanics: winning side 1 sat per share, losing side zero, both burned. This separates it clearly from sibling tools like atstake_merge_complete_set and atstake_position.

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

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

It states the hard precondition ('Only callable after the market resolves') and warns that a second call is pointless because the position is fully burned. It falls short of naming an alternative path for unresolved markets (e.g., merge or transfer a complete set), which would have made it a 5.

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 at all, the description carries the full burden and does so: permissionless, pays the caller nothing, costs gas, moves no assets, requires an unlocked wallet, and blocks downstream payouts/redemptions until status changes. That is exactly the economic and authorization context an agent needs before invoking a state-changing call.

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 action and its precondition are front-loaded, and the cost/asset-movement/authorization facts are delivered in short, scannable sentences. The trailing 'Tip' promoting earning_opportunities is tangential to calling this tool and is the one sentence that does not fully earn 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?

For a zero-param state-changing tool with no annotations and no output schema, the description covers precondition, caller cost, asset effects, wallet requirement, and downstream consequence. It stops short of saying what happens on failure (already resolved, height not reached) or what the caller can observe afterwards.

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 takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The description does not need to compensate for any schema gap here.

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?

It states a concrete verb and object ('Settle the market NO') plus the triggering condition ('once the close height has passed'), and explains the outcome ('the idle side wins'). It refers to being 'half of the market's settlement' but never names the counterpart tool or contrasts itself explicitly against siblings like atstake_redeem, so the differentiation is inferential rather than stated.

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?

Clear preconditions: the close height must have passed and the coins must have failed to enter a bond before the deadline. It also clarifies why someone must call it ('nobody is paid until the status moves off open'), which is real usage guidance. It does not name an explicit alternative tool for the other settlement path or state what to do if the market is already resolved.

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, and it does disclose the two things that matter most: read-only and no wallet needed. It also hints at content (addresses, scripts, indices) but says nothing about freshness (live chain read vs cached), completeness, or response shape.

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 core content is front-loaded and the second paragraph earns its place as a trust/verification rationale. The trailing 'Tip: call earning_opportunities' is an unrelated upsell that dilutes focus and gives the agent a misleading next-step pointer.

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 zero-param, no-output-schema tool, the description must convey the return shape, and it does only at a high level. Terms like 'PoX-5', 'legion', and 'YES proof' are assumed-knowledge, leaving an unfamiliar agent guessing about what fields actually come back.

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?

Zero parameters, so there is nothing to document; baseline 4 applies. The description correctly implies no inputs are needed ('read-only, no wallet needed').

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

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

The description names a specific resource set: twenty El Salvador reserve addresses, their output scripts, and PoX-5 reward cycle indices. That is far more concrete than a restatement of the name. It lacks an explicit verb ('returns'/'lists') and leans on opaque domain jargon ('legion', 'YES proof'), which keeps it from a 5.

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

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

It implies when to use it ('anyone arguing either side in a legion should be reading these on Bitcoin directly'), which is contextual guidance rather than an explicit trigger. No sibling is differentiated -- atstake_market_status and atstake_position are near neighbours, and the only tool named is earning_opportunities, which is an unrelated cross-sell.

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 and does so: it discloses that transfers are free but value-destroying, that voting weight moves with the balance, that shares are map entries so no fungible-token post-condition can guard the call, that the market must be trading, and that an unlocked wallet is required. This is an unusually complete risk profile for an irreversible mutation.

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 action, then layered warnings in descending importance — value loss, then vote implications, then technical caveats. Every sentence earns its place except the trailing 'Tip: call earning_opportunities', which is a tangential cross-sell unrelated to executing a transfer.

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 3-required-param mutation with no annotations and no output schema, the description covers the failure modes (market closed, wallet locked), the irreversibility/non-guardability of the call, and the economic side effects. Nothing an agent needs before invoking it is missing.

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 both the side enum and recipient semantics are already documented, which sets the baseline at 3. The description adds meaning beyond the schema by explaining that 'amount' also moves legion voting weight ('sending 1,000 bonded shares hands the recipient a vote'), which directly informs how an agent should size the call.

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?

States a specific verb and resource ('Send shares of one side to another principal') and immediately scopes it against the sibling operations by warning 'Do not use this to take a side.' An agent can distinguish this from atstake_mint_complete_set, atstake_merge_complete_set, and the buy/sell tools without opening a schema.

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?

Gives explicit preconditions ('Only works while the market trades') and an explicit exclusion ('Do not use this to take a side'), which is strong when-to-use guidance. It does not name the specific sibling tool to use instead for taking a side, so the routing is implied rather than spelled out.

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 disclosure burden, and it delivers real operational facts: no API key needed, public-endpoint rate limit of 500 req/min, and mainnet-only availability. It still omits whether cancellation is irreversible, what happens to escrowed funds, and what the response looks like.

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 core cancellation semantics are front-loaded well, but the closing 'Tip: call earning_opportunities...' is an unrelated cross-sell that does not help an agent invoke this tool and dilutes focus.

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 one-parameter cancel operation with no output schema and no annotations, the description covers network, auth, and rate-limit context. However, it leaves the agent without return-value or failure-mode expectations, which matters for a mutation 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% and the sole parameter (orderId) is documented in the schema as 'The order ID to cancel.' The description adds no syntax or format guidance beyond that, so the 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?

States a specific verb (cancel) and resource (Bitflow Keeper order), and adds scope: 'Cancels a pending order before execution.' This makes it easy to distinguish from bitflow_create_order and bitflow_get_order without opening any schema.

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 phrase 'before execution' implies that the tool is used on pending orders, but it never says what to do when the order is already executed, missing, or when you should first call bitflow_get_order to confirm status. There are no explicit exclusions or named 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?

With no annotations, the description carries the full burden and does disclose key traits: the order is pending and executed later by an external Keeper service, no API key is needed, and there is a 500 req/min rate limit plus mainnet-only availability. It stops short of stating who signs/broadcasts, what fees are involved, or how the resulting order is tracked.

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?

Purpose is front-loaded in the first sentence, and the operational notes are short and scannable. The 'earning_opportunities' tip is tangential to invoking this tool and slightly dilutes focus, though it costs only one line.

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 six-parameter write operation with a nested object and no output schema, the definition covers environment and rate limits but omits what the call returns (presumably an order identifier) and how to follow up via bitflow_get_order or bitflow_cancel_order. An agent can call it, but cannot complete the create-then-track loop from this description alone.

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 all six parameters including the nested fundingTokens map are already documented in the schema; that sets the baseline at 3. The description adds no parameter-level meaning, notably no explanation of actionType values or how minReceivedAmount interacts with autoAdjust.

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?

States a specific verb and resource ('Create an automated swap order via Bitflow Keeper') and clarifies it produces a pending order rather than executing a swap immediately. However, it never names bitflow_swap or bitflow_get_quote as the alternatives, so the distinction from the direct-swap sibling must be inferred.

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 phrase 'pending order that will be executed by the Keeper service' implies when to use this (asynchronous/automated execution versus a direct swap), and 'Bitflow is only available on mainnet' is a real constraint. But there is no explicit when-to-use/when-not guidance relative to bitflow_swap, and the trailing tip about earning_opportunities is unrelated to selecting this tool.

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

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

With no annotations, the description does carry real operational context: public endpoints, ~500 req/min, no API key, mainnet only. However, for a tool that can CREATE an on-chain construct, it says nothing about what creation does (funding, ownership, reversibility, whether it is idempotent) or what authorization is needed.

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 purpose followed by short scoped notes; each sentence adds a distinct constraint. The closing 'Tip' promoting earning_opportunities is marginally tangential but brief.

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?

No output schema exists, so the description should clarify what is returned in each mode (created contract vs existing contract), and it does not. Rate-limit and network constraints are covered, but the mutation semantics for the 'create' path remain a gap.

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 single stacksAddress parameter is fully documented there, including the wallet fallback, so the baseline of 3 applies. The description adds no additional parameter meaning.

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

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

States a concrete verb+resource ('Get or create a Bitflow Keeper contract') and explains the resource's purpose (scheduled/automated token swaps). It distinguishes itself from quote/swap siblings, but the dual get-or-create behavior and the near-named sibling bitflow_get_keeper_user are not distinguished.

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?

Usage is implied through 'automated swaps' and the mainnet-only note, plus a pointer to earning_opportunities. It never says when to use this versus bitflow_get_keeper_user, bitflow_create_order, or bitflow_swap, and it doesn't say when creation occurs versus retrieval.

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 the burden and does reasonably well: it discloses the auth model (public endpoints, no API key), a rate limit (500 req/min), and a network constraint (mainnet only). It does not explicitly state the read-only/non-mutating nature or the failure mode when no address is supplied, keeping it below 5.

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 core is front-loaded and readable, but the opening line largely restates the tool name before the second sentence elaborates, and the closing 'Tip' about earning_opportunities is promotional and not needed to invoke this tool correctly.

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 one-optional-param read tool with no output schema and no annotations, the description covers the essentials an agent needs: auth model, rate limit, network availability, and what data is returned (contracts and order history). Return-format detail would be nice but is not required to call it correctly.

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

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

Schema coverage is 100% and the single optional param already documents 'uses wallet if not specified', so the schema does the heavy lifting. The description adds no syntax, format, or default semantics for stacksAddress beyond what the schema states; 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 states a specific verb and resource ('Get Bitflow Keeper user info and orders') and elaborates with 'Retrieves user's keeper contracts and order history', which lets an agent distinguish it from bitflow_get_order (single order) and bitflow_get_keeper_contract. It stops short of explicitly naming those siblings as alternatives, so a 5 isn't warranted.

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

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

It supplies contextual gating ('Bitflow is only available on mainnet', no API key needed) that is genuinely useful, but never states when to call this versus the closely related bitflow_get_keeper_contract, bitflow_get_order, or bitflow_cancel_order. The trailing 'earning_opportunities' tip is a cross-sell rather than guidance for this tool.

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

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

With no annotations, the description carries the full burden and does add genuinely useful operational context: no API key needed, public endpoints with a 500 req/min rate limit, and mainnet-only availability. It stops short of describing error behavior (e.g., unknown order ID) or the shape of the returned details, which would have earned a 5.

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?

Purpose is front-loaded in the first sentence, followed by a clarifying restatement and then operational constraints. The closing earning_opportunities tip is tangential to fetching an order and slightly dilutes focus, keeping it from a 5.

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 one-parameter read tool with no output schema, the description covers the essentials an agent needs: what it returns conceptually (status and details), that no auth is required, rate limits, and network availability. The remaining gap is the absence of any hint about the returned fields or order states, but the tool's simplicity keeps this close to complete.

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

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

Schema description coverage is 100% and the single orderId parameter is already documented in the schema as "The order ID to retrieve." The description adds no syntax, format, or sourcing guidance for the ID beyond what the schema provides, so the 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 gives a specific verb and resource ("Get details of a Bitflow Keeper order") and reinforces it with "status and details of a specific order." It is clearly distinguishable from mutating siblings like bitflow_create_order and bitflow_cancel_order, though it does not explicitly distinguish itself from bitflow_get_keeper_user, which likely lists a user's 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?

Usage is implied by the single required orderId — you call it when you already have an order ID and need its status. There is no explicit when-not-to-use guidance and no pointer to the alternative sibling (bitflow_get_keeper_user) for listing orders; the only tip redirects to an unrelated earning_opportunities tool.

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

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

With no annotations, the description carries the full burden and delivers real operational facts: no API key needed, public endpoints at 500 req/min, and mainnet-only availability. It stops short of stating that the call is read-only/side-effect free or what happens on thin liquidity, but the rate limit and network restriction are exactly the kind of context an agent needs.

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 core two sentences are front-loaded and efficient, but the trailing 'Tip' promoting earning_opportunities is filler that does not help an agent decide or invoke this swap-quote tool. Roughly a third of the text is off-topic.

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?

No output schema exists, so the description correctly covers the return ('expected output amount and best route'), plus auth, rate limits, and network availability. Only the read-only/stateless nature and failure modes are unstated, which keeps it just short of complete.

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

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

Schema description coverage is 100% and all four parameters (including the human/base amountUnit enum) are documented in the schema, so the baseline of 3 applies. The description adds no parameter-level detail such as token ID format or amount handling beyond what the schema already gives.

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?

States a specific verb and resource ('Get a swap quote from Bitflow DEX') and describes the return ('expected output amount and best route'). It does not distinguish it from close siblings such as bitflow_get_routes, bitflow_get_swap_targets, or alex_get_swap_quote, so an agent must guess which quote source or route helper to pick.

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?

Usage is only implied: a quote naturally precedes bitflow_swap, but the description never says to call bitflow_swap to execute or when to prefer a different quote provider. The closing tip points at earning_opportunities, which is unrelated to selecting or invoking this tool and adds no routing 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 carries the full burden, and it delivers several genuinely useful traits: no API key needed, public endpoints with a 500 req/min rate limit, and mainnet-only availability. It omits whether results are ordered by best output, whether fees/gas are included per route, and the response shape.

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 core purpose is front-loaded in the first sentence, followed by tightly packed constraints (multi-hop, no key, rate limit, mainnet). The trailing 'Tip' about earning_opportunities is off-topic filler for a routing tool, which is the only 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?

For a simple two-parameter read tool this covers access constraints and network scope, which is most of what matters. However, with no output schema the description should say what a 'route' contains (hops, pool, expected output, fee) and whether results are ranked, since an agent planning a swap needs that to act on the result.

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 both parameters already carry examples ('token-stx', 'token-aeusdc'). The description only restates the directionality ('from tokenX to tokenY'), adding essentially nothing beyond what the schema documents, so the 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 names a specific verb and resource ('Get all possible swap routes between two tokens on Bitflow') and clarifies scope by stating that multi-hop routes through intermediate tokens are included. That distinguishes it in spirit from single-quote tools like bitflow_get_quote, but it never names a sibling, so an agent must infer the boundary itself.

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?

There is no explicit when-to-use or when-not-to-use guidance and no reference to the obvious alternatives (bitflow_get_quote, bitflow_get_swap_targets, bitflow_swap, alex_get_swap_quote). The closing 'Tip: call earning_opportunities' is an unrelated cross-sell, not routing advice, so the agent gets no help deciding between route discovery and quoting.

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 the behavioral disclosure burden and does well by noting no API key is required, a public endpoint rate limit of 500 req/min, and mainnet-only availability. It does not describe error behavior or detailed response shape, but the key operational constraints are stated.

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

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

The description is front-loaded with the core operation and immediately follows with what is returned. The operational notes are useful, though the final cross-reference to earning_opportunities is somewhat tangential for this tool.

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

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

For a simple one-parameter read tool with full schema coverage and no output schema, the description supplies enough context: what it returns, public-endpoint access, rate limit, and mainnet restriction. An agent can invoke it correctly without additional information.

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

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

Schema description coverage is 100%, and the single tokenId parameter is documented in the schema as a contract address. The description repeats the input-token idea but adds no syntax, validation, or format detail beyond what the schema already provides, so the baseline of 3 is appropriate.

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

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

The description gives a specific verb and resource: get possible swap target tokens for a given input token on Bitflow. It clearly distinguishes the tool from generic token listing or route/quote tools by framing the output as tokens receivable when swapping from the specified token.

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?

Usage is implied by the purpose: call it when you need to know which tokens can be received for a given input token. However, it does not explicitly say when not to use it or name alternatives such as bitflow_get_routes or bitflow_get_quote.

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

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

With no annotations, the description carries the full burden and does disclose two useful operational facts: authentication is not needed and the endpoint only exists on mainnet. It says nothing about response size ("all trading pairs" could be large), rate limits, or pagination, which matter for a broad-market snapshot call.

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 core action in the first sentence, then return fields, then the auth/mainnet caveats. Four short labeled lines, no filler. The closing tip is marginally tangential to invoking this specific tool but is cheap enough not to be a real cost.

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?

There is no output schema or annotation coverage, so the description is the only source of shape information; it names the fields returned but not the structure or scale of the response, and it doesn't explain what changing the filters does to the result set. Adequate to call safely, but not complete for an agent planning downstream parsing.

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 both optional filters (baseCurrency, targetCurrency) are documented with contract-ID semantics in the schema. The description never mentions them, so it adds nothing about filtering behavior — e.g., whether omitting both returns the full pair list versus a default pair. 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?

States a specific verb+resource ("Get market ticker data from Bitflow DEX") and names the payload fields (price, volume, liquidity) across all trading pairs. It does not explicitly contrast itself with close siblings like bitflow_get_tokens, bitflow_get_quote, or bitflow_get_routes, so the agent must infer that this is the broad snapshot rather than a per-pair 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?

Gives real prerequisites — no API key required and mainnet-only availability — which genuinely helps an agent avoid calling it in the wrong environment. However, it offers no when-to-use guidance against alternatives; the tip to call `earning_opportunities` is a follow-on suggestion, not a routing rule versus bitflow_get_quote or bitflow_get_tokens.

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 and adds useful operational context: no API key required, public endpoints with a 500 req/min limit, and mainnet-only availability. It does not explicitly describe safety or error behavior, but 'Get' and 'Returns the list' make the read-only nature clear.

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 definition is short and front-loads the core purpose. The second sentence partly restates the first, and the closing tip about earning_opportunities is useful but not essential to invoking this tool.

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

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

For a simple zero-parameter list-retrieval tool, it covers the main constraints: mainnet-only, no API key, rate limit, and that it returns a token list. Without an output schema, it could say more about the token object fields, but the description is largely complete for selecting and invoking 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?

The tool has zero parameters, so there are no parameter semantics to document. The baseline for zero-param tools is 4, and the description adds no misleading parameter guidance.

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?

States a specific verb and resource: 'Get all available tokens for swapping on Bitflow' and clarifies the return is a token list on Bitflow DEX. It is clear, but does not explicitly distinguish itself from related siblings such as bitflow_get_swap_targets or bitflow_get_ticker.

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 intended use is implied by 'available tokens for swapping,' and it notes mainnet-only availability. However, it does not say when to use this instead of sibling token/swap discovery tools, nor does it provide explicit 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?

With no annotations, the description carries the burden well: it discloses the public-endpoint rate limit (500 req/min), no-API-key access, wallet unlock requirement, mainnet-only restriction, and (via the schema's confirmHighImpact param) that >5% price impact needs opt-in. It does not state that this is an on-chain state-changing transaction with fees or what happens if slippage is exceeded, which keeps it out of the top score.

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 action, then mechanism, then constraints — each line carries distinct information. The closing 'Tip' is marginally promotional but still routes the agent to a useful next call, so it 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?

For a mutation tool with no annotations and no output schema, the description covers prerequisites, network availability, rate limits, and route behavior. The gap is the return value — it never says whether the call returns a tx ID, quote, or receipt, which matters when no output schema 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 description coverage is 100%, so baseline 3 applies. The description only restates the tokenX/tokenY roles in prose and adds no meaning about amountUnit, fee presets, or slippage semantics beyond what the schema already documents.

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 and resource ('Execute a token swap on Bitflow DEX') and then narrows the mechanism ('aggregated liquidity', 'best route across all Bitflow pools'). An agent can separate this from sibling quote/discovery tools like bitflow_get_quote or bitflow_get_routes and from alex_swap by the named DEX.

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?

Prerequisites are stated explicitly: unlocked wallet, sufficient token balance, mainnet only, and a pointer to earning_opportunities. However, it never says when to prefer this over alex_swap or when to run bitflow_get_quote first, so the alternative-routing guidance stops short of the top band.

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 zero annotations, the description carries the full burden and does so: it discloses the auth requirement, the irreversible consequence of inaction (bounty flips to 'abandoned'), the required BIP-322 signature and the exact signed payload. It also explains the downstream payment block. Nothing material about the mutation's side effects is left silent.

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 action and the authorization rule, then mechanism and deadline in a logical order. The closing tip about earning_opportunities is a promotional non-sequitur that does not help the agent call this tool and slightly dilutes focus.

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 authorization, side effects, deadlines, and signing format despite having no annotations and no output schema. It doesn't state what acceptance itself returns, though the pointer to bounty_get's payment block implies it; a brief note on the response would close the last gap.

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 both parameters are already documented there, so baseline 3 applies. The description echoes both IDs via the signing message template but adds no new semantics on how to obtain or format a submission_id.

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?

Specific verb ('Pick a winning submission') plus a precisely scoped resource ('for a bounty'), which cleanly separates it from bounty_submit, bounty_paid, and bounty_cancel. An agent knows exactly what operation this performs without opening the schema.

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

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

Explicitly states the authorization precondition ('Only the bounty's poster can call this') and the mandatory follow-up flow ('The poster has 7 days after acceptedAt to prove payment with bounty_paid'), naming the sibling tool that completes the sequence. This is a full when-to-use/when-not-to-use statement.

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 burden, and it does disclose real behavioral context: authorization requirement (poster only), state gating, and the exact BIP-322 signing payload. It omits what happens to escrowed funds after cancellation and whether the action is reversible, which matters for a destructive mutation with no destructiveHint.

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 action, then constraints, then the signing format — good ordering. The trailing 'Tip: call earning_opportunities...' is tangential promotional content that does not help invoke this tool, though it costs only one sentence.

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 single-parameter mutation with no annotations and no output schema, the description covers the essentials an agent needs: permission, allowed states, and the signature it must produce. Missing only post-cancellation effects (funds, response shape), which the absence of an output schema makes more noticeable.

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 the single parameter, so the schema already explains bounty_id. The description's signing-message template ({bountyId}) echoes the parameter without adding format rules beyond what the schema supplies; 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?

States a specific verb and resource ('Cancel a bounty') with unambiguous scope. The name/description pair needs no inference to know this destroys a bounty rather than creating or accepting one.

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?

Gives explicit preconditions: only the poster may call it, and only while status is 'open' or 'judging', clarified parenthetically as 'before any submission has been accepted'. It does not name an alternative action (e.g. bounty_accept) or say what to do if the preconditions fail, so it stops short of a full when/when-not routing.

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 behavioral burden and does well: it discloses the L2+ requirement, the exact BIP-322 signing payload, and the post-expiry acceptance/payment windows. It still does not clarify whether reward funds are escrowed or when they are deducted, which is important for a financial mutation 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?

The description is front-loaded with purpose and prerequisite, then presents fields and signing details in a compact structured list. It is somewhat long, but nearly every sentence supports correct invocation, especially the signing string and expiry semantics.

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 complex mutation tool with no annotations or output schema, the description covers authentication, field semantics, signing, and bounty lifecycle well. It could be stronger by explaining what happens to funds on creation and what the response contains, but it is sufficient to call the tool correctly.

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

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

Schema coverage is already 100%, but the description adds meaningful semantics beyond the schema: markdown is allowed in description, expires_at governs new submissions while acceptance can continue afterward, and tags are optional. It also explains the exact signing serialization of all parameters.

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

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

The first sentence names a specific verb and resource: post a new bounty on aibtc.com. It clearly distinguishes creation from the many bounty siblings such as bounty_list, bounty_get, bounty_submit, and bounty_accept.

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

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

The description states a concrete prerequisite: Genesis-level (L2+) registration is required. It does not explicitly name alternatives or when-not-to-use conditions, but the create-versus-list/submit/accept split is clear from the tool name and sibling set.

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 does substantial work: it states no authentication is required and explains the returned bounty record, first-page submissions, conditional winner block, and conditional payment hint. It does not cover error behavior or rate limits, but it provides strong behavioral context for a read 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?

The description is front-loaded and uses a clear bullet structure for return details. The closing earning_opportunities tip is somewhat extraneous to calling bounty_get, but the main content is efficient.

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

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

Since there is no output schema, the description appropriately explains the key returned fields and conditional blocks, and it notes that no authentication is required. It is nearly complete, but it could clarify pagination for the 'first page of submissions' or what happens when the bounty is not found.

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

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

Schema description coverage is 100%, and the only parameter, bounty_id, is already described in the schema as 'Bounty ID'. The description adds no additional meaning such as ID format or where to obtain the bounty ID, so baseline 3 is appropriate.

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

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

The description clearly states the specific action and resource: get full detail for a single bounty. The word 'single' helps distinguish it from bounty_list and bounty_submissions, though it does not explicitly name those sibling alternatives.

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?

Usage is implied by 'single bounty' detail, but the description does not explicitly say when to use this versus bounty_list, bounty_submissions, or other bounty tools. The earning_opportunities tip is promotional and does not guide selection among 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?

With no annotations, the description carries the full burden and does disclose meaningful traits: no authentication required, a server-computed 'status' field derived from timestamps, the max page size of 100, and that the default view silently excludes terminal states. It omits return-field inventory, sort order, and any error/rate-limit behavior, which keeps it below a 5.

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 action and endpoint, then a scannable filter list with defaults inline. Mostly every line earns its place; the trailing earning_opportunities tip and repeated limit max are 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?

For a read-only list endpoint with a fully documented schema and no output schema, the description covers auth, filters, defaults, pagination caps, and the derived status field — enough to call it correctly. What each record actually contains beyond 'status' is left unstated, which is the one realistic gap.

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

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

Schema description coverage is 100%, so the schema already documents every parameter, including the status enum and the limit maximum. The description's filter bullets largely restate the schema, adding only the gloss that "active" means non-terminal states — useful but marginal, 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?

States a specific verb + resource ("List bounties on aibtc.com/api/bounties") and enumerates the filter surface, so an agent knows exactly what it retrieves. It stops short of naming the sibling it differs from (bounty_get for a single bounty, bounty_my_posted / bounty_my_submissions for self-scoped lists), so differentiation is inferable rather than explicit.

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?

Usage is implied through filter semantics and the important default (status defaults to "active", i.e. non-terminal states only), which is real guidance for calling it correctly. However, it never says when to prefer this over bounty_my_posted, bounty_my_submissions, bounty_get, or taskmarket_search, and the earning_opportunities tip is an adjacent upsell rather than an alternative for the same task.

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 and does so: it discloses the 50-result cap, the default non-terminal filter, the meaning of what's surfaced ('open for submissions', 'judging', 'needs winner accepted or payment proven'), the parallel-fetch + createdAt-desc sorting behavior of include_terminal, and that no authentication is required. That is substantially more than the schema states.

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 default behavior, then the alternative modes — a logical order with short paragraphs. The closing 'Tip: call earning_opportunities' is tangential cross-promotion that doesn't help an agent invoke this tool.

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

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

No output schema exists, and the description compensates by describing result volume (up to 50) and sort order, and by characterizing the state categories returned. It stops short of describing the per-bounty fields an agent would receive, but the behavioral picture is otherwise sufficient to call it correctly.

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

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

Schema coverage is 100%, so baseline is 3; the description goes further by explaining why 'active' is the default and what each terminal status selection is for, plus the parallel merge semantics of include_terminal. It doesn't enumerate the enum values itself, deferring to the schema, which is a reasonable division.

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 first sentence names a specific verb and resource ('List bounties posted by a BTC address') and clarifies the default address source. This clearly distinguishes it from sibling tools like bounty_list (all bounties), bounty_submissions, and bounty_my_submissions (as a submitter).

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?

Gives clear default behavior (active, non-terminal, up to 50) and explicit conditions for alternatives: pass status='paid'/'cancelled'/'abandoned' for terminal states, or include_terminal=true for a combined view. It doesn't name the sibling tools an agent could use instead (e.g. bounty_list for a global feed), so it stops just short of full routing 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 carries the full burden and does well: it discloses 'No authentication required', a default result cap of 50, the default non-terminal filter, and that include_terminal triggers parallel fetches merged into one view. It leaves open what happens when more than 50 records exist (truncation vs. pagination), which is the main unresolved behavior for a list 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?

Front-loads what is returned and to whom, then layers defaults, alternatives, and auth requirements in short paragraphs. The closing 'Tip: call earning_opportunities…' is unrelated cross-promotion that does not help an agent decide how to call this tool and dilutes an otherwise tight definition.

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 3-optional-param, read-only list tool with no output schema, the description covers query defaults, return fields (derived status, acceptedSubmissionId, paidTxid), and auth. Only the truncation/pagination semantics of the 50-record cap and the full record shape remain unspecified.

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, but the description adds real meaning: the btc_address default (current wallet's bc1q address), the status default of 'active' non-terminal, and the fact that include_terminal does parallel fetching and returns a combined view rather than simply relaxing a filter.

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?

States a specific verb and resource plus scope: bounties a given BTC address has *submitted to*, defaulting to the wallet's bc1q address. That is implicitly distinct from bounty_list (all bounties) and bounty_submissions (submissions on a bounty), but it never names those siblings, so an agent must infer the split.

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?

Gives a clear next-step routing rule ('Use bounty_get on any row to see whether your specific submission was the one accepted') and explains the default view (50 active, non-terminal) versus include_terminal=true. No explicit when-not-to-use guidance against bounty_submissions or bounty_my_posted, which is the only gap.

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 the full burden and does so unusually well: it spells out every server-side verification rule on Hiro (tx anchored, sBTC contract call, sender = poster, recipient = winner STX address, amount >= rewardSats, byte-exact memo, tx time > acceptedAt - 60s), the anti-replay rule that a txid cannot pay two bounties, and the exact BIP-322 signing payload. This is behavior an agent could not possibly derive from the schema.

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 critical framing (what it does, who may call it) is front-loaded, and the numbered prerequisite sequence scans well. The closing 'Tip: call earning_opportunities to see how to put your assets to work' is unrelated promotional boilerplate that does not belong in a payment-proof tool description, which costs it the top score.

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 no annotations and no output schema, the description supplies prerequisites, verification criteria, and signing details — enough for an agent to invoke correctly. The remaining gap is outcome reporting: it never says what a successful call returns (a receipt, a status change on the bounty) or what happens when verification fails, which matters more given there is no output schema to fall back on.

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 both parameters are already documented, and by baseline this would be a 3. The description earns above baseline by adding constraints not in the schema: the txid must be a confirmed/anchored transfer, and the transfer must carry the literal memo 'BNTY:{bountyId}' with matching recipient and amount — these are semantic requirements the parameter definitions do not state.

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 opening sentence names the exact action (prove payment), the resource (a bounty), and the required evidence (a confirmed sBTC transfer txid), plus the authorization scope 'Poster only.' It is clearly distinguishable from siblings like bounty_accept, bounty_submit, or bounty_get, which do not record payment proof.

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

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

It gives an explicit ordered preflight checklist (read the payment hint from bounty_get, send sBTC via transfer_token with the exact memo, wait for confirmation via get_transaction_status, then submit) and names the tools to use at each step. The 'Poster only' restriction and the memo format 'BNTY:{bountyId}' are stated as hard conditions, not inferences.

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 the full burden and does deliver valuable facts: the listing is paginated, the underlying data is public, and no authentication is needed. It stops short of describing ordering, result payload, or rate limits, but the access and pagination profile is more than most read tools state.

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 first line and the access notes are front-loaded and tight, but the 'Tip: call earning_opportunities...' sentence is unrelated to listing submissions and reads as promotion rather than guidance, diluting an otherwise efficient description.

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

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

For a three-parameter, read-only list tool with no output schema and fully documented parameters, the description covers scope, access requirements, and pagination. It leaves result contents and ordering unspecified, a minor gap given the schema richness.

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 bounty_id, limit, and offset are already documented in the schema. The description only adds that the bounty scope is a 'single bounty', which is implicit in the schema anyway, so baseline 3 is appropriate.

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

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

The description opens with a specific verb and resource, 'Paginated list of submissions', and scopes it to 'a single bounty'. An agent can distinguish it from bounty_my_submissions by the 'for a single bounty' scope, though the description never names that sibling, so differentiation relies on the reader comparing names.

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

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

It states the data is public and that no authentication is required, which is useful context for deciding to call it. However, it gives no explicit when-to-use/when-not framing against alternatives such as bounty_my_submissions or taskmarket_submissions, and the closing 'Tip' promotes an unrelated tool rather than guiding selection.

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