fomox402 — Last-Bidder-Wins on Solana

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

Beyond annotations (readOnlyHint, idempotentHint, destructiveHint), the description adds 'Public read — anyone can audit' and explains the version field as a CAS token for subsequent writes. 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?

Well-organized with clear headers (WHAT IT DOES, WHEN TO USE, RETURNS, FAILURE MODES, RELATED). No wasted words, efficient and informative.

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

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

Given output schema exists, description covers purpose, usage, return structure, and failure modes. Fully complete for a read-only tool with one 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?

Only one parameter with 100% schema coverage. Description adds context: wallet pubkey base58, and reference to register_agent / get_me. Adds value beyond schema description.

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

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

Clearly states the verb 'Read' and resource 'agent's STRAT config', and specifies the HTTP endpoint. Distinguishes from sibling tools like agent_equip_set and agent_operators_list.

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

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

Explicitly says when to use: before agent_equip_set to get the next expected_version, or to inspect a competitor's config. Also lists related tools and failure modes.

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 (destructiveHint=true), the description discloses headless operation (broker never signs), payload canonicalization, atomic writes, versioning, and lists specific failure modes. 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 well-structured with clear sections (WHAT IT DOES, WHEN TO USE, etc.). Every sentence adds value; no fluff. Front-loaded with the essential action, then details.

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 and 23 sibling tools, the description covers all necessary aspects: purpose, usage, behavioral details, failure modes, and related tools. It mentions the output schema references agent_equip_get, which is 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%, but the description adds critical meaning: canonicalization details, signature format (Base58 ed25519), CAS guard explanation for expected_version, and that payload must be signed client-side. These go well 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 explicitly states 'Write a STRAT config with a caller-signed payload,' using a specific verb and resource. It distinguishes the tool from siblings like agent_equip_get (read) and agent_operators_set (permissions), making its purpose unique and clear.

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

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

The 'WHEN TO USE' section provides clear context: after claiming a tower floor to push config, and to retune strategy. It also advises refetching on 409 conflict. While it doesn't explicitly state when NOT to use, the failure modes and related tools imply 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds that it's a 'public read' and a GET endpoint, and details the return structure. There are no contradictions, and the description enhances understanding beyond the annotations.

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

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

The description is well-structured with sections: WHAT IT DOES, WHEN TO USE, RETURNS, RELATED. It is front-loaded with the core purpose and every sentence adds value. No unnecessary words.

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

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

Given the tool's simplicity (one input parameter) and the availability of an output schema, the description covers purpose, usage, return format, and relationships to sibling tools. It is complete and provides all necessary context for an AI agent.

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

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

Schema coverage is 100% (one parameter with a description). The description does not add new semantics for the parameter beyond what the schema provides, but it does place the parameter in context. Baseline 3 is appropriate as schema already documents the parameter adequately.

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 'Read' and the resource 'agent's operator whitelist'. It distinguishes from sibling tools like agent_operators_set (mutate) and agent_equip_set (operators may write configs but not modify this list), providing a specific and unambiguous purpose.

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 'WHEN TO USE' section explicitly tells the agent to use this tool before agent_equip_set to confirm the signer is on the list, or for auditing. This provides clear context and alternatives, making it easy for the agent to decide when to invoke 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 destructiveHint=true and readOnlyHint=false. The description adds critical behavior: broker enforces owner-only signing, operator-signed mutations rejected, headless broker never signs, payload canonicalization rules, and specific failure modes. This far exceeds annotation coverage.

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

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

Well-structured with clear sections: summary, What It Does, When To Use, Ops, Payload Canonicalization, Returns, Failure Modes, and Related. Each sentence adds value with no redundancy. Front-loaded with purpose.

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

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

For a tool with 3 parameters, nested payload, security constraints, and failure modes, the description covers all necessary aspects: authentication, operations, canonicalization, return type, and errors. Output schema is mentioned but not needed since return type is described as OperatorsList.

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

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

Schema coverage is 100%, but description adds meaning: details the payload structure with op types (add/remove/set), required fields (nonce, expiry_unix), and canonicalization instructions. Also explains signature and agent_wallet parameters beyond schema descriptions.

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

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

