fomox402 — Last-Bidder-Wins on Solana

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

Without annotations, description fully discloses it's a public GET, reads config, returns version, and lists failure modes. No behavioral gaps given the tool's simplicity.

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

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

Front-loaded with bold summary, well-organized with headings. Every sentence provides unique 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?

Given simple 1-param tool with no output schema, the description fully covers return structure, failure modes, and relationships, making it complete.

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

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

Schema coverage is 100%, but description adds value by clarifying the parameter format (base58 pubkey) and source (same as register_agent/get_me), 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?

The description clearly states it reads an agent's STRAT config, distinguishing it from siblings like agent_equip_set (write) and agent_operators_list (who can write). Uses specific verb+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?

Explicitly says when to use: before agent_equip_set to compute expected_version, or to inspect competitor's config. Also covers failure mode (404) and how to handle it.

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

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

No annotations are provided, so the description fully handles behavioral disclosure. It details failure modes, broker verification steps, payload canonicalisation, and that the broker never signs. All relevant behaviors are explained.

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, FAILURE MODES, RELATED). Each section is concise and informative, with no superfluous text. Bullet points for failure modes improve readability.

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 explains the return value: AgentConfig same shape as agent_equip_get with incremented version. It covers all failure modes, parameters, and usage context. For a complex mutation tool with nested objects, this is thorough.

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 descriptions for each parameter. The description adds valuable context beyond schema: payload must be canonicalised with sorted keys, expected_version should come from agent_equip_get, signature is Base58 ed25519, and client-side signing. This enriches the schema but the schema itself already provides good 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 action: 'Write a STRAT config with a caller-signed payload (CAS-protected).' It distinguishes from sibling tools like agent_equip_get (read) and agent_operators_set (permissions).

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?

Includes explicit 'WHEN TO USE' section: after a tower floor is claimed, and for retuning the strategy. Also mentions when NOT to use (by providing alternatives like agent_equip_get for reading and agent_operators_set for granting operator permission).

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

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

No annotations provided, but description covers read-only nature, public access, and return format. It does not explicitly state authentication requirements, but 'public read' implies no auth needed.

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

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

Well-structured with sections (WHAT IT DOES, WHEN TO USE, RETURNS, RELATED). 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 for a single-parameter read tool. Describes return format in detail. No output schema needed as description covers it.

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

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

Input schema has 100% coverage with a clear parameter description. The description does not add additional semantics beyond what the schema already provides.

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

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

Description clearly states 'Read an agent's operator whitelist' and provides the HTTP GET endpoint. It distinguishes from siblings like agent_operators_set by specifying read vs mutate.

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: before agent_equip_set to confirm signer, or to audit write access. References sibling tool agent_operators_set for mutation.

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

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

No annotations provided, but description fully discloses mutation behavior, owner-signature enforcement, canonicalization, and all failure modes, leaving no ambiguity.

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, OPS, CANONICALISATION, RETURNS, FAILURE MODES), every sentence adds value without redundancy.

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

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

Given the complexity (3 params, nested payload, signature verification, failure modes), the description is thorough, covering all aspects needed for correct invocation.

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

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

Schema coverage is 100%, and description adds critical context: payload structure, op semantics, canonicalization requirements, and failure modes, going 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?

Description clearly states it mutates the operator whitelist with an owner-signed payload, and distinguishes from sibling tools like agent_operators_list (read) and agent_equip_set (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?

Provides explicit when-to-use scenarios (granting/revoking write access, rotating operator keys, wiping whitelist) and details on ops, failure modes, and 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?

With no annotations, the description fully carries the behavioral disclosure burden. It explicitly states irreversibility, account closure, rent reclaim, failure modes, and the effect on divPerKeyScaled. This exceeds typical transparency.

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

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

The description is structured into clear sections (WHAT, WHEN, IRREVERSIBLE, RETURNS, FAILURE MODES, ADVANCED, RELATED). Each section earns its place; no wasted words. The first sentence is a concise summary.

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 provides comprehensive return values, failure modes, preconditions, and irreversible effects. It covers all necessary context for an agent to use the tool correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by clarifying that api_key must belong to the wallet holding keys and that gameId must be a round with keys. This extra context justifies a 4.

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

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

The description starts with a clear verb and resource: 'Burn ONE key on a round to permanently boost your share on the remaining keys.' It distinguishes from siblings by explicitly mentioning related tools (claim_dividend, place_bid) and providing usage 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 'WHEN TO USE' section specifies conditions ('only when you hold many keys (>5)...') and gives a mathematical reasoning. It also includes an 'ADVANCED USE' section for counter-burn defense, and mentions when not to use (e.g., small key share).

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

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

No annotations provided, so the description carries full burden. It comprehensively discloses behavior: invokes 'distribute' instruction, calculates share using formula, returns transaction signature and other fields. It lists three failure modes with causes. Prerequisites (holding keys, wallet matching) are clearly stated, and the side effect of updating the high-water mark is implied.

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, WHO CAN CALL, RETURNS, FAILURE MODES, DIFFERENCES) making it easy to scan. While it is somewhat long, every sentence adds necessary detail. Front-loaded with the core purpose. A minor improvement could be condensing the formula explanation, but it remains 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 tool's complexity (on-chain interaction, dividend mechanics, failure modes, return values), the description is remarkably complete. It covers prerequisites, precise calculation, return format, and failure cases. No output schema exists, but return fields are described. The comparison with sibling 'claim_winnings' and related tools (burn_key, get_game) adds essential context.

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

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

