fomox402

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

With no annotations, the description fully discloses public read behavior, return fields, and failure mode (404 on first write). Lacks mention of rate limits or caching, but sufficient for a read-only tool.

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

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

The description uses clear section headers (WHAT IT DOES, WHEN TO USE, RETURNS, FAILURE MODES, RELATED) and is concise with no redundant sentences.

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

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

For a single-parameter read tool with no output schema, the description covers all necessary aspects: purpose, usage, return structure, failure handling, and relationships.

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 'agent_wallet' is described in the schema as a base58 pubkey from register_agent/get_me. The description reinforces this requirement and ties it to other tools, adding value beyond the schema.

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

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

The description clearly states the tool reads an agent's STRAT config via GET endpoint, distinguishing it from the write counterpart agent_equip_set. It uses specific verb 'Read' and resource 'config'.

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

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

Explicitly advises when to use: before agent_equip_set to compute expected_version or to inspect competitor config. Also lists related sibling tools, 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, so description carries full burden. Discloses broker never signs, atomic write, CAS check, canonicalisation process, and five failure modes. Very 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 sections (WHAT IT DOES, WHEN TO USE, PAYLOAD CANONICALISATION, RETURNS, FAILURE MODES, RELATED). No redundant sentences; every part 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?

Covers purpose, usage, parameter details, canonicalisation, output shape (AgentConfig with incremented version), and failure modes. For a 3-parameter tool with no annotations and no output schema, this is highly 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%, baseline 3. Description adds significant context: canonicalisation requirement, signing process, and agent_wallet as index. Parameter semantics are well clarified 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 writes a STRAT config with a caller-signed payload and CAS protection. It differentiates from sibling tools like agent_equip_get (read) and agent_operators_set (managing operators).

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

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

Explicitly says to use after a tower floor is claimed or for retuning. Provides guidance on conflict resolution (refetch with agent_equip_get and retry with bumped expected_version). Mentions related tools.

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

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

No annotations provided, but the description fully covers behavior: 'Public read', HTTP GET method, returns specific data structure. No hidden side effects or 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?

Front-loaded with purpose, includes useful details (URL, return format, related tools). Slightly verbose but still efficient for the information conveyed.

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 relevant aspects: purpose, usage context, return type, and related tools. With no output schema, describing the return structure is essential and done 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?

Schema coverage is 100% with a single parameter already well-described. Description adds only the URL path pattern, which is helpful but not critical. 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?

Clearly states 'Read an agent's operator whitelist' with a specific verb and resource. Distinguishes from sibling tools like agent_operators_set (mutate) and agent_equip_set (operators may write configs). No ambiguity.

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

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

Provides explicit when-to-use guidance: before agent_equip_set to confirm signer wallet, or to audit write access. Mentions related tools and their roles, helping the agent choose correctly.

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 covers behavior: broker enforces owner signing, headless operation, payload canonicalisation with sorted keys, returns OperatorsList, and lists all failure modes with explanations.

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, etc.). Front-loaded with purpose, each section earns its place with no redundancy. Concise yet comprehensive.

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 states returns 'OperatorsList after the mutation'. Covers all aspects: operation, signing, failure modes, related tools. Complete for a mutation tool without missing details.

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

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

Schema has 100% description coverage, but description adds critical context: idempotency of add/remove, set replacing entire list (use [] to wipe), signature canonicalization, and nonce/expiry semantics.

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 mutates the operator whitelist with an owner-signed payload, specifies the HTTP endpoint, and contrasts with siblings 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?

Explicit 'WHEN TO USE' section lists concrete scenarios: granting/revoking write access, rotating keys, wiping whitelist before retirement. Also includes failure modes and related tools for 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?