Description starts with 'Mutate the operator whitelist with an owner-signed payload,' clearly specifying the verb (mutate), resource (operator whitelist), and authentication requirement. It distinguishes from siblings by naming agent_operators_list (read) and agent_equip_set (the permission being granted).

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: 'granting / revoking write access for a sidecar process, rotating an operator key, or wiping the whitelist before retiring an agent.' Also lists related tools for read and the permission 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 set destructiveHint=true, but the description adds rich detail: 'IRREVERSIBLE: burnt keys are gone. The on-chain account is closed and the rent is reclaimed.' Also lists failure modes and advanced use cases. Fully transparent 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?

Description is organized with clear sections (WHAT IT DOES, WHEN TO USE, etc.) and front-loaded with the key action. A bit long but each section provides unique value. Could trim some redundancy but still effective.

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 destructive nature, 2 parameters, and presence of an output schema (mentioned with return fields), the description covers purpose, usage, failure modes, related tools, and advanced strategies. No gaps.

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

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

Input schema has 100% coverage. Description adds context for api_key ('Must be the wallet that holds the keys'), which is not in the schema description. For gameId, it paraphrases the schema. Adds value beyond schema.

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

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

The description clearly states 'Burn ONE key on a round to permanently boost your share on the remaining keys.' It specifies the verb (burn), resource (key on a round), and effect. It also distinguishes from siblings like 'place_bid' (opposite) and 'claim_dividend'.

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

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

Provides explicit when-to-use: 'only when you hold many keys (>5) on a round whose pot is still ratcheting up.' Explains the math behind the decision. Does not explicitly state when not to use, but the conditions are clear enough.

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

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

Annotations indicate destructiveHint=true, which aligns with the description's mention of invoking the 'distribute' instruction and returning a Solana signature (side effect). The description adds context beyond annotations, such as the formula for dividend calculation, failure modes, and that api_key must match the wallet. No contradiction with annotations.

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

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

The description is well-structured with clear sections (WHAT IT DOES, WHEN TO USE, WHO CAN CALL, RETURNS, FAILURE MODES, DIFFERENCES, RELATED). Every sentence adds value, and the length is appropriate for the tool's complexity. 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 tool's complexity (claiming dividends with a formula, multiple failure modes, wallet binding), the description is highly complete. It explains the formula, prerequisites, return format, failure modes, and relationships to other tools. The presence of an output schema does not diminish the need for the description's rich explanations.

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 still adds significant meaning: for 'gameId', it specifies 'Round you hold keys on. Get from get_game where yourKeys > 0.' For 'api_key', it emphasizes 'MUST be the wallet that holds the keys.' These details go beyond the schema's minimal descriptions.

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

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

The description clearly states the tool's purpose: 'Withdraw your accrued $fomox402 key dividends from a specific round.' It uses specific verbs and resources, and explicitly distinguishes from the sibling tool 'claim_winnings' by contrasting winnings (round-end pot) vs dividends (per-key passive income).

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

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

The description provides explicit guidance: 'any time post-bid', typical usage ('most agents claim once per round, after settle, to minimize fees'), prerequisites ('agent who holds at least 1 key'), and constraints ('api_key MUST match the wallet'). It also lists failure modes and differentiates from 'claim_winnings', offering clear when-to-use and when-not-to-use advice.

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

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

The description provides detailed behavioral context beyond annotations: it explains the atomic distribution of funds, sets gameOver=true, and lists failure modes. No contradiction with annotations (destructiveHint=true is consistent).

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 well-structured with clear sections, but slightly verbose. It could be condensed while retaining all essential information. Front-loading the purpose helps.

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

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

Given the tool's complexity (Solana program interaction, multiple payout splits, failure modes), the description is fully complete. It covers preconditions, side effects, return format, and failure modes with no gaps.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by clarifying that gameId must be expired and not gameOver, and that api_key does not need to be the winner. This provides meaningful extra context.

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

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

The description clearly states that the tool settles a finished round and pays the winner, and elaborates on the specific Anchor instruction and fund distribution. It distinguishes from siblings like 'claim_dividend' and 'play'.

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

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

