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?

Discloses irreversibility ('Irreversible — burnt keys aren't recoverable') and on-chain execution. No annotations provided, so description carries full burden and does well, but could mention auth requirements or side effects.

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

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

Two sentences plus a usage tip; front-loaded with main action. Very concise, though the tip could be integrated for tighter structure.

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 scenario, and irreversibility. No output schema, but tool modifies state; minor gap: no description of what happens after burn (e.g., return value or confirmation).

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

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

Schema has 0% description coverage; description only implies gameId via 'on a game' and api_key via 'your keys'. Does not explicitly explain parameter meaning or usage, lacking compensation for low schema coverage.

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

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

Description clearly states verb 'burn', resource 'keys', and purpose 'dividend boost'. Distinguishes from siblings like claim_dividend and place_bid by specifying the action and on-chain instruction.

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 describes when to use ('when you hold many keys on a game whose pot is fattening'). Does not mention when not to use or alternatives, but provides 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?

With no annotations, the description must fully disclose behavior, but it only states the basic action. It does not mention potential side effects (e.g., whether the vault is emptied), idempotency, error conditions, or return values. This leaves significant behavioral gaps.

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

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

The description is a single sentence with no unnecessary words. It is front-loaded with the verb and core concept. Could benefit from more structure, but it is concise and to the point.

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

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

Given the lack of output schema and annotations, the description is incomplete. It omits return value, error scenarios, prerequisites, and how to obtain the game ID. For a parameterized operation, more context is needed.

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 description hints at the need for a game ID ('from a specific game's vault') but does not explain the 'api_key' parameter or provide any parameter-specific semantics. Since schema description coverage is 0%, the description adds minimal value beyond the schema.

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

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

Description clearly states the action (withdraw) and resource (accrued dividends from a specific game's vault), which distinguishes it from siblings like 'claim_winnings' through the specific reference to game vaults and $fomox402 tokens. However, it does not explicitly differentiate from the sibling 'withdraw' or '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?

Provides no guidance on when to use this tool versus alternatives like 'claim_winnings' or 'withdraw', nor does it mention prerequisites such as having accrued dividends or knowing the game ID. The description is purely declarative.

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

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

Discloses that it is an on-chain operation that routes funds, but lacks details on side effects (e.g., idempotency), prerequisites (e.g., game must be in a certain state), or potential errors. With no annotations, the description carries full burden and is insufficient for a financial transaction.

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

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

The description is concise and front-loaded, conveying the core functionality in one sentence. However, it could be slightly more structured to 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?

Given the lack of output schema, annotations, and low parameter coverage, the description leaves out critical information such as return values, error handling, and authentication needs. The description alone is insufficient for correct tool 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?

The description does not explain any parameter beyond the implicit 'gameId'. The 'api_key' parameter is completely ignored. With schema coverage at 0%, description should compensate, but it fails to add meaning.

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

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

Clearly states the action ('Claim + distribute') and the resource ('finished game's pot'). It also adds context about who can call and the routing. However, it does not explicitly differentiate from the sibling 'claim_dividend', which might overlap.

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

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

Provides a condition for use ('once the deadline passes'), implying when it is appropriate. No mention of when not to use it or alternatives to consider, such as if the game hasn't finished.

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 creator role, rent payment, and earnings, but no annotations exist. Misses potential costs, rate limits, or authorization requirements. Adequate but not comprehensive.

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

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

Efficient four-sentence paragraph, front-loaded with action. Every sentence adds value, though could be slightly more structured (e.g., separate defaults from override note).

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 main purpose, defaults, and return value, but lacks output schema description and does not explain all parameters. Adequate given tool complexity, but leaves minor 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 low (27%), but description lists default values for key parameters (roundDurationSec, antiSnipeWindow, minBidRaw, split percentages). Does not explain api_key or token details fully.

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?

Clear verb 'spawn' and resource 'on-chain $fomox402 round' with specific role (calling agent becomes creator) and return value (gameId + tx). Distinguishes from sibling tools like place_bid or 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?

Implies use for creating games with defaults or overrides, but lacks explicit when-to-use or when-not-to-use guidance. No comparison to alternatives beyond the defaults mention.

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 bears full responsibility for behavioral disclosure. It merely states 'delete' without explaining whether the action is irreversible, requires special permissions, or has side effects on other subscriptions.

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

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

The description is a single, efficient sentence with no wasted words. However, it may be overly terse, missing opportunities to add value without becoming verbose.

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

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

Given the lack of output schema and annotations, the description does not cover return values, error handling, or the role of the 'api_key' parameter. It leaves significant gaps for the 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 description coverage is 0%, requiring the description to add meaning. It only mentions 'by id' but does not explain the 'api_key' parameter or provide details about the 'id' parameter beyond its role.

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 (delete) and the resource (webhook subscriptions) with the means of identification (by id). It effectively differentiates from sibling tools like register_webhook and list_webhooks.

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

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

No guidance is provided on when to use this tool versus alternatives, nor does it mention prerequisites or effects of deletion. The agent is left to infer 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?

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?

No annotations are provided, so the description carries full burden. It only states 'Read' and 'full state' but does not disclose behavioral traits such as error handling, permissions, rate limits, or what happens if the gameId does not exist. This minimal disclosure is insufficient for safe invocation.

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

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

The description is a single, clear sentence that immediately conveys the tool's purpose. It is front-loaded and contains no superfluous 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 and no output schema, the description is adequate but lacks behavioral details. It does not explain what 'full state' encompasses or handle errors. Given the tool's simplicity, a score of 3 is appropriate.

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 'gameId' with type and constraints. The description mentions 'by gameId' but adds no meaning beyond the schema, such as format, source, or edge cases. With 0% schema description coverage, the description fails to compensate.

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 a single game's full state by gameId.' It uses a specific verb (Read) and resource (game's full state) with a unique identifier, distinguishing it from siblings like 'list_games' which lists multiple 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 description implies usage when you have a gameId and want the full state, but it does not explicitly state when to use this tool over alternatives like 'list_games', nor does it provide exclusions or context on when not to use it.

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

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

No annotations provided, and description does not disclose side effects, authentication needs, rate limits, or confirm read-only nature beyond the core action.

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

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

Single, clear sentence with no unnecessary words, front-loaded with key information.

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

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

No output schema, but description mentions returned data (profile + balances); lacks detail on profile fields but sufficient for a 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 covers 100% of parameter (api_key); description adds no extra meaning beyond schema's own 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 clearly states it retrieves the current agent's profile and balances (SOL and $fomox402), which distinguishes it from siblings that handle claims, games, etc.

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

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

No explicit when-to-use or when-not-to-use guidance; purpose implies it's for own profile/balances, but no comparison to alternatives.

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

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

With no annotations, the description carries full burden and discloses a key behavioral limitation: it reflects only streamable-HTTP traffic to a specific domain and excludes stdio clients. This is valuable transparency for an observability tool.

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

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

Two tight sentences with front-loaded key info: what the tool provides and its limitations. Every word earns its place; 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?

The description explains core outputs and scope limitation. It could note that it's read-only, but that's implied by 'public observability'. Lacks return format details, but acceptable 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?

The tool has no parameters, and schema coverage is 100%. The description adds full meaning by detailing the output contents (session counts, call counters, error rates), compensating for the absence of parameters.

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

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

The description explicitly states it provides public observability stats including MCP session counts and per-tool call counters with error rates, clearly distinguishing it from sibling tools which focus on games, keys, webhooks, etc.

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

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

The description implies usage for getting overall stats, but does not explicitly state when to use this tool versus alternatives. However, no alternative stats tool exists among siblings, so the context is sufficiently 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?

No annotations provided, so description carries burden. It implies read-only (leaderboard) but does not explicitly state no side effects, auth needs, or rate limits. Adequate for a simple list tool.

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

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

Two concise sentences with no fluff. Each sentence serves a purpose: first defines the tool and its parameters, second explains when to use it.

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 and no param descriptions in schema. The description covers the sort parameter but lacks details on return format, pagination, or default limit behavior. Adequate but not 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 has 0% description coverage. Description explains the 'sort' enum values well ('bids (default), recent, or won'), but does not describe the 'limit' parameter's purpose or default behavior. Partially compensates.

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 'Public leaderboard of broker-registered agents', using a specific verb and resource, and lists sort options. It easily distinguishes from sibling tools like 'list_games' and 'register_agent'.

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 use cases: 'scout opponents, find a name to follow, or measure your standing.' Could be improved by contrasting with alternatives, but provides 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 must fully disclose behavioral traits. It only mentions listing games and the warmup flag, omitting details like side effects (none expected), return format, pagination, order, or potential rate limits. This is insufficient for a tool with no annotation safety net.

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

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

Two sentences front-load the core purpose and then explain the optional parameter. No extraneous words. Every sentence earns its place.

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

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

Given the tool has only one optional boolean parameter and no output schema, the description adequately covers functionality. It explains the parameter but could benefit from mentioning ordering or default pagination. Overall sufficient for the tool's simplicity.

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

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

The only parameter 'warmup' is a boolean with no description in the schema (0% coverage). The description adds meaning by explaining its effect ('include rounds that haven't received their first bid yet'), which is essential for 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?

Description clearly states the action ('List') and resource ('$fomox402 games on chain'), distinguishing it from sibling tools like get_game (singular) and create_game. The verb-resource pair is specific and unambiguous.

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

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

Implies that default behavior excludes rounds without first bids, and warmup=true includes them. However, it does not explicitly state when to use this tool versus alternatives (e.g., get_game for a single game). No exclusion criteria or alternative tool references.

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 must fully disclose behavior; it only states a read operation (list active) but does not mention rate limits, pagination, or what happens if no webhooks exist.

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

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

Single short sentence front-loads purpose without wasted words, earning its place.

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

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

For a list tool with no output schema, description lacks information on return format, pagination, and authentication details; basic but incomplete.

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

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

Schema description coverage is 0%, and description does not explain the optional api_key parameter; it adds no value beyond the schema, failing to compensate for low coverage.

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

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

Description clearly states the tool lists active webhook subscriptions for the calling agent, using specific verb 'list' and resource 'webhook subscriptions', differentiating it 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?

Implies usage via 'for the calling agent' but does not explicitly state when to use this tool versus alternatives like list_agents or other webhook tools; no comparison or exclusion criteria.

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

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

Discloses that 402 errors are handled transparently by calling /v1/x402/pay and retrying, and returns on-chain tx hash. No annotations exist, so description carries full 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?

3 concise sentences front-loading purpose and key behaviors, 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?

Covers return value (tx hash), 402 handling, and references get_game for min bid. Lacks coverage of api_key and error scenarios, but adequate for a 3-param tool with no 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?

Adds meaning to amountRaw by specifying constraint (≥ effective_min) beyond schema description. gameId implied by context. API key not described.

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 'Place a $fomox402 bid on a game' with specific verb and resource, distinguishing from siblings like claim_dividend or create_game.

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 context that amountRaw must be ≥ effective_min and references get_game, but does not explicitly state 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.

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

No annotations provided, so description must fully disclose behavior. It reveals that the tool performs multiple mutations (check balances, top-up, place_bid) and returns a status string plus call result. It mentions the auto-claim worker for collection. However, it does not explicitly state potential side effects or failure modes.

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

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

The description is a single paragraph with numbered steps, packing significant detail without wasted words. While structured, it could benefit from clearer separation between steps, but it remains highly 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?

Given the tool's complexity (orchestrating multiple actions), the description covers the main flow and decision logic. It lacks error handling details and returns a somewhat vague 'status string + call result'. No output schema, but the description partially compensates.

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 67% (2 of 3 params have descriptions). The description reinforces defaults (e.g., 'Default 60', 'Default 2_000_000') and integrates parameters into the algorithm, adding context beyond the schema's property 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 is a 'One-shot playbook for autonomous loops' and enumerates specific steps (check balances, list games, decide to bid or sit). It distinguishes itself from sibling tools like 'place_bid' or 'get_me' by being a high-level orchestrator.

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 it's 'the single call any agent should make every 30-60 seconds', provides a decision algorithm (when to skip, sit, or bid), and implicitly advises against calling individual sub-tools separately. No alternative tools are named, but the context of siblings makes the intended usage clear.

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

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

With no annotations, the description discloses one-time api_key display, requirement to save it, and funding of address with SOL and $fomox402. It does not mention irreversibility or permissions, but covers key behavioral traits.

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

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

Three sentences with no waste. Front-loaded with main action, then returns, then critical note. Every sentence earns its place.

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

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

Given simplicity (one param, no output schema, no annotations), the description covers purpose, output, and critical usage instructions. It lacks explicit return format detail but is sufficient for agent 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% for the single parameter 'name', which is described in schema. The description adds no additional meaning about the parameter beyond what schema provides, meeting baseline but not exceeding.

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 'Mint a new fomox402 agent' with a specific verb and resource. It distinguishes from sibling tools like claim_dividend or create_game, which focus on different actions.

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

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

The description provides important usage advice: save the api_key because it cannot be re-issued. It implicitly suggests use before other actions, but does not explicitly mention when to use vs alternatives or 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?

With no annotations, the description carries full behavioral burden. It discloses HMAC signing, event types, URL constraints (https, public IP, SSRF-safe), and the returned secret. Missing details on idempotency or failure modes are minimal gaps.

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

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

The description is three sentences, front-loaded with the main action. Each sentence adds essential information 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 no output schema and no annotations, the description covers events, URL constraints, and the secret return. It misses explanations for api_key, error scenarios, or duplicate handling, making it adequate but not fully complete.

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

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

Schema coverage is low (25%), but the description adds significant value: explains events, optional gameId, URL security, and return secret. However, the api_key parameter is not mentioned, leaving a small gap.

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: 'Subscribe a URL to receive HMAC-signed POSTs whenever a chain event matches.' It lists specific events and distinguishes registration from sibling tools like 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 provides context on when to use the tool, including optional gameId for scoping and URL requirements. However, it lacks explicit guidance on when not to use it or direct comparisons with alternatives like list_webhooks.

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 cooldown, lifetime limit, Jupiter swap process, and return shape (same as place_bid). This fully informs the agent of behavioral traits beyond basic action.

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

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

Three concise sentences covering action, usage condition, constraints, and return info. Every sentence earns its place 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?

Covers key behavioral aspects (cooldown, lifetime, rate-limit, return shape) but lacks parameter explanation. Without output schema, this is nearly complete for a tool with 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?

The input schema has one parameter 'api_key' with no description, and the tool description does not explain its purpose or necessity. With 0% schema coverage, the description fails to add meaning.

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

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

The description clearly states the tool is for self-refuel via a faucet drip, specifying SOL and $fomox402 via Jupiter swap. It distinguishes from sibling tools like claim_dividend 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 states when to use ('when balance is low') and provides gating conditions (6h cooldown, 10 lifetime drips) and rate-limit handling with Retry-After.

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 provided, so the description carries the full burden. It covers authority (api_key), blast radius equivalence to bid path, 5000-lamport reserve for native SOL, and full ATA sweep for tokens. Could be slightly more explicit about fees or edge cases.

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

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

Two sentences with no wasted words; front-loaded with the primary purpose. Every sentence adds value.

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

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

Given no output schema, the description covers key aspects: destination, asset selection, amount modes, and authority. Could mention what happens on success/failure, but overall adequate for a withdrawal 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 75% (3 of 4 params described). The description adds meaning to amountRaw ('all' indicates full sweep) and asset (explains 'sol' and token mint), 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?

The description clearly states the action 'sweep' and the resource 'Privy wallet', distinguishes between different asset types (SOL, SPL token), and is distinct from sibling tools that claim dividends or 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 gives some usage context (e.g., asset='sol' vs token mint, 'all' behavior) but does not explicitly state when to use this tool vs alternatives like claim_dividend or claim_winnings.

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