the-floor

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

Description provides rich behavioral details: explains that flow is split into categories, defines each category (player, trader, routed, liquidity), clarifies that playerSellShare is only for attributable sells, and warns against common mistake of double-counting LP deposits as dumps. This adds value beyond readOnlyHint and openWorldHint annotations.

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

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

Description is concise (4 sentences) and efficiently conveys purpose, categories, and important warnings. No redundant information. Structured well with a hook question followed by explanation.

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?

Description covers the main purpose, categories, and important caveats. However, it does not explain how the output is structured (e.g., single object with fields like playerSellShare, etc.) or how to interpret the numbers. It also does not differentiate from sibling tools like get_distribution. Given the complexity, a bit more clarity on output format would improve completeness.

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

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

Input schema has no parameters, so description does not need to add parameter semantics. It correctly focuses on explaining the output and interpretation, which serves the purpose of parameter semantics indirectly.

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

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

Description clearly states the tool analyzes FLOOR flow into categories (player, trader, routed, liquidity). It uses a question to frame the purpose and specifies the breakdown. This distinguishes it from other tools like get_distribution or get_floor_state which likely have different focuses.

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 does not explicitly state when to use this tool versus alternatives. It provides important caveats about interpretation but lacks direct usage context. The warning about double-counting is useful, but doesn't differentiate from 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?

The description adds significant behavioral context beyond annotations: it warns that drop rate varies, new activations dilute, and token prices move. It states 'FACTS not advice' and notes that passing `id` handles upgrade credit. No contradiction with annotations (readOnlyHint, openWorldHint).

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

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

The description is concise: 3 sentences cover purpose, parameter guidance, and warnings. No fluff, front-loaded with key information.

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

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

Given the tool has only 2 optional params and no output schema, the description comprehensively explains what is returned (fee, share, dividends, payback) and caveats. Perfectly adequate for a read-only analytical tool.

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

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

Schema coverage is 100% with good descriptions for both parameters. The description adds extra context for `id` (handles upgrade credit) and reinforces tier behavior. This exceeds the baseline of 3.

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

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

The description clearly states the tool provides decision math for activating a StonkBroker, including fee, dividend share, estimated dividends, and payback days. It distinguishes from siblings like get_broker (general info) and prepare_activate_broker (actual activation) by focusing on analysis.

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

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

The description explains when to pass `id` (for exact quote) vs omit (for table prices) and warns about variable factors. However, it does not explicitly compare to sibling tools or state when not to use it.

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

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

The description goes beyond annotations (readOnlyHint, openWorldHint) by detailing that the leaderboard is a snapshot, that ownership can change, and that it should be reported as data not as an appraisal. This adds significant behavioral context.

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

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

Two sentences: first sentence states purpose and composition, second provides crucial framing. No wasted words, front-loaded with key information.

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

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

For a read-only tool with one optional parameter and no output schema, the description fully explains what data is returned, its interpretation, and important caveats about ownership and valuation.

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

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

The single parameter 'limit' is fully described in the schema (coverage 100%). The description does not add additional parameter guidance but provides context about the output ranking criteria.

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

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

The description clearly states it returns a leaderboard of activated StonkBrokers ranked by USD value of wallet contents, specifying the assets included and their pricing source. This distinguishes it from sibling tools like get_leaderboard or get_broker.

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

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

The description explains the scope (activated brokers) and provides framing about the snapshot nature and how contents can change. However, it does not explicitly state when to use this tool versus alternatives like get_broker or get_leaderboard.

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

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

Annotations already provide readOnlyHint and openWorldHint, so the description's addition of specific output measures (tier counts, alpha concentration) adds some value. However, it does not disclose other behaviors like data freshness or pagination, which could be relevant.

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

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

The description is a single, well-structured sentence that immediately conveys the tool's purpose. It is concise with no wasted words.

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

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

For a parameterless read-only tool with annotations, the description covers the essential aspects. It could be improved by hinting at the output structure or data source, but it is sufficiently complete for its low complexity.

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

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

There are no parameters, and the schema coverage is 100%. The description does not need to add parameter info, and the baseline score of 3 is appropriate.

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

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