Schema coverage is 100%, so baseline is 3. The description adds significant value beyond the schema: 'gameId' is clarified as 'Round you hold keys on' with a hint to verify via 'get_game where yourKeys > 0', and 'api_key' is stressed as 'MUST be the wallet that holds the keys'. This provides important context for correct usage.

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

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

The description clearly states the purpose: withdraw accrued dividends from a specific round. It uses specific verbs ('withdraw', 'pays out') and resources ('$fomox402 key dividends', 'Anchor program's distribute instruction'). It explicitly differentiates from the sibling 'claim_winnings' by contrasting winnings vs. dividends, ensuring no confusion.

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

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

Provides explicit guidance on when to use: 'any time post-bid', dividends accrue continuously, can claim mid-round or after settle. Recommends claiming once per round after settle to minimize fees. Also explains who can call (keyholders) and crucial condition that api_key must match the wallet. Clear alternatives and exclusions are stated via the 'DIFFERENCES FROM claim_winnings' 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?

Without annotations, description fully discloses atomic distribution, marking gameOver=true, permissionless calling, and lists failure modes with causes.

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 into sections, front-loaded with purpose. Each sentence is informative, though slightly lengthy but not wasteful.

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, but description details return shape including tx, gameId, payouts. Covers failure modes, permissionless nature, and alternatives, making it complete.

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

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

Schema coverage 100% so baseline 3. Description adds context for gameId (must be expired and not gameOver) and api_key (anyone can settle), providing 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?

Clearly states it settles a finished round and pays out winner, invoking Anchor program's claim instruction. 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?

Explicitly specifies when to use (deadline passed, not gameOver) and when not (not expired, already claimed). Mentions autoclaim worker as automatic alternative.

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

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

No annotations provided, so description carries full burden. Discloses that it invokes Anchor program, pays rent, creator earns creatorBps, rent refunded on settle, and split sums must be 10000 bps. Could mention prerequisites like SOL balance, but overall strong.

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

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

Well-structured with clear sections: WHAT IT DOES, WHEN TO USE, DEFAULTS, RETURNS, RELATED. Every sentence adds value without unnecessary verbosity. Front-loaded with main 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?

Covers purpose, usage, defaults, return format, and related tools. Lacks error handling details and mentions of prerequisites (e.g., SOL for rent). For a complex creation tool with 11 optional params, it is fairly comprehensive.

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 100% with good descriptions, baseline 3. Description adds value by listing all defaults, explaining rationale (e.g., higher minBidRaw reduces bids), and stating the split sum requirement, which goes 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 spawns a new on-chain round and makes the agent the creator. Distinguishes from siblings like list_games and place_bid by explaining the role of creator and when to use vs. joining existing rounds.

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: when no live round suits strategy or when wanting creator share. Includes cost mention (~0.005 SOL rent, refundable) and references related tools (list_games, place_bid) for alternative 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?

No annotations provided, so description carries full burden. It discloses idempotency, returns 404 for already-deleted ids, and explains effect (stops POSTing events). Could mention auth requirements, but api_key is in schema.

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

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

Well-structured with clear sections (WHAT IT DOES, WHEN TO USE, RETURNS, RELATED). 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?

For a simple deletion tool with 2 parameters and no output schema, the description covers purpose, usage, behavior, return value, and related tools completely.

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

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

Schema coverage is 100%, so parameters are described. The description adds value by linking 'id' to list_webhooks/register_webhook responses. For api_key, no additional context 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 the tool unsubscribes a webhook by id, with a detailed explanation of what it does. It distinguishes from siblings by naming list_webhooks and register_webhook as related tools.

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

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

Explicitly provides usage scenarios (rotating endpoints, retiring agents, narrowing scope) and references related tools for context. It lacks explicit 'when not to use' but the positive 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?

Given no annotations, the description fully discloses authentication (HMAC, not Bearer), secret handling, failure modes, return type, and the HMAC computation process. It is thorough and accurate.

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). It is concise yet informative, 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 complex tool involving HMAC and streaming, the description covers all aspects: purpose, usage, authentication, parameters, return value, failure modes, and related tools. It is complete even without an 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 schema already describes parameters, but the description adds significant context: HMAC secret usage, event structure nuances, bigint safety, and that secret never leaves the process. This 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 the tool publishes a single event from a firm into the tower stream. It differentiates from siblings like tower_replay and SSE streams, making the purpose distinct.

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 (only for onboarded firms, one event per call for recoverable batches) and mentions related tools. It lacks an explicit 'when not to use' but the context is clear.

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

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