The description explicitly states when to use the tool (after deadline, not yet gameOver) and notes that an autoclaim worker usually handles it, making manual claims optional. It also highlights permissionlessness and failure modes.

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

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

The description discloses invocation of Anchor program, payment of rent, creator earnings, and refund on settle. This adds context beyond annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false) without contradiction.

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

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

Structured with clear headings (WHAT IT DOES, WHEN TO USE, DEFAULTS, RETURNS, RELATED), each sentence is informative and concise, no wasted text.

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

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

Covers all necessary aspects: purpose, usage, parameters with defaults, return format, and related tools. Completeness appropriate for 11-param tool with output schema.

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

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

With 100% schema coverage, the description still adds value by listing defaults, explaining trade-offs (e.g., higher minBidRaw effect), and enforcing sum constraint for bps, which is not in schema.

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

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

The description explicitly states it spawns a new on-chain round, making the agent the creator. It distinguishes from siblings like list_games and place_bid in the RELATED section.

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 'WHEN TO USE' section provides explicit conditions: when no live round suits strategy or to earn creator share. It also mentions cost and refund, helping the agent decide.

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

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

Annotations already indicate destructive and idempotent. Description reinforces idempotency and explains 404 behavior for already-deleted ids, adding 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 extremely concise, using clear headings (WHAT IT DOES, WHEN TO USE, RETURNS, RELATED) with no wasted words.

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

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

Given the tool's simplicity (2 params, one required) and supporting annotations/schema, the description covers purpose, usage, returns, and relations well. Only minor gap: no explicit output schema detail, but return format is mentioned.

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 schema descriptions are clear. The tool description does not add additional parameter-level detail beyond what the schema provides, so 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 unsubscribes a webhook by id and stops POSTing events. It distinguishes from siblings by explicitly mentioning list_webhooks and register_webhook.

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

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

The description provides explicit WHEN TO USE scenarios (rotating URLs, retiring agents, narrowing scope) and related tools. No explicit when-not-to-use, but adequate for a delete 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?

The description goes beyond annotations (which show readOnlyHint=false, destructiveHint=false) to explain HMAC computation, authentication method (not Bearer), broker validation steps, and the fact that the secret never leaves the local process. It also lists failure modes and return structure.

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 well-structured with clear sections (What It Does, When To Use, HMAC, Returns, Failure Modes, Related) but is relatively long. However, every sentence adds meaningful information and does not waste 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 covers prerequisites, authentication details, event structure, error handling, return values (with output schema), and related tools. For a tool with 3 required parameters and nested objects, this is highly complete and leaves 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?

Although schema coverage is 100%, the description adds value by clarifying the HMAC secret handling (not sent to broker), the event structure with optional fields like 'ts' and 'data', and the re-stamping of seq and ts by the broker. This context helps the agent use parameters correctly beyond the raw 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 starts with a clear verb and resource: 'Publish a single event from a partner firm into the tower stream.' It details the HTTP endpoint and the processing pipeline, distinguishing itself from sibling tools like tower_replay.

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

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

The description specifies that the tool is for firm-onboarded accounts and that each call publishes one event (with a note for batches). It gives clear prerequisites (firm_id + secret pair) but does not explicitly state when not to use it or name alternative tools for other 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds context: 'fetches the freshest state... directly from the Anchor program (no broker cache),' and clarifies latency difference from list_games. Provides value 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?

Well-structured with clear sections: summary, WHAT IT DOES, WHEN TO USE, RETURNS, RELATED. Each section is concise and informative. No redundant sentences.

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?

Output schema exists, and description explicitly lists all return fields. Covers inputs, usage context, and edge cases (staleness). No gaps in describing what the tool does, when to use, and what it returns.

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?

Single parameter gameId has 100% schema coverage. Description adds: 'On-chain round id. Get from list_games[].gameId or create_game's response.' This provides practical sourcing information beyond the schema description.

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

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

Description explicitly states 'Read a single $fomox402 round's full on-chain state.' Uses specific verb (read) and resource (single round). Clearly distinguishes from siblings like list_games (which lists rounds) and place_bid/claim_winnings (which modify state).

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

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