The description clearly specifies the resource (desks and alpha distribution) and the metrics (tier counts, alpha concentration for top 1% and top 10%). It distinguishes from sibling tools like get_behavior or get_leaderboard, which focus on different aspects.

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 implicitly suggests using this tool when a summary of distribution is needed, but does not explicitly state when not to use it or mention alternatives. With many sibling tools, more explicit guidance would help.

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

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

Annotations already indicate readOnlyHint=true and openWorldHint=true. The description adds that the result is 'ranked by alpha' and includes 'unaffiliated free agents,' providing context beyond annotations. It does not contradict annotations.

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

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

The description is a single concise sentence that is front-loaded and contains no unnecessary words. Every part earns its place.

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

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

Given no parameters, no output schema, and annotations that cover safety, the description adequately states what the tool returns. It could be more complete by mentioning the structure (list of objects) but is sufficient for a simple retrieval tool.

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

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

The tool has no parameters, and schema coverage is 100% trivially. Per guidance, baseline is 4 when there are 0 parameters. The description adds no parameter info, which is acceptable.

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

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

The description clearly states that the tool retrieves firms, their members and contributions, plus unaffiliated free agents ranked by alpha, which is a specific verb+resource combination that distinguishes it from sibling tools like get_behavior or get_players.

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 retrieving firm and free agent data but does not explicitly state when to use it versus alternatives nor when not to use it. No comparison to siblings such as get_leaderboard or get_players is provided.

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

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

Annotations already indicate read-only and open-world behavior. Description adds detail on what data is returned without contradicting annotations.

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

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

Single concise sentence listing the data fields followed by an imperative recommendation. Zero wasted words.

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

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

Given zero parameters and no output schema, description fully explains what the tool returns, making it complete for its purpose.

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

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

No parameters, so baseline 4 applies. Description does not need to add parameter information.

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

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

Description clearly states it returns the entire floor state and lists specific data fields. Distinguishes from sibling tools by suggesting it as the starting point for context.

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 'Start here for context' explicitly indicates when to use this tool, but does not provide guidance on when not to use it or suggest alternatives.

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

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

The description adds significant value beyond the readOnlyHint and openWorldHint annotations. It explains that reconstructed rows are marked seeded:true and that absent metrics should be treated as unknown, not zero, which is crucial for correct interpretation of the data.

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

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

The description is two sentences long, front-loading the key purpose in the first sentence and adding important behavioral context in the second. Every word is meaningful, with no redundancy.

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

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

Given the lack of an output schema and the simplicity of the tool (no parameters), the description is fairly complete. It explains what data is returned and how to treat missing values, though it could explicitly mention the output format (e.g., array of objects).

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

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

The tool has no parameters, and the input schema is fully covered. The description does not need to add parameter semantics, and a baseline of 4 is appropriate for zero-parameter tools.

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

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

The description explicitly states the tool provides daily snapshots for trends including price, market cap, burned, supply, players, alpha, and holders. This clearly distinguishes it from sibling tools like get_behavior or get_distribution, which focus on specific entities rather than historical aggregate metrics.

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

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

The description indicates the tool is for historical trend data, which implies its appropriate use case. While it does not explicitly mention when not to use it or name alternatives, the context from sibling tool names (e.g., get_players, get_behavior) makes the purpose clear.

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

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

Annotations provide readOnlyHint and openWorldHint, but the description adds little behavioral context beyond 'top holders by balance'. It does not explain what 'top' means (e.g., count, percentile), nor does it clarify the open world hint implications.

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

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

The description is a single, concise sentence with no unnecessary words. It earns its place by immediately conveying the tool's core function.

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 should explain return format (e.g., list of addresses with balances). It fails to do so, leaving the agent uncertain about the response structure. The openWorldHint is also unexplained.

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

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

No parameters are defined, so the description does not need to add param info. The baseline score of 4 applies per rubric for zero-parameter tools.

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

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

The description clearly states it retrieves top holders by balance, with a specific token $FLOOR. The verb 'get' and resource 'holders' are evident, but the token name $FLOOR is not explained, which could cause slight ambiguity.

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

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