States read-only, no auth required, fetches from Anchor program with no cache, and freshness guarantee. Return fields are fully listed. No annotations exist, so description carries full burden and meets it.

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 separate sections (WHAT IT DOES, WHEN TO USE, RETURNS, RELATED). Concise yet informative, 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 simple read tool with one parameter, the description covers purpose, usage, return fields, and behavioral notes fully. No output schema needed as returns are listed. Complete.

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

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

Single parameter gameId already described in schema. Description adds context 'Get from list_games[].gameId or create_game's response' which is helpful. Schema coverage 100% so baseline 3, but extra context raises to 4.

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

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

Clearly states it reads a single round's full on-chain state. Verb (read), resource (single round), scope (full state) are explicit. Distinguishes from siblings like list_games (list ids) and write tools.

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

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

Provides explicit when-to-use scenarios (after place_bid, before claim_winnings, for authoritative deadline) and contrasts with list_games staleness. Offers clear 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?

No annotations provided, so the description carries full burden. It discloses read-only nature, no on-chain side effects, no rate-limit cost, and that balances are refreshed from Solana RPC. It does not mention error conditions but the core behavioral traits are well covered.

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), front-loaded with key info, and every sentence adds value without redundancy.

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

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

Despite no output schema, the description provides a detailed return structure including nested objects (balances, stats, faucet). Combined with clear purpose and usage, it fully equips the agent to 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 description coverage is 100%, but the tool description adds value by explaining that the agent is looked up by api_key (Bearer or arg) and when it is required. This additional context helps the agent understand parameter usage 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 'Read the calling agent's profile + live on-chain balances,' specifying the verb and resource. It distinguishes itself from siblings by emphasizing read-only behavior and listing related tools.

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

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

The description explicitly states 'WHEN TO USE: before every bid loop, before topup decisions, and after register_agent to verify the faucet drip arrived. Cheap (one RPC call).' It provides clear contexts but lacks explicit exclusion of alternatives.

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

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

Despite no annotations, the description fully discloses behavior: 'Read-only, no auth required, no side effects.' It also explains the visibility limitation regarding local stdio MCP clients, which adds important context beyond a simple read-only hint.

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, VISIBILITY CAVEAT, RELATED) and no unnecessary words. Every sentence adds value, and the format makes it easy to parse.

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, zero-parameter tool, the description is complete. It explains what it returns, when to use, provides a caveat, and references related tools. The absence of an output schema is mitigated by the detailed return description.

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 exist, so the input schema is fully covered. The description adds value by detailing the return object structure, which compensates for the lack of an output schema. Without output schema, the description's explanation of the return shape earns a 4.

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

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

The description explicitly states 'returns aggregated MCP traffic + per-tool call telemetry' with a clear verb and resource. It distinguishes from siblings by referencing 'list_agents' and 'get_me' as related tools, making the purpose unambiguous.

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

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

Explicitly provides usage scenarios: 'for dashboards, health checks, or to verify the broker is alive before a long autonomous run.' Also includes a visibility caveat and mentions related tools, guiding when to use this vs. 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?

Discloses read-only, no auth required, safe to call frequently, and server-side caching for 30s. These traits are not provided by annotations, so the description fully covers behavioral expectations.

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 sections, but could be slightly more concise; however, every sentence adds value. Front-loaded with key information.

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

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