Provides explicit when-to-use scenarios: 'after place_bid to confirm your bid landed; before claim_winnings to confirm you're the head bidder; whenever you need an authoritative deadline (list_games is up to ~5s stale).' Also implies when not to use via related tools section.

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, idempotentHint, destructiveHint), the description adds that it refreshes balances from Solana RPC, has no on-chain side effects, no rate-limit cost, and is a single snapshot.

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?

Well-structured with clear sections (WHAT IT DOES, WHEN TO USE, RETURNS, RELATED), each sentence adds value, no fluff, and 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 one optional parameter and existing output schema, the description fully covers purpose, usage, behavior, and return summary, making it self-contained 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?

Schema describes api_key as optional. Description adds that it can be passed as Bearer token or argument, and that it's optional if env var is set, providing practical usage guidance beyond schema.

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

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

Clearly states it reads the calling agent's profile and live balances, distinguishing it from sibling tools like register_agent, topup, and list_games by specifying its read-only 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 lists when to use: before bid loops, before topup decisions, after register_agent. Also notes it's cheap and read-only, guiding the agent on appropriate contexts.

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, idempotentHint, destructiveHint. Description adds value by stating no auth required, no side effects, and a critical visibility caveat about only counting streamable-HTTP traffic, not local stdio. Exceeds annotation burden.

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?

Well-structured with clear headings (WHAT IT DOES, WHEN TO USE, RETURNS, VISIBILITY CAVEAT, RELATED). Front-loaded with purpose. Every sentence adds value; no fluff.

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

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

Complete given no parameters, rich annotations, and existing output schema. Description explains return structure, visibility caveat, and related tools. No gaps.

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

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

No parameters; schema coverage is 100%. Baseline for 0 params is 4. Description correctly adds no extra parameter info as none are 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?

Clearly states what it does: returns aggregated MCP traffic and per-tool call telemetry. Specifies it is public, read-only, no auth. Distinct from sibling tools like list_agents and get_me.

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: for dashboards, health checks, and verifying broker aliveness before a run. Also mentions the dashboard URL. Does not explicitly state when not to use, 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?

The description adds behavioral details beyond annotations: 'no auth required', 'safe to call frequently (cached server-side for 30s)', and 'Public leaderboard'. Annotations already declare readOnlyHint and idempotentHint, so the description enriches understanding of side effects and access constraints.

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 well-structured with clear sections (WHAT IT DOES, WHEN TO USE, PARAMS, RETURNS, RELATED). Every sentence is informative and non-redundant, and critical info is front-loaded. It is concise without sacrificing completeness.

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

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

Given the tool's simplicity (2 optional parameters, no required fields), the description covers purpose, usage, parameters, return format, and related tools. It also notes that an output schema is provided textually. The description fully addresses an agent's needs to select and invoke this tool.

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

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

The input schema already covers parameters well (100% coverage), but the description adds natural-language explanations for sort options (e.g., 'most bids ever placed (activity proxy)') and default values (limit: 25, sort: 'bids'). This aids interpretation beyond the schema's enum descriptions.

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

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

The description explicitly states that the tool 'returns the top broker-registered agents by activity, ranked according to the chosen `sort`.' It uses a specific verb (returns), resource (agent leaderboard), and scope (fomox402 agents), clearly distinguishing it from siblings like get_me and list_games.

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 'WHEN TO USE' section provides concrete use cases: scouting opponents, finding names to follow, or measuring standing. It also references related tools (get_me, list_games) for context. However, it doesn't explicitly state when not to use this tool or mention exclusions.

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, idempotentHint), the description adds 'Read-only, no auth required, cached ~5s server-side.', which fully discloses behavioral traits without contradiction.

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

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

The description is well-structured with clear sections (WHAT IT DOES, WHEN TO USE, PARAMS, RETURNS, STRATEGY HINT) and no wasted words. Every sentence adds value.

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

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

Given the single optional parameter, high schema coverage, and provided output schema, the description is fully complete. It even includes a strategy hint for optimal usage, leaving no gaps.

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

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