No guidance on when to use this tool versus siblings like 'get_distribution' or 'get_firms'. The description does not mention alternative tools or exclusion criteria, leaving the agent to infer from names.

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

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

Annotations already declare readOnlyHint=true, making the tool's non-destructive nature clear. The description adds context about the return content (rankings and recruiters) and the fixed nature of recruiter assignments, which is beyond what annotations provide.

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

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

The description is two sentences with no filler, front-loading the core purpose and adding a key detail. Every sentence earns its place.

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

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

Given the simplicity of the tool (one optional parameter, no output schema), the description adequately covers the main functionality. However, it lacks details about the response structure (e.g., how limit affects both rankings) and assumes the agent understands 'alpha' and 'referral earned'.

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 'limit', with baseline at 3. The description does not elaborate on the parameter beyond the schema, so no additional semantic meaning is added.

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

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

The description clearly states the tool returns wallets ranked by alpha (earning power) and top recruiters by referral earned, with a specific detail about recruiter fixation. It distinguishes from siblings like get_holders (holders) and get_player (single player) by focusing on rankings.

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 does not provide explicit guidance on when to use this tool versus alternatives like get_behavior or get_distribution. It lacks when-not-to-use conditions or mentions of prerequisites, leaving the agent to infer context.

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

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

Annotations already declare readOnlyHint and openWorldHint. The description only lists action types but does not add behavioral context such as ordering, pagination, or data freshness. It does not explain how 'recent' is determined or whether results are consistent across calls.

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

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

The description is a single sentence listing action types, which is concise. However, it could be more structured by explicitly stating that it returns actions of these types. Slight improvement possible but generally 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?

No output schema exists, yet the description does not explain the return format (fields, ordering, or pagination). Given the tool's simplicity (one optional param), the description should at least mention what properties each action includes. The current description is insufficient for an agent to understand the response structure.

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

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

Schema coverage is 100% for the single parameter 'limit', which has a clear description. The tool description adds no parameter-level information, but schema already documents it well. Baseline score of 3 is appropriate.

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

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

The description clearly states the tool returns recent on-chain game actions and lists specific action types (collect, claim, etc.). The verb 'get' and resource 'live actions' are explicit. However, 'recent' is not defined (time range? count?), which slightly reduces clarity. Among siblings, it is distinct as the only 'get_live_actions' tool.

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

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

No guidance on when to use this tool vs alternatives. The description does not mention prerequisites, frequency of use, or relationship to sibling tools like 'get_history' or 'prepare_*' tools. The agent must infer context from the name alone.

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

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

Adds value beyond annotations by explaining null meaning due to upstream scan failures and referencing partial/unknownFields. readOnlyHint and openWorldHint already present but description enriches them.

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

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

Two efficient sentences: first lists outputs, second clarifies null behavior. No fluff, front-loaded with key information.

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

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

Simple tool with one param and no output schema. Description covers return values, null handling, and refers to partial/unknownFields, making it complete for agent use.

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% (address described), so description doesn't need to add more for the parameter. But it provides no extra parameter-level meaning beyond the schema.

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

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

The description clearly lists the data returned (desk tier, alpha, emissions, etc.) and specifies that fields may be null, distinguishing the tool from siblings like get_behavior or get_holders.

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?

No guidance on when to use this tool over alternatives like get_floor_state or get_leaderboard. The description only explains output nullability, not usage context.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds valuable behavioral context: that outputs are facts and paybacks (not instructions), that halving decay is ignored (best case), and that a desk is required. No contradictions with annotations.

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

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

The description is front-loaded with the core purpose and lists many metrics efficiently. It is longer than strictly necessary but each sentence adds value. Minor redundancy in 'so an agent can reason about its next move' and 'the agent decides' could be tightened.

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

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

Given the complexity of the tool (many output fields) and no output schema, the description provides a comprehensive list of what the tool returns. It covers the key metrics, assumptions, and prerequisites. Slight gap: does not mention the format or how to interpret the data, but the list is sufficient for an agent.

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

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

The input schema has 100% description coverage for the single parameter (address). The description adds the requirement that the wallet must have a desk, but does not substantially enhance the parameter meaning beyond the schema's '0x wallet to analyze'.

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

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