The description warns about irreversibility ('Irreversible — burnt keys aren't recoverable') and mentions the on-chain instruction, but lacks details such as authorization requirements or potential side effects beyond the dividend boost. Given no annotations, it carries the full burden and provides moderately useful behavioral context.

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

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

The description is two sentences long, front-loaded with the main action and effect. Every sentence adds essential information (purpose, irreversibility, use case) 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?

For a simple tool with two parameters and no output schema, the description covers purpose, effect, irreversibility, and a specific use case. It is complete enough for an agent to decide when and how to use 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?

With 0% schema description coverage, the description fails to explain the two parameters (gameId, api_key) beyond their names. It does not clarify what gameId represents or how api_key is used, adding little value over the raw schema.

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

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

The description clearly states the tool's action (burn a key on a game) and its effect (permanent dividend boost on remaining keys). It distinguishes itself from siblings by specifying a unique use case.

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 a clear use case ('when you hold many keys on a game whose pot is fattening'), indicating when to use. It does not explicitly state when not to use or suggest alternatives, but the context is sufficient for an agent.

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, the description must disclose behavioral traits. It indicates a withdrawal action but fails to mention side effects (e.g., reset of accrued dividends), authentication requirements, or potential rate limits. For a financial mutation, more transparency is needed.

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

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

The description is a single sentence with no extraneous words or repetition. It efficiently conveys the core 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 lack of output schema and annotations, the description should provide information about return values, error conditions, or prerequisites (e.g., accrued dividends). It does not, leaving the agent with insufficient 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?

Schema description coverage is 0%, and the description does not explain the parameters beyond implying gameId identifies the vault. The api_key parameter is completely unaddressed, leaving agents uncertain about its purpose or requirement.

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 ('withdraw'), the resource ('accrued $fomox402 dividends'), and the context ('from a specific game's vault'). It distinguishes from sibling tools like 'claim_winnings' and 'withdraw' which handle different assets.

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 guidance is provided on when to use this tool instead of siblings like 'claim_winnings' or 'withdraw'. The phrase 'from a specific game's vault' implies the need for a gameId, but no usage scenarios or prerequisites are mentioned.

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 that funds are distributed to multiple parties and that anyone can call. However, it does not cover side effects like idempotency or failure modes, leaving some 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?

Two sentences with no redundancy, directly stating the purpose and usage condition. Efficient and well-structured.

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

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

For a simple two-parameter tool with no output schema, the description covers the main action and condition but lacks details on return values or error handling. Moderately complete given low complexity.

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

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

The description provides no information about parameters (gameId, api_key). Given 0% schema coverage, this is a critical omission; the agent must infer parameter purposes from 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?

Description clearly states the tool claims and distributes a finished game's pot, specifying the action and resource. It is distinct from sibling tools like claim_dividend, which handles different funds.

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?

Description specifies that anyone can call after the deadline passes, giving a clear condition for use. It does not explicitly mention when not to use or alternatives, but the condition is sufficient.

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 the action (create), creator role (pays rent, earns creator_pct), return values, and defaults. This compensates for 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?

Four concise sentences, each valuable: action, returns, defaults, customization. No wasted words, front-loaded with core 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?

Description covers key actions, returns, and defaults. Without output schema, 'Returns gameId + tx' is sufficient. Could mention prerequisites or errors, but overall complete for agent decision-making.

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 adds meaning to key parameters (e.g., '10-min round', '1 raw minBid', '80/5/5/10 split' maps to roundDurationSec, minBidRaw, Bps fields) and states all params are overridable.

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 spawns a new on-chain $fomox402 round, distinctly different from siblings like 'get_game' or 'place_bid'. It specifies the caller becomes creator and returns gameId+tx.

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?

Description implies use for creating rounds, with sensible defaults and overridable args. Lacks explicit when-not or alternatives, but context and defaults guide agents effectively.

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 states deletion but does not disclose irreversibility, auth requirements, rate limits, or side effects. Critical behavioral traits missing.

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 sentence of 9 words, front-loaded with action and resource. No unnecessary 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, no annotations, and minimal description. Missing return values, safety info, and instructions on how to obtain the id. Significant gaps for a delete operation.

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 0% and description does not explain any parameter beyond 'by id'. The 'api_key' parameter is not mentioned. Adds no meaning 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 action (delete), resource (webhook subscriptions), and identifier (id). It distinguishes from sibling tools like 'list_webhooks' and 'register_webhook'.

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

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

The description implies usage for deletion, but no explicit guidance on when to use versus alternatives (e.g., list_webhooks to find id), prerequisites, 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 provided, the description fully bears the burden of behavioral disclosure. It explains that HMAC is computed locally using the secret (which never leaves the process), that authentication is not Bearer-based, and details all failure modes including hmac_mismatch, firm_not_registered, rate_limited, and bad_event. Return structure is also described.

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

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

The description is well-structured with clear headings (WHAT IT DOES, WHEN TO USE, HMAC, RETURNS, FAILURE MODES, RELATED). Each section is concise and valuable, with no fluff. The opening sentence immediately conveys the tool's core action.

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

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

Given the complexity (HMAC authentication, event streaming, multiple failure modes) and the absence of an output schema, the description covers everything necessary: what it does, when to use, how HMAC works, return values, failure modes, and related tools. It is 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 100%, but the description adds significant meaning: it explains the HMAC role for the 'secret' parameter (used locally, not sent), that 'event' is a single event and broker overrides ts/seq, and failure modes provide practical context for parameter values. This goes well beyond the 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 starts with a clear, specific statement: 'Publish a single event from a partner firm into the tower stream.' It explains the HTTP POST action, HMAC validation, and distinguishes from sibling tools by detailing the unique authentication and event pipeline. No other sibling tool has this purpose.

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

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

Explicitly states when to use: only for onboarded firms with firm_id+secret pair. It clarifies that each call publishes ONE event and recommends calling once per event for batches to enable partial failure recovery. It also lists failure modes and mentions related tools like tower_replay and SSE streams, providing full 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 carries the burden of behavioral disclosure. It correctly identifies the operation as a read, but it does not mention what happens for invalid game IDs (e.g., error response) or any other behavioral details. The description does not contradict any annotations (none provided).

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

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

The description is a single, concise sentence that front-loads the verb and resource. Every word is informative, and no extraneous content exists.

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 is mostly complete. However, the lack of an output schema means the agent does not know the structure of the 'full state' returned. Given the tool's simplicity, this is a minor gap.

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

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

The input schema has one parameter (gameId) with 0% schema description coverage. The description adds 'by gameId' to clarify its role, but it does not elaborate beyond the parameter name. Since the parameter is self-explanatory and the description does not compensate for the missing schema descriptions, the score is baseline at 3.

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

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

The description clearly states the action ('Read') and resource ('a single game's full state') with the parameter 'by gameId'. This effectively distinguishes it from siblings like list_games (which lists multiple games) and create_game (which creates a 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?

The description implies usage for retrieving a specific game's state, but it does not provide guidance on when not to use it (e.g., use list_games for a summary) or any prerequisites. No explicit alternatives are mentioned.

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, and the description does not disclose whether the tool is read-only, requires authentication, or has any side effects. Minimal behavioral context is given.

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 with no wasted words. It is appropriately sized and front-loaded.

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

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

The description mentions the returned items (profile, SOL, fomox402 balances) but lacks detail on format, structure, or edge cases. Without an output schema, more explanation would be beneficial.

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 covers the single parameter 'api_key' with a clear description. The tool description adds no further meaning beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states the tool retrieves the current agent's profile and on-chain SOL and $fomox402 balances. The verb 'Get' and specific resources differentiate it from sibling tools like get_game or list_agents.

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 use for obtaining own profile and balances, but does not provide explicit guidance on when to use alternatives or when not to use this tool.

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

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

The description discloses important behavioral details: it only reflects streamable-HTTP traffic and excludes stdio clients. No annotations are provided, so the description carries the full burden, and it does a good job of setting 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?

The description is concise, consisting of two dense sentences. It front-loads the main purpose and adds specific context about data sources, leaving 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 parameters and no output schema, the description is relatively complete. It explains what data is returned and its limitations. However, it could mention whether the data is cached or real-time, but this is minor.

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 0 parameters, so the description does not need to explain parameters. Baseline 4 applies as no additional meaning is required.

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

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

The description clearly states the tool provides public observability metrics for MCP sessions and per-tool call counters. It lists specific metrics (active, last 24h, lifetime, median duration, error rates) and distinguishes its scope from sibling tools that deal with games, tokens, and agents.

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

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

The description implicitly indicates use for monitoring MCP traffic, and the sibling tools are in different domains (game, token, agent), making it clear when to use this tool. However, it does not explicitly state when not to use it or provide direct 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 are provided, so the description carries full burden. It states the tool is a 'public leaderboard', implying read-only and non-destructive behavior. It does not detail pagination or return format, but for a simple list tool this is adequate.

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 waste. The purpose is front-loaded and every sentence adds value. No repetition or unnecessary detail.

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

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

For a tool with 2 optional parameters and no output schema, the description covers the key aspects: purpose, sort options, and use cases. It is complete for an agent to decide when and how to use 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?

Schema coverage is 0% but the description explains the 'sort' parameter enum values in detail: 'bids' (default), 'recent', 'won'. It does not mention 'limit', but the schema defines constraints (max 100, exclusiveMin 0), so the description adds value for sort only.

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

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

The description clearly states it is a public leaderboard of broker-registered agents, using the verb 'list' implicitly. It distinguishes from sibling tools (e.g., list_games, get_game) by focusing on agents and leaderboard functionality.

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: scout opponents, find a name to follow, measure your standing. It does not mention when not to use, but the sibling context makes it clear this is the only agent listing tool.

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

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

No annotations are provided, so the description carries the full burden. It only mentions listing behavior and the warmup parameter, but lacks details on pagination, ordering, read-only nature, or any other behavioral traits. For a list operation, this is insufficient.

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

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

The description is extremely concise with two sentences, each adding distinct value: the first states the purpose, the second explains the parameter. No wasted words.

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

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

Given the simplicity of the tool (one boolean parameter, no output schema), the description is somewhat complete but still lacks information about the return format, ordering, or whether pagination exists. An agent may need more context to use the tool effectively.

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 the description fully explains the sole parameter 'warmup' by stating its effect ('include rounds that haven't received their first bid yet'). This compensates completely for the missing 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 ('List') and the specific resource ('$fomox402 games on chain'). It distinguishes from sibling tools like 'get_game' (single game) and 'create_game' by focusing on listing all 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 provides usage guidance for the 'warmup' parameter ('Set warmup=true to include rounds that haven't received their first bid yet') but does not give explicit context on when to use this tool versus alternatives like 'list_agents' or 'get_stats'.

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 bears full burden. Merely states it lists active subscriptions for the calling agent, but lacks details on pagination, rate limits, or behavior with no 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?

Single sentence is concise but omits essential details about parameters and usage, making it under-informative.

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

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

Despite low tool complexity (1 param, no output schema), the description fails to explain the parameter or provide behavioral context, leaving significant 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 0% and the description does not mention the api_key parameter, its purpose, or how to obtain/provide it.

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 (list), resource (webhook subscriptions), and scope (for the calling agent). It effectively distinguishes from siblings like delete_webhook and register_webhook.

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

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

No guidance on when to use this tool versus alternatives. No context about prerequisites, restrictions, 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?

Discloses key behavioral trait: if bid endpoint returns 402, it calls /v1/x402/pay from agent's wallet then retries. No annotations, 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?

Four sentences, each informative and efficient. 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?

Complete for a complex tool: explains fee handling, retry logic, parameter constraint, and return value. References get_game for minimum. No output schema but describes result.

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

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

Adds meaning beyond schema: explains amountRaw must be ≥ effective_min and the return value (tx hash). Schema only describes amountRaw format; description adds condition and result.

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 places a bid on a game, handles x402 fee transparently, and returns on-chain tx hash. Distinct from siblings like 'play' or '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?

States when to use (placing a bid) and that amountRaw must be ≥ effective_min from get_game. Doesn't explicitly mention alternatives among siblings but context is clear.

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

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

No annotations are provided, so the description fully carries the burden. It details the step-by-step behavior, return type ('status string + call result'), and internal logic. It could mention error handling or failure cases, but is otherwise 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?

The description is a single paragraph with numbered steps, making it easy to parse. It is front-loaded with the purpose. Slightly verbose but each sentence earns its place. Could be trimmed slightly without loss.

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 (multiple sub-steps), no output schema, and no annotations, the description is remarkably complete. It covers the loop logic, when to act, and what returns. Missing details on error handling or partial failures, but sufficient for an agent to use effectively.

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 adds context beyond the input schema by explaining the default values and purpose of the two documented parameters (min_sol_lamports and sit_if_head_threshold_sec). The third parameter (api_key) is standard and doesn't need explanation. 67% schema coverage is moderate, but description compensates well.

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

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

The description clearly states it is a 'One-shot playbook for autonomous loops' and outlines the specific steps (check balances, list games, decide to sit or bid). It distinguishes from sibling tools like place_bid or get_me by combining multiple actions into a single orchestrated call.

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

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

Explicitly instructs the agent to call every 30-60 seconds, provides conditional logic (e.g., 'skip warmups, pick the highest pot', 'if you're head bidder and timer>60s, sit'), and includes when-not-to-use scenarios. This gives clear decision 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?

Fully discloses key behaviors: one-time api_key display, non-reissuable key, need for funding. No annotations present, but description covers all needed 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?

Two sentences, front-loaded with the main purpose, no unnecessary words.

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

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

Complete for a registration tool: explains output handling and post-registration steps. No output schema 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?

Schema coverage is 100% and the parameter description in the schema is adequate. The tool description adds no extra meaning about the parameter.

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

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

The description clearly states the action ('Mint a new fomox402 agent') and the resource, with specific outputs (Solana address, api_key). It is distinct from sibling 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 clear steps after registration: save api_key and fund address. No explicit when-not or alternatives, but not necessary given the tool's uniqueness.

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. It discloses that the tool returns a secret for verifying deliveries via X-Signature header and mentions HMAC signing and SSRF safety. It does not cover rate limits or deletion, but the core behavioral aspects are adequately described.

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, consisting of two sentences that efficiently convey the tool's purpose, allowed events, URL requirements, optional parameter, and return value. No unnecessary words.

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

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

Given no output schema, the description explains the return value (a secret). It covers events, URL constraints, and optional gameId. However, the api_key parameter is unaddressed, and error handling is omitted. Overall, it is fairly complete for a subscription 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 only 25% (only url has a description). The description adds meaning to url (https+public IP), events (lists them), and gameId (optional scoping), but the api_key parameter is neither documented in schema nor mentioned in description, leaving a 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: subscribing a URL to receive HMAC-signed POSTs for specific chain events. It lists the event types and mentions optional gameId scoping, distinguishing it from sibling tools like delete_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?

The description provides context on when to use the tool (to be notified of outbid, bid_landed, settle, or dividend_accrued events) and specifies URL constraints (https, public IP, SSRF-safe). It does not explicitly state when not to use or mention alternatives, but the guidance is clear enough.

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

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

Despite no annotations, the description discloses key behavioral traits: operation type (self-refuel), delivered assets (SOL + token via Jupiter swap), rate limits (cooldown, lifetime cap), return shape, and rate-limit response handling (Retry-After). Missing detail on authorization requirements.

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 largely efficient, front-loading the main action and including important constraints. Slightly verbose with 'same shape as place_bid' but acceptable.

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?

Without output schema, the description explains return shape well. However, the missing parameter explanation and lack of details on required permissions reduce completeness for a one-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?

The input schema has one parameter (api_key) with no description. Schema coverage is 0%, and the description does not explain the parameter's purpose or source, leaving agents guessing.

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 identifies the tool as a self-refuel mechanism that sends a faucet drip (SOL + $fomox402) to the user's wallet, distinguishing it from sibling tools like withdraw or place_bid. It uses specific verbs and resources.

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 advises use when balance is low and specifies gating conditions (6h cooldown, 10 lifetime drips), but does not explicitly state when not to use or mention 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 carries full burden. It declares read-only and no auth required, but does not mention error responses or rate limits. However, the return type is fully listed, ensuring transparency for a simple GET 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 well-structured with clear sections (WHAT IT DOES, WHEN TO USE, RETURNS, RELATED). It is somewhat verbose but every sentence provides useful context. Minor redundancy with the lead sentence and the WHAT IT DOES line.

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

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

Given no output schema, the description lists all returned fields in the TowerFloor object. It also relates to sibling tools and the claim endpoint, providing a complete picture for a 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%, so baseline is 3. The description adds value by cross-referencing 'tower_floors' for obtaining the 'n' value, which helps the agent understand the parameter's provenance.

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 'Read full state of a single tower floor by index' and includes the HTTP method and path. It clearly distinguishes from sibling 'tower_floors' which is an index tool.

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

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

The description provides explicit when-to-use scenarios (after tower_floors to confirm details before claiming, and post-claim to verify ownership). It also references the claim 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 fully discloses behavior: read-only, no auth required, broker-cached ~5s, returns formatted table and raw JSON, and mentions the API endpoint. 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 sections but is somewhat verbose, repeating the purpose and including redundant details. Could be more concise while retaining 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?

The description covers all necessary aspects: what it does, when to use, return fields (including nested structure), and related tools. It compensates for the lack of an output schema by listing return fields.

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 2 parameters with 100% coverage in descriptions. The description adds value by stating default values for status (omit to return every floor) and tower_id (defaults to v0), and explains their purpose beyond the schema.

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

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

The description clearly states it lists tower floors with status and claim fee, and distinguishes from siblings by mentioning tower_floor_detail and tower_replay. The verb 'List' and resource 'FOMO Capital tower floors' are specific.

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

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

It provides explicit guidance on when to use (before tower_floor_detail or claim signing, and for passive scouting) and mentions related endpoints, but does not explicitly state when not to use or exclude 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 nature and no auth requirement. Describes pagination behavior and return format. Lacks mention of rate limits or error handling, but these are not critical for a read-only endpoint.

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-organized with labeled sections (WHAT IT DOES, WHEN TO USE, etc.). It is concise (6 short sections) and 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?

Even without an output schema, the description fully documents the return structure, pagination mechanism, and related tools. It provides sufficient context for correct invocation and workflow integration.

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 each parameter described. The description adds value by explaining the use of cursor pagination and the default for limit, which go beyond the schema.

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

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

The description clearly states the tool replays ordered tower events for a specific firm/game pair, with a specific verb ('GETs') and resource ('/v1/replay/firm/:firm/game/:game'). It distinguishes from siblings like tower_floors and firm_ingest.

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

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

Explicitly lists three use cases (rebuilding state, static summary, post-mortem) and contrasts with the SSE stream for live tailing. Names alternatives like tower_floors and firm_ingest.

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 covers key behaviors: asset types, lamport reserve for SOL, full ATA sweep for tokens, and api_key authority. Lacks details on failure modes but is adequate.

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-loaded with purpose, then specifics. 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 no annotations and no output schema, description covers essential behavioral context for a withdrawal tool. Minor omission of error handling, but sufficient for agent use.

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

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

Adds meaning beyond schema: explains 'asset' options, 'amountRaw' all behavior, and api_key authority. Schema covers 75% of parameter descriptions, and description fills gaps.

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 'Sweep the calling agent's Privy wallet to an arbitrary destination' with specific verb and resource. Distinguishes from sibling tools by focusing on fund movement.

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?

Explains when to use 'sol' vs token mint and behavior of 'all' for amountRaw. Mentions authority and blast radius, but no explicit when-not-to-use or alternatives.

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