Covers all essential aspects: purpose, params, return format, usage context, behavioral traits. Although no output schema, the provided return object example compensates well.

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 detail beyond the schema: default and max for limit, and explains each enum value for sort (bids=activity, recent=who's playing now, won=skill). Schema coverage was 100%, but description adds 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?

Clearly states the tool returns a leaderboard of agents ranked by activity, using the verb 'returns' and specifying the resource 'fomox402 agents'. Distinguishes from siblings like get_me and list_games via 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?

Provides explicit WHEN TO USE scenarios: scout opponents, find a name, measure standing. Also notes it is read-only, no auth, safe to call frequently. Mentions related tools for alternative 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?

With no annotations, the description fully carries the burden. It discloses read-only nature, no auth required, server-side caching (~5s), and explicitly notes it queries on-chain data. It also details the 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?

Well-structured with clear section headers (WHAT IT DOES, WHEN TO USE, PARAMS, RETURNS, STRATEGY HINT, RELATED). Each sentence adds value. However, the RETURNS section is verbose with a full field list; could be slightly more concise by referencing schema or omitting details that are in the output, but it's still good.

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 fully covers the tool's purpose, usage, parameters, return values (including field names and types), and even provides strategic context. No output schema exists, but the return structure is fully documented. Given the complexity of the product and many sibling tools, this is comprehensive.

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 'warmup' has 100% schema coverage, so baseline 3. The description adds context beyond schema: explains the behavior ('include rounds that exist on-chain but have not yet received their first bid') and practical use case ('sniping cheap first bids'). This extra value justifies a 4.

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

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

The description explicitly states it lists active and recently-settled game rounds, distinguishes itself from siblings like get_game (single round detail) and place_bid (bidding), and clearly defines the scope ('queries the on-chain program for every fomox402 round the broker tracks').

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 ('every poll cycle in autonomous mode, or whenever the agent needs to choose a round'), when-not-to-use ('Prefer over get_game when you don't already know the gameId'), and a strategy hint for aggressive bidding scenarios, making it clear when to prefer this tool over 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?

Despite no annotations, the description fully discloses behavior: read-only, no side effects, returns creation order, and explicitly states secret values are not returned.

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 well-structured with distinct sections (WHAT IT DOES, WHEN TO USE, RETURNS, RELATED) and uses minimal, informative 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?

Even without an output schema, the description provides the return structure, ordering, and caveat about secret values. Complete for a list 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?

Schema coverage is 100% for the single api_key parameter. The description does not add extra meaning beyond the schema, meeting 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 'List the agent's active webhook subscriptions' and elaborates with 'returns every webhook the calling agent has registered, in creation order.' It distinguishes 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?

Explicitly provides when to use: 'to audit subscriptions before adding more, or to find the id of a webhook you want to delete.' Also notes read-only nature, helping agents 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?

No annotations provided, so description fully carries burden. It details the 3-leg process, fees, failure modes, return structure, and side effect of minting a key. Completely transparent.

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

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

Well-structured with headings (WHAT IT DOES, WHEN TO USE, FEES, etc.) and every section adds value. However, slightly long; could condense failure modes and returns list without losing clarity.

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 (3-leg payment, Solana, no output schema), the description is highly complete. It covers return fields, failure reasons, side effects (minting key), and references siblings for further context.

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

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

Schema description coverage is 100%. Description adds extra context: for amountRaw, explains it must be ≥ effective_min and suggests usage; for gameId, warns about 404 on settled/non-existent rounds. 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 it places a bid on a game round, handles the x402 micropayment internally, and returns a bid tx hash. It distinguishes from siblings like list_games, get_game, 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?

Explicitly says 'WHEN TO USE: any time you want to be the head bidder.' Provides preconditions: use gameId from list_games, set amountRaw ≥ effective_min. Mentions related tools like play (auto-loop wrapper) and burn_key.

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

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

With no annotations provided, the description fully carries the burden of behavioral disclosure. It explains the entire multi-step flow, including silent handling of rate-limits during topup, conditions for sitting as head bidder, return statuses, and possible error scenarios. No behavioral traits are hidden.

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

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

The description is relatively long but well-structured with labeled sections (WHAT IT DOES, WHEN TO USE, POSSIBLE STATUSES, RETURNS, RELATED). It front-loads the core purpose. Could be slightly more concise, but every sentence serves a purpose.

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

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

Given the tool's complexity (multi-step, sub-calls, multiple outcomes), the description is highly complete. It covers the algorithm, statuses, error cases, and return structure. Despite lacking an output schema, the description fully documents the return format.

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 all three parameters described. The description adds significant context beyond the schema, explaining how each parameter affects tool behavior (e.g., min_sol_lamports triggers topup, sit_if_head_threshold_sec determines when to sit). This helps the agent decide parameter values intelligently.

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 defines 'play' as a one-shot autonomous playbook that collapses multiple steps into a single call. It specifies the exact sequence of actions (check balances, topup, list games, filter, bid/sit) and explicitly distinguishes it from sibling tools like get_me, list_games, place_bid, topup, claim_winnings.

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 explicitly stating this tool is intended as the only tool in a recurring stateless agent loop. It also mentions alternatives: 'call those individually if you want fine-grained control', providing clear usage context and 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?

No annotations provided, so description carries full burden. It discloses all side effects: on-chain funding, leaderboard registration, auto-faucet drip, api_key shown only once, and broker stores only sha256 hash. 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-structured with sections (WHAT IT DOES, WHEN TO USE, RETURNS, SIDE EFFECTS, RELATED). Front-loaded purpose. Slightly verbose but every sentence adds value. Minor redundancy could be trimmed, but overall good.

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?

Only 1 parameter with full schema coverage. No output schema, but description lists all return fields. Covers side effects, idempotency, and related tools comprehensively. Complete for a registration tool.

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

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

Schema description coverage is 100% with thorough parameter details. The description adds context about idempotency and namespace key behavior, going beyond the schema. Baseline 3, plus extra value gives 4.

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

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

The description states 'Mint a new fomox402 agent identity. Always the FIRST tool you call.' It clearly identifies the verb and resource, and distinguishes from siblings like 'get_me', 'topup', and 'withdraw'.

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 'always the FIRST tool you call' and 'once per agent identity'. Describes idempotency on 'name' and notes that calling twice returns existing agent_id but does not re-issue api_key. Also lists 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?

With no annotations, the description fully discloses behavior: HMAC-signed delivery, SSRF allowlist constraints, 4KB body limit, return format including secret. Lists all event types with descriptions. No contradictions with missing 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 sections, but somewhat lengthy. Each sentence adds value, but could be slightly more compact. Still highly effective for an AI agent.

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

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

No output schema, but description includes return object fields. Covers required and optional params, URL constraints, event types, security (HMAC), and related tools. Complete for this 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?

Schema coverage is 100%, but the description adds meaningful context beyond the schema: URL must be https, SSRF allowlist, events meanings, gameId scope, api_key from env. The event list in the description provides more detail than the schema enum.

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-resource pair 'Subscribe a URL' and explains that it registers an endpoint for event POSTs. It distinguishes from sibling tools like list_webhooks and delete_webhook by naming them 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?

Explicit WHEN TO USE section states long-lived agents prefer push over polling, and advises stateless agents to poll instead. Names the alternative polling tool (list_games) and recommends against polling, providing clear 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?

No annotations present, so description carries full burden. It discloses rate limits, lifetime limits, failure modes, return values, and the atomic swap mechanism, ensuring the agent knows exactly what to expect.

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 into sections (WHAT IT DOES, WHEN TO USE, etc.) and front-loaded with purpose. While lengthy, all sentences add value. Could be slightly more concise but still efficient.

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

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

Comprehensive coverage: no output schema, but description details return fields and failure modes. Handles complexity of atomic swap, rate limits, and lifetime limits without leaving 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?

Only one parameter (api_key) with schema description already covering its purpose. The description adds minor context (wallet behind key receives drip) but doesn't significantly enhance beyond schema. Schema coverage is 100%, so baseline 3 is appropriate.

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

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

The description clearly states that the tool triggers a faucet drip into the calling agent's wallet, explaining the atomic SOL + $fomox402 transfer via Jupiter swap. It distinguishes itself from siblings like 'withdraw' and 'play' by detailing the specific mechanism and when it's used.

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 (when balances are low) and that 'play' calls it automatically. Also provides rate limits (6h cooldown, 10 lifetime drips) and failure modes, giving clear guidance on alternatives.

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

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

No annotations provided, but the description fully discloses read-only operation, no auth required, and lists the complete return structure. Minor omission of rate limits or error handling, but adequate for a simple read tool.

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

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

Well-structured with clear sections (WHAT IT DOES, WHEN TO USE, RETURNS, RELATED). Every sentence is informative and concise, no fluff.

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

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

Given no output schema, the description provides the full return object. Covers usage, related tools, and parameter semantics. Completely adequate for this simple read tool.

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

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

Schema coverage is 100% and the description adds context by explaining the parameter's source (tower_floors[].n) and usage, going 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?

The description clearly states it reads the full state of a single tower floor by index, specifies the REST endpoint, and distinguishes it from sibling tower_floors which provides an index overview.

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: after tower_floors narrows down a candidate and post-claim to verify ownership. Also warns not to use for claiming and points to the POST endpoint and 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?

With no annotations, the description carries the full burden. It discloses that the tool is read-only (GET), requires no auth, is broker-cached (~5s), and returns both markdown and raw JSON. This provides sufficient behavioral context for a read operation.

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

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

The description is thorough but somewhat lengthy. It uses clear section headers and lists, but some redundancy exists (e.g., repeating the return format in text and explicitly listing fields). Could be more concise without losing clarity.

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 adequately explains the return format and usage context. It covers what the tool does, inputs, outputs, and related tools. The complexity is moderate, and the description meets the needs 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 coverage is 100% and both parameters have descriptions. The description adds value by explaining defaults (omit status for all floors, tower_id defaults to live tower 'v0'), which aids correct invocation.

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 tower floors with status and claim fee. It distinguishes itself from siblings like 'tower_floor_detail' (single floor) and 'tower_replay' (firm-level events), making the agent's selection 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 specifies when to use: before 'tower_floor_detail' or before signing a claim envelope, and as a passive scout. It references related tools and the REST endpoint for claiming. While it doesn't explicitly state when not to use, it provides clear context and alternatives.

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

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

With no annotations, the description fully bears behavioral disclosure. It declares read-only, no auth required, describes monotonic seq order, and explains pagination via next_cursor. However, it omits details on rate limits, error handling, or data retention, slightly lowering transparency from perfect.

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). Each sentence adds value without redundancy, and the organization makes it easy for an AI agent to parse.

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

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

Despite lacking an output schema, the description explains the return type (ReplayResponse fields) and pagination details. It also cross-references related tools. For a read pagination tool with 4 parameters, this provides sufficient context for correct invocation.

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

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

Input schema has 100% coverage, so baseline is 3. The description adds context like default limit (200 server-side) and pagination behavior (omit cursor starts at seq=0), but these are minor enhancements beyond the schema's descriptions, which already clearly define each 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 the tool replays ordered tower events for a specific firm/game pair, specifies the HTTP method and path, and distinguishes from sibling tools like tower_floors (current snapshot) and firm_ingest (publish events). It uses a specific verb ('replay') and resource ('ordered tower events'), making 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?

The description provides explicit when-to-use scenarios (rebuilding state after SSE disconnect, building a static summary, post-mortem) and when-not-to-use (use SSE stream for live tailing instead). It also mentions cost efficiency ('cheaper than re-attaching to stream'), giving clear guidance on 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?

No annotations were provided, so the description carries full burden. It thoroughly discloses failure modes (with reason), authority implications, asset-specific behavior (reserve for SOL, ATA closure for tokens), and return format. 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 well-structured with clear sections (WHAT IT DOES, WHEN TO USE, ASSET PARAMETER, etc.) and uses bolding and line breaks. It is somewhat lengthy but every sentence adds value. Could be slightly more concise.

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

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

Despite no output schema, the description explicitly states return fields ({ tx, to, asset, amountRaw_sent, balance_after }). It covers parameter behavior and failure modes comprehensively. A minor gap is lack of mention of idempotency or rate limits, but overall complete for a 4-parameter 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?

While schema coverage is 100% (all 4 parameters described), the description adds significant meaning beyond the schema: explains the 'all' behavior for amountRaw, special-case 'fomo' alias for asset, and the reserve for SOL. This extra detail justifies 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 explicitly states 'Sweep funds out of the calling agent's Privy wallet to any address' and differentiates from sibling tools like 'topup' (opposite) and 'get_me' (check balances). It uses a specific verb 'sweep' and defines the resource clearly.

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 use cases ('Retiring an agent', 'Cashing out winnings', 'Routing $fomox402') and mentions authority/auth model. It refers to related tools ('git get_me' and 'topup') but does not explicitly state when not 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.