The description explicitly states the tool's purpose: returning decision-relevant math for a wallet. It uses specific verbs ('get strategy') and lists the exact metrics provided (alpha/share, FLOOR earned, pending PnL, etc.). This clearly distinguishes it from sibling tools like get_behavior or get_distribution.

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

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

The description provides clear context: 'so an agent can reason about its next move' and explicitly states that the output is facts, not instructions. It also notes a prerequisite ('Needs the wallet to have a desk') and a caveat (best-case payback). However, it does not explicitly mention when not to use this tool or suggest alternative tools for other use cases.

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?

Description is consistent with readOnlyHint=true annotation, describing a read operation. Adds context about pool thinness and its impact, which annotations do not cover.

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

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

Two sentences, no fluff, front-loaded with critical details. Every clause 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 tool with no parameters and no output schema, the description is highly complete: it lists all returned data (router, WETH, pool, fee, spot price) and includes a practical warning about liquidity.

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

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

Schema has zero parameters, so description does not need to explain them. Baseline is 4 for 0-param tools. Description adds value by detailing the output information.

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

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

Description clearly states it provides everything needed to swap ETH↔FLOOR on Robinhood Chain, listing specific elements like Uniswap V3 router, WETH address, pool, fee tier, and spot price. Distinguishes from sibling tool prepare_swap_eth_for_floor by noting it should be read first.

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

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

Explicitly instructs to read before prepare_swap_eth_for_floor or for constructing/verifying a swap. Also gives a liquidity warning, guiding appropriate use.

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

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

Annotations already indicate readOnlyHint and openWorldHint. Description adds critical behavioral context: ids are zero-based, positional, and an off-by-one error silently buys a different operator. This goes beyond annotations to disclose risk.

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

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

Two efficient sentences: first lists output fields, second provides usage warning. No wasted words, front-loaded with key info.

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

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

Given no parameters and no output schema, description sufficiently explains output and usage context. Could add more detail on field meanings (e.g., alpha, bandwidth), but overall adequate for 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?

No parameters, so baseline is 4. Description focuses entirely on what the tool returns (id, name, cost, alpha, bandwidth), compensating for lack of output schema. No param info needed.

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

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

Description clearly states the tool lists operators with specific fields (id, name, cost, alpha, bandwidth) and explains its role in the recruiting workflow. Distinguishes from siblings by referencing prepare_recruit_operator and warning about id positional nature.

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 'Read this before recruiting', giving clear when-to-use context. Warnings about off-by-one errors provide usage guidance. No explicit alternatives named, but sibling tools indicate alternatives for other actions.

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?

Description discloses that it prepares an unsigned transaction (non-executing), and that approval is for an exact amount by default, not unlimited. Annotations already indicate non-read-only and non-destructive; description adds useful context about the unsigned nature.

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

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

Two sentences, no wasted words. Front-loaded with the primary purpose, followed by key detail about amount. Highly efficient.

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

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

Description is complete for a preparation tool: explains what it does, why needed, key parameter nuance. No output schema exists, so return value may be assumed (unsigned tx). Adequately covers the tool's role among siblings.

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

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

Schema coverage is 100% with both parameters described. Description adds clarification: 'from' is optional and used for reporting current allowance, 'amount' is in whole FLOOR not wei. This adds value beyond the schema.

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

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

Description clearly states the tool builds an unsigned ERC20 approve for the game contract to spend FLOOR, and specifies it's needed before recruiting or upgrading. This distinguishes it from other prepare_ tools like prepare_recruit_operator or prepare_upgrade_desk.

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

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

Explicitly states when to use: 'Needed before recruiting or upgrading.' Provides context that amount is exact by default and can be passed in whole FLOOR. Does not explicitly mention when not to use, but the guidance is clear.

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

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

The description adds behavioral context beyond annotations: it discloses that the tool builds an unsigned transaction, explains the destination of collected floor, and implies a signing requirement. No contradictions with annotations.

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

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

The description is two sentences, front-loaded with the primary purpose, and contains no extraneous information.

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

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