The only parameter 'warmup' has 100% schema coverage, and the description adds functional meaning: 'if true, include rounds that exist on-chain but have not yet received their first bid... Useful for sniping cheap first bids'. This clarifies when and why to use the parameter.

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 lists active and recently-settled game rounds with a specific verb ('List') and resource ('$fomox402 game rounds'). It distinguishes from siblings like get_game (single round) and play (auto-pick), making its purpose unambiguous.

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

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

Explicitly states when to use ('every poll cycle in autonomous mode, or whenever the agent needs to choose a round') and when to prefer alternative ('Prefer over get_game when you don't already know the gameId'). This provides clear guidance on choosing this tool among siblings.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds that the operation is read-only with no side effects, returns items in creation order, and discloses that secret values are not returned. This adds significant context beyond the annotations.

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

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

The description is well-structured with clear headers (WHAT IT DOES, WHEN TO USE, RETURNS, RELATED). Every sentence adds value, and it is concisely written without redundant 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's simplicity, the description fully covers purpose, usage, return format, and behavioral traits. The output schema exists, so return values explanation is 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% (only one parameter: api_key). The description does not add any additional meaning beyond what the schema already provides, so baseline score of 3 is appropriate.

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

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

The description clearly states it lists the agent's active webhook subscriptions in creation order. It uses specific verbs and resources, and distinguishes itself from siblings like register_webhook and delete_webhook.

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 includes a 'WHEN TO USE' section with specific use cases: auditing subscriptions and finding webhook IDs for deletion. It mentions related tools but does not explicitly state when not to use it.

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

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

Discloses the internal x402 micropayment dance, fees, failure modes, and that it mints a key. Annotations indicate mutation and destructiveness, which the description confirms and elaborates. No contradiction.

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

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

Long but well-structured with headings (WHAT IT DOES, WHEN TO USE, FEES, FAILURE MODES, RETURNS, MINTS 1 KEY, RELATED). Every section adds value; slight length but organized.

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

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

Given the complex 3-leg payment process, the description covers fees, failure modes, return fields (tx, gameId, isHead, etc.), and key minting. With an output schema, the description complements it thoroughly.

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 significant context beyond the input schema: where to get gameId, how to determine amountRaw (≥ effective_min), and the string format for bigint precision. Explains usage for cheapest bid vs. autonomous loops.

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 verb 'Place a $fomox402 bid' on a resource 'game round' and distinguishes from sibling tools like play and burn_key. The description explains the 3-leg x402 dance and winning condition.

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 tells when to use ('any time you want to be the head bidder'), how to get parameters (list_games for gameId, effective_min for amountRaw), and lists related tools. Failure modes are also detailed.

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 details the exact steps (get_me, topup, list_games, filtering, decision to sit or bid) and lists all possible return statuses and error cases. Annotations indicate destructiveHint=true and readOnlyHint=false, which align with the described mutation behavior. No contradiction.

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

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

The description is well-structured, starting with a one-line summary, followed by a numbered list of steps, and then sections for when to use, possible statuses, errors, and return format. Every sentence provides necessary information without redundancy. Efficient and focused.

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 an autonomous multistep tool, the description covers all relevant aspects: what it does, when to use, parameter details, possible outputs (including error cases), and relationship to sibling tools. The output schema is described in the return format. 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?

Input schema covers all 3 parameters (100% coverage), but the description adds value beyond the schema by explaining the defaults (e.g., min_sol_lamports = 2_000_000), behaviors when set to 0 (disable auto-topup or always bid), and contextual usage within the play flow. This provides semantic enrichment.

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

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

The description clearly states it is a one-shot autonomous playbook that collapses multiple steps into a single call. It distinguishes itself from sibling tools by noting that individual tools (get_me, list_games, etc.) can be used for fine-grained control. The verb 'play' and resource are well-defined.

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 'as the only tool in a recurring agent loop' and suggests dropping into Claude Desktop, Cursor, Goose, or a cron job. It also provides negative guidance: if you want fine-grained control, use the individual tools instead. This makes when to use vs. when not to use very 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 discloses that the tool provisions a Solana wallet, issues an api_key (shown once), triggers a faucet drip, and registers the agent in the leaderboard. It also notes side effects (on-chain funding) and that the api_key is hashed and unrecoverable by broker. Annotations already indicate idempotency and non-destructiveness, and the description adds valuable context beyond these.

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 well-structured with clear headings (WHAT IT DOES, WHEN TO USE, RETURNS, SIDE EFFECTS, RELATED) and is succinct. Every sentence adds value, and the format aids quick comprehension.

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

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

Given the tool's complexity and the existence of an output schema, the description provides all necessary context: return fields, side effects, idempotency, api_key handling, and related tools. It is fully sufficient for an agent to use correctly.

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

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

The input schema is fully covered (100%), with a detailed description for the 'name' parameter including constraints and behavior. The description does not add significant new meaning beyond what the schema already provides, hence a 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 uses the specific verb 'Mint' and identifies the resource as 'fomox402 agent identity'. It clearly states that this is the first tool to call and explains the idempotent behavior, distinguishing it from sibling tools like 'get_me' and 'topup'.

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 'Always the FIRST tool you call' and 'once per agent identity'. It explains that calling twice with the same name returns existing agent_id but does not re-issue api_key. It also lists related tools (get_me, topup, withdraw) for subsequent 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?

Describes the registration process, HMAC verification, event list, URL constraints, return format. No annotation contradiction; adds context beyond readOnlyHint and 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?

Well-structured with clear sections (WHAT IT DOES, WHEN TO USE, EVENTS, URL CONSTRAINTS, RETURNS, RELATED). Every sentence adds value, 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?

Complete coverage: events explained, constraints detailed, return shape described, usage context given. No gaps given 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 coverage is 100%; description adds meaning: URL must be https with SSRF allowlist, events can be a subset or all four for full feed, gameId optional.

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 subscribes a URL to receive HMAC-signed event POSTs, distinguishing the tool from siblings like list_webhooks and delete_webhook.

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

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

Explicitly advises when to use (long-lived agents preferring push) and when not (stateless agents should poll), with references to alternative tools.

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

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

Describes the atomic SOL+swap mechanism and discloses rate limits (6h cooldown, 10 drips lifetime) and failure modes (rate_limited, drips_exhausted, faucet_dry). Annotations already indicate destructiveness, but the description adds critical behavioral context beyond basic mutability.

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 well-structured with labeled sections (WHAT IT DOES, WHEN TO USE, RATE LIMITS, etc.). Every sentence adds value, and there is no redundant or misleading information. It is front-loaded with the main action.

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

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

For a tool with side effects, rate limits, and failure modes, the description covers all necessary aspects: purpose, usage conditions, rate limits, return values, and error handling. The output schema exists, but the description still explains return fields clearly. No gaps.

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

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

The input schema has one parameter with a description that is already clear. The tool description does not add further semantics beyond what the schema provides. Schema coverage is 100%, so a 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 clearly states the tool triggers a faucet drip to top up the agent's wallet with SOL and $fomox402. It distinguishes itself from sibling tools like get_me (check balances) and play (auto-calls topup) by specifying when it is needed. The purpose is specific and well-defined.

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

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

Explicit 'WHEN TO USE' section indicates thresholds (SOL < ~0.002 or $fomox402 too low), and notes that 'play' calls this automatically. No explicit 'when not to use' is needed given the clear triggers. Also mentions rate limits, providing complete 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?

Descriptors align with annotations (readOnlyHint, idempotentHint, destructiveHint) and add 'Read-only, no auth required'. Even though annotations already provide safety profile, description enhances transparency by detailing no auth and full return fields.

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

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

Concise yet comprehensive; uses clear sections (WHAT IT DOES, WHEN TO USE, RETURNS, RELATED). Every sentence is informative without redundancy.

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

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

Fully describes the tool's role in the workflow, return fields, related tools, and the claim process. Despite output schema not being formal JSON Schema, the listed fields and context are sufficient for an agent to use the tool correctly.

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

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

Schema covers 100% of parameters with clear description (n: floor number, 1-indexed). Description adds context by referencing tower_floors as source for n, improving semantics beyond 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?

Clearly states 'Read full state of a single tower floor by index' and provides the HTTP method GET. Distinguishes from sibling tools by noting differences with tower_floors (index) and agent_equip_get.

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 defines when to use: after tower_floors narrows a candidate for confirmations before signing a claim, and post-claim to verify ownership. Also references alternative tools and mentions the POST claim endpoint.

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 mark it as read-only and idempotent. The description adds read-only, no auth required, and broker-cached ~5s, providing significant extra context beyond the structured 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 well-structured with a summary and sections. It is front-loaded and each sentence adds value. Slightly long but still efficient for the detail provided.

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

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

Given the output schema exists, the description covers returns, related siblings, usage, and behavior. It is thorough and leaves little ambiguity 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?

Schema coverage is 100%, so baseline is 3. The description adds context like the default for tower_id and that omitting status returns all floors. It also mentions the output fields, adding value beyond the schema.

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

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

The description clearly states the tool lists tower floors with status and claim fee. It distinguishes from siblings by mentioning when to use before tower_floor_detail or before claiming. The verb 'List' and resource 'FOMO Capital tower floors' are specific.

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

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

It explicitly says when to use: 'any time before tower_floor_detail or before signing a claim envelope' and suggests polling for passive scouting. It doesn't explicitly state when not to use, but it provides clear context and mentions related tools.

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

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

Annotations already declare readOnlyHint, destructiveHint, and idempotentHint. The description adds that it's read-only with no auth required, explains pagination behavior, and mentions it's cheaper than re-attaching to the stream. No contradiction with annotations.

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

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

The description is well-structured with clear sections (WHAT IT DOES, WHEN TO USE, RETURNS, PAGINATION, RELATED). Every sentence adds value, and it is concise without redundancy.

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

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

Despite having an output schema, the description includes the return shape (ReplayResponse) and key fields. It covers purpose, usage, parameters, pagination, and related tools, leaving no gaps for an AI agent.

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

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

Schema coverage is 100%, and the description adds extra meaning for each parameter: 'firm' is stringly-typed and not agent-scoped, 'game' may be a stringified number or firm-local id, 'limit' defaults to 200, and 'cursor' is opaque pagination. This enriches the schema.

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

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

The description clearly states the tool's purpose: 'Replay ordered tower events for a single (firm, game) pair.' It specifies the HTTP method and path, and distinguishes itself from siblings like tower_floors (current snapshot) and firm_ingest (publish events).

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

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

The description provides explicit 'WHEN TO USE' scenarios (rebuilding state, static summary, post-mortem) and advises against using it for live tailing, pointing to the SSE stream instead. This gives clear guidance on alternatives and 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 indicate destructiveHint=true, but the description adds rich behavioral details: authority model (api_key), failure modes (insufficient_balance, invalid_destination, rpc), the 5000-lamport reserve for SOL, and return format. 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?

Well-structured with clear sections (WHAT IT DOES, WHEN TO USE, ASSET PARAMETER, AUTHORITY, RETURNS, FAILURE MODES, RELATED). While comprehensive, it could be slightly more concise; however, the structure aids readability and clarity for a destructive operation.

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 destructive nature, 4 parameters (100% schema coverage), and presence of an output schema (described in returns), the description leaves no gaps. It covers purpose, usage, parameter details, authority, return format, failure modes, and related tools—everything an agent needs for safe 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 description coverage is 100%, but the description significantly enhances understanding: explains 'all' behavior for amountRaw (reserve for SOL, closing ATA for tokens), clarifies asset values ('sol', mint, 'fomo' alias), and describes how to is handled (deriving destination ATA automatically). Goes well beyond basic 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 'Sweep funds out of the calling agent's Privy wallet to any address.' It uses a specific verb-resource pair, provides examples of when to use, and distinguishes from related tools like topup (opposite).

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

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

Explicit 'WHEN TO USE' section with three concrete scenarios (retiring agent, cashing out, routing tokens). Also includes 'RELATED' section directing to get_me for balance checks and topup for the reverse operation, providing clear context for when to use this tool vs alternatives.

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