Given the tool has 2 parameters, full schema coverage, and annotations, the description covers essential behavior, though it could mention failure modes or prerequisites like the floor desk existing.

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

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

With 100% schema coverage, the description adds value by relating the 'from' parameter to the signing requirement, though the 'id' parameter is adequately described in the schema.

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

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

The description clearly states the verb (Build), the resource (unsigned transaction for collecting Floor desk's pending PnL), and distinguishes it from siblings like prepare_collect or prepare_broker_floor_desk by specifying the broker wallet and floor desk context.

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

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

The description provides clear guidance on signing ('Sign as the broker's owner') and explains where the collected floor lands, but does not explicitly state when to avoid this tool or compare with 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?

Beyond annotations (readOnlyHint=false, destructiveHint=false), the description details the transaction flow, ETH forwarding, permanent desk binding, and important behavioral traits like signature validity and wallet funding. No contradictions.

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

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

The description is verbose but well-structured, starting with purpose, then mechanics, then implications. Every sentence serves a purpose, though it could be slightly trimmed without losing meaning.

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

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

The description thoroughly explains the operation's behavior but fails to state what the tool explicitly returns (e.g., unsigned transaction format). Given no output schema, this gap reduces completeness.

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

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

Schema coverage is 100%, but the description adds critical nuance: the 'from' parameter must be the broker's current owner, referrer defaults to dashboard, and id range. This significantly enhances parameter understanding.

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

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

The description clearly states the tool's purpose: building an unsigned transaction for a StonkBroker's ERC-6551 wallet to open a desk on The Floor. It specifies the action, resource, and unique cross-game context, distinguishing it from siblings like prepare_create_desk.

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

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

The description provides strong usage context, including the unique cross-game move, the owner requirement, and warnings about desk permanence and not promising wallet tokens. However, it lacks explicit alternatives or when-not-to-use guidance, though the context is clear.

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

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

Annotations indicate readOnlyHint=false and destructiveHint=false, and the description adds that it is free (no FLOOR, no ETH beyond gas) and builds an unsigned transaction. This provides useful cost and behavioral context beyond annotations.

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

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

Two concise sentences that front-load the purpose and add key usage hints without extraneous information. Every sentence adds value.

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

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

For a tool with one optional parameter and no output schema, the description adequately covers purpose, cost, and prerequisite. Could mention the return type (unsigned transaction) for completeness, but not essential.

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 'from', which is adequately described in the schema. The tool description does not add new parameter information, so baseline score of 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?

Description clearly states the tool builds an unsigned transaction to collect pending PnL for a desk, specifying the action and resource. It distinguishes from siblings like prepare_approve_floor or prepare_create_desk, which serve different purposes.

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 a clear prerequisite: 'Use get_player first to see pendingPnL.' While it doesn't explicitly list when not to use or compare to alternatives, the context of sibling tools makes usage clear. Could mention that the transaction needs to be signed and sent separately.

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

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

The description reveals critical behavioral traits beyond annotations: it never sees private keys, never broadcasts, costs 0.01 ETH, and the referrer is immutable after creation. These details exceed the minimal annotation hints.

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

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

Every sentence is essential: purpose, return format, security, cost, referrer details, and user guidance. No waste, and the most critical info (purpose, security, cost) is front-loaded.

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

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

Despite no output schema, the description covers all key aspects: what the tool does, inputs with guidance, return format, critical behavioral traits, and cost. It is complete for an agent to select 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 already describes both parameters (100% coverage). The description adds practical value: explains why 'from' is recommended (prevent revert), and clarifies referrer defaults and zero-address option. This extra context raises the score above baseline 3.

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

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

The description clearly states the tool builds an unsigned transaction to open a desk (join the game). It uses specific verb 'build' and resource 'desk', and the context of sibling tools (many prepare_* actions) helps differentiate it as the creation action.

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

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

The description explains when to use the tool (to open a desk) and provides important context about referrer permanence and the need to inform the user. However, it does not explicitly compare to sibling tools or state when not to use it.

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

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

Discloses behavioral traits beyond annotations: outputs an unsigned transaction, spends FLOOR, requires prior approve, and burns 75% of spent amount. No contradiction with annotations.

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

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

Three sentences, no filler. First sentence defines primary purpose, second explains prerequisite and fallback, third adds detail on tokenomics. Each sentence is necessary.

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, tokenomic impact, and ID source. Without an output schema, it implies the response contains an unsigned transaction and possibly an approveFirst, which is adequate. Minor gap: doesn't state whether operatorId must exist or what happens if invalid.

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

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

Adds meaning beyond schema: 'from' is recommended for allowance check, 'operatorId' is zero-based with explicit mapping to list_operators and example range (0=Retail Analyst ... 14=The Closer). Schema coverage is 100%, but description enriches understanding.

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

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

Clearly states the action: 'Build the UNSIGNED transaction to recruit an operator by id'. Distinguishes from sibling tools like prepare_recruit_starter and prepare_seat_operator by specifying 'recruit an operator' and referencing list_operators for IDs.

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 see list_operators for IDs, notes the need for prior ERC20 approval due to spending FLOOR, and explains that a short allowance triggers an approveFirst transaction. Provides clear when-to-use and other actions needed.

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

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

The description states it builds an UNSIGNED transaction, indicating no immediate execution or side effects. Annotations show readOnlyHint=false (mutation) and destructiveHint=false, though the description does not contradict them. It provides sufficient behavioral context beyond annotations.

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

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

One sentence with no filler. Every word adds value: 'Build' (action), 'UNSIGNED transaction' (behavior), 'recruit the free starter operator' (purpose), 'No FLOOR cost' (distinction).

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

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

For a tool with 1 optional parameter, no output schema, and good annotations, the description covers all essential aspects. It explains what it does, its cost, and its transactional nature. No gaps remain.

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

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

The sole parameter 'from' is described in the schema as 'The wallet that will sign (optional).' The description adds no additional meaning beyond the schema. With 100% schema coverage, baseline 3 is appropriate.

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

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

The description clearly states the tool builds an unsigned transaction to recruit the free starter operator. It distinguishes from siblings like 'prepare_recruit_operator' by mentioning 'free starter operator' and 'No FLOOR cost', which directly addresses purpose and differentiation.

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

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

The description implies when to use the tool: when recruiting the free starter operator. It does not explicitly state exclusions or alternatives, but the sibling tools provide context. Still clear enough for proper use.

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

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

The description reveals that the tool builds an UNSIGNED transaction (not executing it) and mentions limitations (seats/bandwidth). Annotations indicate readOnlyHint=false (write operation) and destructiveHint=false; the description adds the unsigned nature and constraints, providing useful behavioral context beyond annotations.

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

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

A single sentence that front-loads the purpose, includes the key action (seat operator), the resource (FLOOROP NFT token id), and constraints (limited by desk tier). No wasted words.

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

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

The description is largely complete given the tool's complexity and schema coverage. It explains the purpose, input (tokenId), and constraints. However, it does not describe the return value (the unsigned transaction object), which would be helpful since there is no output schema. Still, for a transaction builder tool, the description covers the essentials.

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 both parameters (tokenId: operator NFT token id; from: optional signing wallet). The tool description reinforces the tokenId purpose but adds no new meaning beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool builds an unsigned transaction to seat an operator owned by the user (by FLOOROP NFT token id) at their desk to earn alpha. It distinguishes from sibling tools like prepare_unseat_operator and prepare_recruit_operator by specifying the action and resource.

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

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

The description provides context on when to use (to start earning alpha) and mentions constraints (limited seats/bandwidth by desk tier). However, it does not explicitly state when not to use or mention alternatives like prepare_unseat_operator.

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

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

Annotations indicate readOnlyHint=false and destructiveHint=false, but the description adds critical behavioral details: it spends real money, the pool is thin, and it warns to verify numbers before signing. It also explains how amountOutMinimum is computed (live price minus slippage), providing full transparency beyond annotations.

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

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

The description is two dense sentences with no wasted words. It front-loads the key purpose, then flows naturally into flow steps and warnings. Every sentence earns its place.

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

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

Given 4 parameters, no output schema, and a list of 21 sibling tools, the description fully covers all needed context: purpose, flow, prerequisites, parameter semantics, and safety warnings. It is complete for an AI agent to select and invoke the tool correctly.

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

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

Schema coverage is 100%, but the description adds significant meaning: explains that amountEth must already be held as WETH, that recipient is the signing wallet, that slippagePct defaults to 2 and is used for amountOutMinimum calculation, and that from is optional but triggers allowance check. This enriches the schema information.

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

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

The description clearly states the tool builds an unsigned Uniswap V3 swap to buy FLOOR with WETH (exactInputSingle). It distinguishes from siblings like prepare_wrap_eth and other prepare_* tools by specifying its place in the 3-step buy flow. The verb 'build' and resource 'unsigned swap' are specific and unambiguous.

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

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

The description explicitly outlines the full buy flow (3 signed steps) and prerequisites (must hold WETH via prepare_wrap_eth). It also states when not to use this tool: 'Selling FLOOR for ETH is the reverse and not built here.' This provides clear when-to-use and when-not-to-use guidance.

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

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

The description adds context beyond annotations: it specifies the tool builds an unsigned transaction, implying it does not execute the operation immediately and requires subsequent signing. Annotations already indicate it is not read-only and not destructive, but the description clarifies the non-executing nature.

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 one concise sentence with a parenthetical for clarity. It is front-loaded and contains no wasted words.

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

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

The tool has no output schema, so the description should hint at the return value. It states 'Build the UNSIGNED transaction' but does not describe the output format or that the result needs signing/broadcasting. It explains the effect but lacks return value details.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add additional meaning beyond the schema's parameter descriptions. It mentions 'operator NFT' but that is already in the schema description for tokenId.

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

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

The description clearly states the verb 'Build' and the resource 'UNSIGNED transaction to unseat an operator', and explains the effect 'frees its seat and bandwidth'. It distinguishes from siblings like 'prepare_seat_operator' and other transaction builders.

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

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

The description implies when to use the tool (to unseat an operator), but does not explicitly state when to use it versus alternatives, nor does it mention prerequisites or exclusions. No guidance on when not to use it.

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

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

Annotations already indicate the tool is not read-only (readOnlyHint=false) and not destructive (destructiveHint=false). The description adds that it builds an unsigned transaction (so not directly executed), spends FLOOR, and may require prior approval. This provides useful behavioral context beyond annotations.

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

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

The description is two sentences, front-loaded with the main purpose, and every sentence adds value. No wasted words.

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

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

For a transaction preparation tool, the description explains what it does and how to use it. While there is no output schema, the agent can infer the result is an unsigned transaction. A note on output format would improve completeness, but it is still adequate.

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

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

Both parameters have schema descriptions (100% coverage). The tool description adds context: costFloor is from the desk table and used only for allowance check, and from is the signing wallet (recommended). This enhances understanding beyond the schema alone.

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

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

The description clearly states the tool builds an unsigned transaction to upgrade a desk to the next tier, and it always steps up one tier. This distinguishes it from sibling tools like prepare_create_desk.

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

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

The description explains when to use the tool (to upgrade desk) and provides important usage notes: it spends FLOOR so an approve may be needed, and costFloor can be passed for allowance checking. It does not explicitly list exclusions or alternatives, but context is clear.

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

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

Discloses that it returns an unsigned transaction (WETH.deposit() call) and that it wraps ETH, adding context beyond annotations which already indicate non-destructive behavior. No contradiction with annotations.

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

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

Two sentences that are concise, front-loaded with purpose, and efficient without extraneous information.

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

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

Given the simple single-parameter tool and no output schema, the description fully covers the tool's role in the workflow, leaving no ambiguity.

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 provides 100% coverage with description for amountEth; the tool description does not add further parameter meaning, meeting baseline.

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

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

The description clearly states the tool builds an unsigned transaction to wrap ETH into WETH, with specific context about being step 1 of buying FLOOR, distinguishing it from siblings like prepare_swap_eth_for_floor.

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

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

Implies usage when needing WETH for swapping, but does not explicitly state when not to use or mention alternatives like prepare_swap_eth_for_floor.

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