Swarm0x

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context by specifying exact metrics and time windows (last hour, last day, per minute) plus the unique 'nest behind chain' measure, though it does not disclose return shape, gas price units, or data freshness.

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

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

A single compact sentence lists every available data point with no filler. Each metric earns its place, and the most prominent items are 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?

For a parameterless read-only snapshot tool, the description covers what data the agent will receive, including specific windows and units for ETH. Minor gaps like exact return structure or gas price unit prevent a 5, but nothing an agent needs to choose and invoke the tool correctly is missing.

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

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

There are zero parameters, so the schema already makes all parameter requirements explicit at 100% coverage; parameter-level description is unnecessary. Per the baseline for zero-parameter tools, this scores 4.

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

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

The description enumerates a specific set of current Robinhood Chain metrics (block time, gas price, eth in dollars, launches, graduations, trades per minute, nest lag), making the tool's purpose clear. However, it lacks an explicit verb such as 'get' or 'list' and does not name sibling alternatives, so it doesn't fully distinguish itself from related tools.

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

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

No explicit when-to-use or alternative routing is given, but the metric list and 'right now' title imply this is the snapshot tool for current chain-wide status. Since sibling tools like moving_now and graduating_soon cover related concepts, explicit exclusion or alternative guidance would have been valuable.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, so the simulation is non-destructive. The description adds valuable context: it simulates through real routers, so results reflect actual swap behavior, and clarifies the meaning of 'unknown' (not a pass). This goes beyond annotations and helps the agent avoid misinterpreting results. No contradiction with annotations.

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

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

The description is a compact paragraph that leads with the core question, explains the simulation method, and lists the output fields. It is informative without being verbose, though it could be slightly tighter by separating the output list. Overall, well-structured 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 covers the purpose, method, output structure, and interpretation of results (including the 'unknown' verdict). It explains the simulation's realism and the warning about not treating 'unknown' as a pass. No output schema exists, so the field list is helpful. It is complete for an agent to decide when to call and how to interpret the 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?

The single parameter (address) is fully documented in the schema with a regex pattern and description. The tool description does not add additional meaning beyond the schema, but with 100% coverage, the schema already provides sufficient semantics. 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's purpose: checking if a token can be bought and sold and the round-trip cost. It specifies the resource (token on Robinhood Chain) and the method (simulation via same routers as a wallet). It distinguishes itself from siblings by its explicit focus on pre-purchase validation rather than execution or other analytics.

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 as a pre-buy check: 'Check a token before buying' and warns 'It is not a pass: do not buy on it.' It gives context on how to interpret the verdict, but does not explicitly name alternative tools or when not to use it. Siblings like prepare_buy or simulate_transaction are not referenced, so a clear routing guideline is missing.

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

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

The description adds behavioral context beyond the annotations: it explains what happens when the rule is hit (sends to notify channel, kept in inbox) and requires a key, pointing to external docs. It also provides the grammar rules and examples, which are critical for correct invocation. Since annotations do not cover these details, this is valuable. No contradiction with annotations.

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

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

The description is moderately sized but efficiently structured: it opens with the core purpose and benefit, then details the grammar and examples, and ends with the key requirement. Every sentence adds value, and the grammar/examples are necessary for correct use. It is slightly longer than ideal but not 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 single parameter, the description provides the complete grammar, examples, and the requirement for a key. It also explains the post-condition (hit sent to notify channel and inbox). It does not describe the return value, but there is no output schema, so that is not expected. The description is sufficient for an agent to construct a valid rule and know the side effects.

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 schema describes the 'rule' parameter with a description pointing to the grammar, and the schema description coverage is 100%. However, the parameter description is minimal ('The rule, in the grammar above.'), and the actual grammar details are only in the tool description. The description adds the full grammar and examples, which is essential. Since the schema does not fully define the expected format, the description compensates, but it is not significantly beyond what a good schema could provide. 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 purpose: setting a standing rule that the nest watches for while the user is away. It specifies the resource (rule) and the action (sets), and provides the grammar and examples, which distinguishes it from sibling tools like 'list_rules' and 'delete_rule'. It is very specific and actionable.

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

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

The description explains the operational context: use it to stop polling and receive alerts on the notify channel, with reference to set_webhook. It does not explicitly contrast with siblings like 'list_rules' or 'delete_rule', but the context makes it clear this is for creating rules, and the mention of the notify channel is a clear usage signal. No exclusions are given, but the purpose is unambiguous.

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 says the tool 'drops' one of the rules, which is a destructive action, yet the annotations mark destructiveHint as false. This is a direct contradiction, and the description provides no additional detail about side effects, so the behavior is unclear.

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 lead with the action and object, and the documentation link is compact. It loses a point because the auth link is generic and requires navigation without indicating what about the key is needed.

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?

With one parameter, no output schema, and low conceptual complexity, the description is close to adequate: it names the id source and auth need. However, it omits what happens after deletion (confirmation/response) and leaves a contradictory destructive hint unresolved.

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%, but the description at least defines id as 'its id' and points to list_rules for finding valid ids. It doesn't clarify format limits or behavior with invalid/nonexistent ids, so it only partially compensates for the schema 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 gives a specific action (drops), a clear object (one of this mite's rules), and the selection method (by its id). It also points to list_rules, which distinguishes this deletion tool from the create_rule/list_rules/test_rule siblings.

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 tells the agent to obtain the target id via list_rules and states the auth prerequisite ('needs a key') with a documentation link. It doesn't state when not to use the tool or mention alternative deletion paths, but for this simple operation the context 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds output-content context but does not disclose additional behavioral traits like whether only certain transaction types are supported or how unknown hashes are handled. No contradiction with annotations.

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

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

The description is a single, front-loaded sentence with no filler. Every clause adds specific value: the chain, the plain-words output, and the concrete content of the explanation.

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

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

For a simple one-hash, read-only tool with strong annotations, the description covers purpose and output content well. It would be slightly more complete with a note about supported transaction types or behavior for unrecognized hashes, but those are 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?

The input schema fully documents the single parameter, hash, with a regex pattern and a clear description. With 100% schema description coverage, the tool description does not need to repeat parameter details, and the baseline of 3 applies.

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

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

The description states exactly what the tool produces: a plain-language explanation of a Robinhood Chain transaction, including who paid what, what they got, and the pool or curve involved. This clearly distinguishes it from siblings like simulate_transaction, which is for speculative future transactions, and wallet_history, which lists transactions.

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

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

The description implies the tool is for understanding what an existing transaction hash did, but it offers no explicit when-to-use or when-not-to-use guidance. It never mentions alternatives such as simulate_transaction or notes that this is not for simulating or listing historical activity.

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

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

Beyond the annotations, the description discloses the side effects: notifications are sent to a channel and records are kept in the inbox, and a key is required. This adds useful behavioral context without contradicting the readOnlyHint=false and destructiveHint=false annotations.

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

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

The description is short, front-loaded with the core action, and each sentence earns its place: what follows, what happens next, and what prerequisite is needed. No filler or 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 two-parameter tool with rich annotations and no output schema, the description covers the important context: purpose, side effects, and authentication requirement. It does not describe return values, but the lack of an output schema lowers that burden and the behavior is sufficiently explained.

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 schema already provides 100% description coverage for both parameters, so the baseline is 3. The description gives contextual meaning to the wallet address by explaining what following it triggers, but it does not add parameter-level details 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 states a specific verb and resource ('Follows a wallet') and clarifies exactly what that means: buys, sells, and launches are sent to the notify channel and kept in the inbox. This clearly separates it from related tools like wallet_history or unfollow_wallet.

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 intended use is clear: an agent should call this when it wants to receive ongoing wallet activity notifications. It also gives a concrete prerequisite by pointing to the docs for a key. It does not explicitly name alternative tools for when-not-to-use, but the context is strong enough.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds context about the data included (buys in the last ten minutes, deployer's record), which is useful but not behavioral detail like rate limits or output format. It does not contradict annotations.

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

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

The description is a single sentence that is concise and front-loads the primary purpose. It avoids unnecessary filler and is appropriately sized for a tool with no parameters. The structure is clear, though slightly run-on.

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?

With no parameters and no output schema, the description gives some indication of what results contain (tokens, buys, deployer record) but does not specify the shape, ordering, or whether it returns a list. Given the simplicity of the tool, this is adequate but leaves room for more precision about the return format.

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

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

There are zero parameters, so the schema is trivially covered. The baseline for 0 params is 4, and the description correctly avoids any parameter explanation since none exist.

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 resource (tokens on a curve) and the specific condition (closest to filling curve and opening a pool), and adds relevant details (recent buys and deployer record). It does not use an explicit verb like 'list' or 'get', but the intent is unambiguous. It is distinct from siblings by the 'graduating' focus, even without naming alternatives.

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 the many similar monitoring tools among siblings (e.g., moving_now, smart_money, signals). The description implies a use case but does not state conditions or exclusions. An agent would have to infer when 'graduating soon' is the right filter.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, covering the safety profile. The description adds value beyond annotations by stating the authorization requirement ('Needs a key') and the scoping to the current mite, which is 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?

Two sentences, both essential. The first sentence front-loads the core purpose and content; the second adds the auth prerequisite. No filler or repetition of annotations.

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 zero-parameter read-only tool with no output schema, the description covers the essential elements: what is returned, the time window, and the auth requirement. It does not describe the output format or ordering, and it does not address how this differs from 'signals', but these are minor gaps given 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 tool has zero parameters, so schema description coverage is vacuously 100% and the baseline is 4. The description does not need to explain parameters, and it adds incidental context about the implicit scope ('for this mite') rather than parameter syntax.

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 resource (alerts for 'this mite') and the time window (last seven days), and enumerates the included categories (rule hits, followed wallets moving, bag guard warnings). It lacks an explicit verb like 'list' or 'retrieve', and does not differentiate from sibling tools such as 'signals', but the purpose is 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 only guidance is the prerequisite 'Needs a key' with a documentation link. There is no statement about when to use this tool versus alternatives like 'signals' or 'my_bag', and no exclusions or conditions. The usage context is left entirely to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds valuable behavioral context by explaining the grouping logic (by funder) and the output concept (share of supply), which goes beyond the schema and annotations.

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

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

Two concise sentences with no fluff. The core action (identify launch buyers and group by funder) is front-loaded, and the output (share of supply) is stated clearly. Every word earns its place.

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

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

For a read-only tool with one parameter and no output schema, the description sufficiently explains what it does and what it returns conceptually. It could mention edge cases (e.g., if no bundles exist) or the exact return format, but given the annotations and simplicity, it is adequately 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% with a clear description of the address parameter (token contract on Robinhood Chain). The description does not add any additional meaning or constraints beyond what the schema provides, so it meets the baseline for high coverage but does not exceed 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?

The description clearly states the tool's function: it identifies wallets that purchased within the first three seconds, groups them by their funder to detect bundles, and reports the combined share of supply. This is specific and distinct from sibling tools like token_holders or wallet_history, which do not focus on launch timing or funder grouping.

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 analyzing launch activity and detecting bundles, but it does not explicitly state when to use this tool versus alternatives or provide exclusions. It gives clear context about the scenario (first three seconds) but stops short of contrasting with sibling tools.

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

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

Annotations already declare it as read-only, idempotent, and non-destructive. The description adds behavioral specifics beyond annotations: the ranking is based on profit from sells, requires a minimum of three sells, and operates on pretend ETH with real fills. This clarifies the exact data and rules the agent can expect.

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

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

The description is two sentences, information-dense, with no redundant wording. The core purpose and rules are front-loaded, making it easy for an agent to quickly grasp the tool's behavior.

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 listing tool, the description covers purpose, filtering criteria, and ranking logic. It does not describe the output format, but given the simplicity and the lack of an output schema, this is not a critical gap. The openWorldHint suggests the board may vary over time, which is implied by 'this week'.

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 'who' is fully described in the schema with enum values and a default (Everyone when left out). Schema coverage is 100%, and the description does not add additional semantic meaning beyond what the schema provides, so the baseline score of 3 applies.

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

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

The description clearly states the tool's function: it lists a practice league board ranking participants by profit from selling pretend ETH, with explicit criteria (only sells count, three or more sells). This distinguishes it from sibling tools like 'winners' or 'smart_money' by focusing on practice and specific rules.

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 conditions for listing (only sells count, three or more sells), which informs when this tool is relevant. It doesn't explicitly name alternatives, but the context is specific enough that an agent can infer when to use it, and the openWorldHint suggests it may reflect changing data.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the behavioral nuance of what 'linked' means (shared funder or co-trading within blocks), which is useful. It doesn't disclose output format or limits, but with annotations covering safety, 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?

One sentence, front-loaded with the resource, and every word earns its place. The two criteria are clearly separated with 'or'.

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

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

For a read-only lookup tool with one parameter and no output schema, the description is nearly complete. It could mention what the response looks like (e.g., list of addresses), but the annotations and simple schema make this 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?

Schema coverage is 100% and the only parameter 'address' is described as 'The wallet.' The description adds context that the wallet is the reference point for finding linked wallets, but doesn't add format details beyond the schema's regex pattern. 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 states a specific resource (wallets) and the relationship criteria (shared funder or trading same tokens within blocks), which clearly distinguishes it from generic wallet tools. It doesn't explicitly name a sibling alternative, but the criteria are specific enough to identify what the tool does.

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

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

The description implies when to use it: when you need wallets related to a given wallet by funder or co-trading behavior. It doesn't explicitly state when not to use it or name alternatives like wallet_history or follow_wallet, but the context is reasonably clear 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?

Annotations already cover readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is known. The description adds useful behavioral context by naming the supported channel types and noting that a key is required, which goes beyond the annotations. It does not contradict any annotation.

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 short sentences and includes the essential information: what the tool returns and the auth requirement with a documentation link. It is not verbose, though the phrasing 'The notify channels this mite has' is slightly awkward and could be more direct.

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 zero-parameter, read-only listing tool, the description is mostly complete: it names the possible channels and the key requirement. Since there is no output schema, it could better describe the response shape, but the core usage is clear enough for an agent to call the 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 zero parameters and schema description coverage is 100%, so the baseline is 4. The description has no parameters to clarify, and its mention of a key is an authentication requirement rather than a tool parameter, which 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 and title make clear that this tool lists the notification channels (telegram, discord, webhook) configured for the current mite, and the tool name 'list_channels' supplies the verb. It is distinguishable from siblings like set_webhook and remove_channel because it describes viewing existing channels, though it does not explicitly contrast itself with those alternatives.

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 no explicit guidance on when to use this tool versus alternatives such as set_webhook, remove_channel, or list_rules. The purpose is implied by the title, but there is no statement like 'use this to see current alert destinations' or 'use set_webhook to change them.'

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds the auth requirement ('Needs a key') and clarifies the response includes hit counts, which goes beyond the annotations without contradicting them.

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

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

Two short sentences earn their place: the first front-loads the resource and return contents, and the second provides the auth/docs link. There is no filler or repetition.

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 no-parameter listing tool, the description is sufficient: it states what is returned, whose rules are returned, and the key requirement via docs. The term 'mite' is assumed domain knowledge emerging from the community definition, and there is no output schema, so a couple of details are left implicit.

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?

This tool has zero parameters and the schema is fully covered at 100%, leaving no parameter semantics for the description to add. With 0 params, the baseline is 4.

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

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

The description clearly names the resource ('standing rules this mite has set') and the included data ('with how often each has hit'). It does not explicitly contrast with sibling rule tools like create_rule or delete_rule, so it stops just short of full differentiation.

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

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

The description implies this is the read/listing tool for standing rules, but it never states when to use it versus create_rule, delete_rule, or test_rule. The 'Needs a key' line adds a useful precondition, but the when-to-use context remains only implied.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds valuable behavioral context by explaining what each query type returns (token with check and holders, wallet with history, transaction with what it did) and warns that symbols can be copied, so the address in the answer should be trusted over the symbol. This goes beyond the annotations and enriches the agent's understanding of the tool's behavior.

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 long sentence that packs a lot of information: accepted input types, per-type behavior, and a caution about symbol ambiguity. It is efficient and front-loads the input types, though the density makes it slightly harder to parse. No wasted words, but it could benefit from breaking into clearer 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 tool with one parameter and no output schema, the description adequately explains what the tool does and what it returns for each input type, including a specific warning about symbols. It does not mention error cases or rate limits, but given the simplicity and the annotations covering safety, it is sufficiently complete for an agent to call it 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% because the single parameter 'query' has a description listing the possible inputs. The description adds meaning by elaborating on how each type is resolved and what the response contains. This goes beyond the schema's bare enumeration, so the description adds value without redundancy.

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

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

The description states a specific verb ('takes... and works out which it is') and a resource (token symbol, wallet name, address, or transaction hash), making it clear this is a general-purpose lookup tool. It distinguishes itself from sibling tools like check_token, wallet_history, and explain_transaction by handling multiple identifier types, so an agent can tell it apart without opening other schemas.

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

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

The description explains what the tool does but does not explicitly say when to use it versus specific sibling tools like check_token or wallet_history. It implies that this is for ambiguous queries, but it never names alternatives or conditions for choosing this tool over them. There is no explicit when-not-to-use guidance, leaving the agent to infer the appropriate context.

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

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

Annotations already show this is a non-read-only, non-destructive mutation. The description adds meaningful detail: the change is limited to the agent tag, nothing else is altered, and a key is required. It does not cover failure modes or permission nuances beyond the key requirement, but for a simple tag toggle that 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?

The description is four short sentences, each carrying distinct useful information: the core action, the limited side effects, the optional name format, and the key requirement with documentation link. It is front-loaded and contains no filler.

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 mutation with two optional parameters and no output schema, the description covers the purpose, side-effect scope, name constraints, and authentication prerequisite. The off behavior is documented in the schema, so nothing essential is missing for an agent to invoke the tool correctly.

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

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

The input schema already documents both parameters with 100% coverage, so the baseline is 3. The description adds value by clarifying that the name is optional and restricted to letters, digits, and spaces, which goes beyond the schema's maxLength constraint. The off parameter is already well explained in the schema.

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

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

The description names the exact action and resource: it marks the mite tied to the key as an AI agent, with the concrete outcome of carrying an agent tag on the league. It also explicitly scopes the effect by saying 'It changes nothing else,' which helps distinguish it from sibling tools that mutate league or wallet state.

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

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

The description gives clear context for when to use the tool: to mark a mite as an AI agent, and it includes the prerequisite that a key is needed. It does not explicitly list exclusionary cases or alternatives, but no sibling appears to target the same action, so the usage context 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?

Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds a useful behavioral detail beyond those annotations: pool tokens are included only after a simulated sell succeeds. This helps the agent interpret the result set correctly.

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 compact sentences: the first states the core selection criterion and scope, and the second adds the important pool-token caveat. There is no filler, 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 zero-parameter, read-only list tool, the description is largely complete: time window, scope, and inclusion rule are all covered. The lack of an output schema means exact ordering or return fields are unspecified, but the title and description make the list semantics clear enough.

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 zero parameters and full schema coverage, so there is nothing for the description to add about parameter semantics. It instead describes the selection logic, which is all that is needed here.

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 resource: tokens with the most money and wallet inflow over the last ten minutes, across all curves and pools. The title reinforces the real-time intent, though the description lacks a direct verb like 'list' or 'get' and does not explicitly contrast with sibling discovery tools.

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

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

The ten-minute window and chain-wide scope give clear context for when this tool is relevant. It does not name alternatives or state when not to use it, so it stops short of explicit routing guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds that a key is required and that it reports changes since purchase, which is useful behavioral context beyond annotations. No contradiction.

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

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

Single sentence that front-loads the main purpose (wallet holdings, gain/loss, changes) and provides examples. It is efficient, though the title 'What my wallet holds' is somewhat redundant with the description, but not problematic.

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 no-parameter, read-only tool, the description provides the essential information: what it returns and the requirement for a key. It could be more specific about output format or interpretation, but it is sufficient for an agent to call it correctly.

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

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

The tool has zero parameters, so the description does not need to explain parameter semantics. Baseline of 4 applies as the description correctly implies a read-only query with no input.

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 reports wallet holdings, gain/loss, and changes since purchase, with specific examples of changes. This is a specific verb-resource combination that distinguishes it from siblings like wallet_history or linked_wallets by focusing on the user's key's wallet.

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. It mentions a key requirement but does not provide context for selecting this tool over similar wallet-related tools, nor does it state exclusions or typical use cases.

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

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

Annotations already cover read-only, idempotent, non-destructive behavior. The description adds useful context beyond that: it names the returned fields and explicitly calls out that a key is required, which helps the agent understand authentication needs without contradicting the annotations.

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

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

Two short sentences, zero filler. The key information is front-loaded, and the documentation link is appended without diluting the main purpose.

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

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

Given the simple zero-parameter read-only nature, the description is nearly complete: it states what the tool returns and the authentication prerequisite. The only minor gap is leaving the term 'mite' undefined, though the docs link and sibling context mitigate that risk.

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 zero parameters, the schema has nothing to document, so the baseline is 4. The description appropriately notes that the key comes from context rather than as an input parameter, which is the only relevant parameter-related guidance needed.

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

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

The description clearly identifies the resource: the 'mite' or account behind the current key, and lists what it exposes (wallet, level, accuracy, limits). It lacks an explicit verb like 'retrieve' or 'show', but the meaning is unambiguous and distinct enough 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?

The description implies the use case: check what account is associated with the current key. It states the prerequisite ('Needs a key') but does not explicitly compare against alternatives or say when not to use it, leaving some routing to inference.

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

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

The description adds useful behavior beyond the annotations: this is a simulated/paper account ('pretend eth'), valuations are computed for the current block, and a key is required. The readOnly/idempotent annotations already cover the safety profile, so the added auth and simulation context earns high but not full credit.

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 definition is short and front-loads the account's contents before the key requirement. It is slightly telegraphic ('pretend eth left') and the lack of a verb makes it harder to parse, but no sentence is wasted.

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 zero-parameter read-only tool with no output schema, the description covers the key returned values and the access prerequisite. A slightly clearer statement of what is returned and an explicit read-only framing would make it 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?

The input schema has zero properties, and the 100% schema coverage makes parameter documentation unnecessary. Baseline for zero-parameter tools is 4; the description adds no conflicting parameter expectations.

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 defines the tool as the practice account for this mite and enumerates the exact data returned: paper ETH balance, held positions, per-position sell value for the block, and weekly profit. It is clear about the resource and contents, though it lacks an explicit verb such as 'get' or 'show' and does not contrast itself with practice_trades.

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 given about when to call this tool instead of practice_buy, practice_sell, or practice_trades. The only operational note is that a key is required, with a docs link, which is a prerequisite rather than a selection criterion.

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?

Even though annotations already mark it as non-read-only, the description adds substantial behavioral detail: the fill includes fees, tax, and price impact; the simulation runs against the current block state; accounts start with 1 practice eth; nothing real is spent; and the result indicates whether the buy could be sold straight back. No contradiction with annotations.

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

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

Four dense sentences with the core action front-loaded, followed only by behaviorally relevant simulation details and the key prerequisite. Every sentence earns its place with no filler.

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 two-parameter tool with no output schema, the description covers mechanics, pricing realism, account balance, safety, return information, and authentication. Nothing essential is missing for an agent to understand and invoke the tool correctly.

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

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

Schema description coverage is 100% and already documents the eth format, minimum amount, and token pattern. The tool description adds useful global context but no per-parameter meaning beyond what the schema already provides, 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 states a specific action ('buys a token') with a precise resource ('with pretend eth at the real price') and clarifies it is a simulation through the same route as a real trade. This clearly distinguishes practice_buy from siblings like practice_sell and prepare_buy.

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 intended context is clear: use it for a paper-trade buy with pretend eth, with no real funds spent. It also supplies a prerequisite (needs a key), but it does not explicitly name alternatives or state when not to use it.

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

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

The description adds the key requirement and the real-sellability constraint, which are not in the annotations. It also clarifies that it books profit or loss. However, it does not describe the full side effects or return behavior. Since annotations already indicate mutation (readOnlyHint=false), the description adds useful context beyond the structured fields.

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

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

The description is two sentences, front-loaded with the core action and result, followed by a constraint and a key requirement. There is no fluff or redundancy, 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?

The description explains the purpose and key constraints but does not mention the return value or any consequences beyond booking profit/loss. Since there is no output schema, the description should hint at what the tool returns, but it is absent. It also does not clarify prerequisites beyond the key. This is a gap for an agent to fully understand the tool's behavior.

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 fully describes both parameters with 100% coverage. The description adds no additional parameter-specific meaning; it only restates the general action. Thus, the baseline of 3 applies as the description does not exceed the schema's documentation.

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 sells a practice position at the real chain price and books profit or loss. It uses a specific verb and resource, and the constraint about tokens not sellable for real distinguishes it from real selling. It is distinct from practice_buy and prepare_sell by implying actual execution.

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 a partial usage condition (token must be sellable for real) but does not explicitly compare with alternatives like practice_buy or prepare_sell. The use case is implied by the name and the sibling context, but there is no explicit when-to-use versus other tools.

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

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

Annotations already cover the read-only, idempotent, open-world, and non-destructive safety profile, so the description is free to add other useful behavioral context. It adds that a key is required for access, that only the 'last' practice trades are returned, and that sell profit is included in the results, which goes beyond what the annotations state.

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

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

The description is two sentences with no filler. The first sentence states the purpose and output content, and the second gives the essential auth prerequisite. It is front-loaded and 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?

For a zero-parameter, read-only listing tool with strong annotations, the description is nearly complete: it names the returned data (last practice trades and sell profit) and the auth requirement. It could be more explicit about what 'this mite' refers to or what other fields are returned, but those are minor gaps given the overall simplicity of the 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?

This tool has zero parameters, so the schema has no information for the description to compensate for. The 'needs a key' note is about authentication rather than a tool argument, which is appropriate here.

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 resource ('practice trades') and conveys that this returns the most recent ones along with the profit from each sell. It lacks an explicit verb like 'list' or 'get', and it does not explicitly distinguish itself from sibling tools such as practice_account, practice_buy, or practice_sell, but the intended meaning is still clear.

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

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

The description provides no guidance on when to use this tool instead of alternatives like practice_buy, practice_sell, or practice_account. The only usage-related note is the authentication requirement ('Needs a key'), which is necessary but does not help an agent choose between this and sibling 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?

Beyond the readOnlyHint, the description discloses exactly what happens: the nest holds no keys, sends nothing, finds the trading venue, rehearses the buy, sets a minimum fill, proves sellability, and returns unsigned steps in execution order. It also covers failure modes (refused if unsellable or half lost) and the meaning of an 'unknown' verdict. This is far more transparent than the annotations alone.

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 dense and covers many facets, but each sentence adds value: purpose, safety, process, execution instructions, refusal condition, amount semantics, and verdict warning. It is longer than typical descriptions, but the complexity of the tool justifies the length. The most important info is front-loaded.

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

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

With no output schema, the description carries the burden of explaining the return: steps to sign, venue.pays, refusal behavior, verdict levels. It covers what an agent needs to call the tool and interpret a result. Minor gaps remain, such as the exact shape of the returned steps, but the guidance to sign and send in order to chain id 4663 is sufficient 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?

The schema already documents all 5 parameters with full coverage. The description adds essential meaning to 'amount' by explaining what unit it is in and how to interpret it via 'venue.pays' (eth, usdg, weth). It also ties slippageBps to the 'least amount the swap will accept' behavior. This goes beyond the schema's per-parameter 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 opening sentence states a specific verb and resource: 'Writes a buy as unsigned transactions for your own wallet to sign.' This clearly differentiates it from a normal trade execution or a practice simulation. The scope ('for your own wallet', 'The nest holds no keys') further pins down what the tool does.

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

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

The description does not explicitly name alternatives or say when not to use this tool. However, it strongly implies the use case: you want to buy a token and sign the transactions yourself, because the nest holds no keys and sends nothing. The rehearsal and sell-back details give context, but there is no comparison with siblings like practice_buy or prepare_sell.

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

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

The description adds significant behavioral detail beyond annotations: 'The nest holds no keys and sends nothing,' 'reads what the wallet holds, leaves out any approval the wallet has already given, rehearses the rest from your wallet in a simulation,' and sets the minimum acceptable amount. These explain the read-only, idempotent nature consistent with annotations.

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

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

The description is slightly long but each sentence adds value: purpose, safety, process, and usage options are all covered. It is front-loaded with the core action and structured logically.

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?

With no output schema, the description implies the return (unsigned transactions) and explains key behaviors like simulation and slippage. It covers all parameter usage and edge cases (existing approvals, 'all' amount) sufficiently for an agent to invoke it correctly.

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

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

Schema coverage is 100%, so all parameters have descriptions. The description adds practical guidance for amount ('all' or plain number) and percent, clarifying the choice between them. This goes beyond schema to improve selection.

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

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

The description states a specific verb and resource: 'Writes a sell as unsigned transactions for your own wallet to sign.' It clearly distinguishes from prepare_buy and practice_sell by focusing on real sells and unsigned transactions. The phrase 'the way out' reinforces its purpose.

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

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

The description implies usage (when you want to sell) and clarifies that a sell is always written regardless of token checks, but it does not explicitly name alternatives or when not to use this tool. It provides context but lacks explicit exclusion guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds context about the returned data (flags, mite, timing) and clarifies that receipts are not verdicts. However, it doesn't disclose any additional side effects, rate limits, or output format beyond what annotations imply. Since annotations carry the safety burden, a 3 is appropriate.

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 compact, with the core purpose front-loaded ('Receipts: flags...'). It uses domain jargon (runs, drains, mite) that may require prior knowledge but is efficient. Each sentence contributes to clarifying purpose, usage, and differentiation. Slightly longer than necessary but 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 read-only tool with one optional parameter and no output schema, the description covers the essential: what it returns, the optional parameter effect, and a pointer to check_token for verdicts. It does not elaborate on the meaning of 'mite' or 'runs/drains/dead', but these are likely domain-specific terms. Overall, it provides sufficient information 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?

The input schema describes the 'address' parameter as an optional token contract. The description adds crucial semantics: providing the token returns that token's receipts and waiting flags, while omitting it returns the latest across the chain. This meaningfully extends the schema's simple description, helping the agent understand the parameter's impact.

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

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

The description states a specific action (flags receipts that proved right) and identifies the resource (chain) and the optional token scope. It explicitly differentiates itself from check_token by clarifying that receipts are historical records, not current verdicts. This makes the purpose unambiguous and distinguishes it from siblings.

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

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

The description provides clear context for when to use this tool (to see historical correct calls) and explicitly points to check_token for current verdicts, giving a conditional alternative. It also explains the optional token behavior (provide for specific token, omit for latest across chain). While it doesn't enumerate all alternatives, the key distinction is covered.

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

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

Annotations already indicate readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true. The description adds that a key is needed and that the channel is identified by id, but it does not disclose what 'removing' entails (e.g., whether it is reversible, whether it affects notifications immediately, or what happens if the id does not exist). No contradiction with annotations.

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

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

The description is two sentences with no wasted words. The core action and the prerequisite (key) are stated efficiently. The link to docs is a minor addition but useful.

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 tool with no output schema, the description covers the essential action and the source for the id. However, it lacks details about the effect of removal, error cases, or whether the operation is reversible. Given the annotations provide some context (not read-only, not idempotent, not destructive), the description is adequate but not 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 description coverage is 0%, so the description must compensate. It explains that 'id' is the notify channel id and points to list_channels for obtaining it, which adds meaning beyond the schema's bare integer type. However, it does not specify the id format beyond the schema's minimum:1 constraint, and there is only one parameter, so the compensation is partial.

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

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

The description states a specific verb ('Removes') and resource ('notify channel by its id'), and references list_channels for finding the id. It is clear what the tool does, though it doesn't explicitly distinguish it from sibling tools beyond the reference to list_channels.

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 context: you need the id from list_channels and a key from the docs. It does not explicitly state when to use this tool versus alternatives, but the reference to list_channels provides some routing guidance. No exclusions or alternative tool names are given.

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

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

Beyond the annotations (readOnlyHint=false, etc.), the description discloses key behaviors: test delivery before saving, saving nothing on failure, the one-time presentation of a secret, and the exact signature verification process (x-swarm0x-sig as sha256=hex(hmac_sha256(secret, body))). These details add significant value beyond the hint annotations.

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

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

The description is three sentences, front-loading the purpose and then adding necessary behavioral details. It includes technical verification details that are essential given no output schema, but remains reasonably compact. Each sentence contributes distinct information.

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

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

For a mutation tool with no output schema, the description covers the response's key element (the one-time secret) and failure behavior. It also provides a prerequisite (key) with a link. Missing details like full response format or error cases are minor given the tool's simplicity and the annotations.

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 the schema already documents the `url` parameter with constraints (https, answers 2xx to POST). The description does not add further parameter-specific semantics; it mentions the URL receives JSON but does not elaborate on URL formatting or edge cases. Baseline 3 is appropriate given full 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?

The description clearly states a specific verb and resource: 'Sends every alert for this mite to an https url as json'. It enumerates the payload fields and distinguishes this from sibling tools by focusing on webhook delivery, which is unique among the listed siblings.

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 some usage context, such as 'The nest makes one test delivery first and saves nothing if it fails' and 'Needs a key' with a docs link. However, it does not explicitly mention when to use this tool versus alternative notification methods or exclude any scenarios, leaving usage guidance implied rather than explicit.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds contextual detail about the type of anomalies but does not disclose return format, pagination, or any other behavioral nuance. It neither contradicts annotations nor enriches them significantly.

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, compact sentence that front-loads the core function ('Odd things from the last hour on Pons launches') and then lists illustrative examples. There is no redundant or verbose language.

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?

With no output schema and no parameters, the description should convey what the tool returns. It lists anomaly categories but does not specify the output structure (e.g., list, count, details). This leaves some ambiguity for an agent expecting to consume the results, though the read-only nature and zero inputs reduce the risk of misuse.

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 zero parameters, so schema coverage is trivially 100%. Per calibration, a baseline of 4 applies since there are no parameters to describe; the description does not need to elaborate on inputs.

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 surfaces 'odd things from the last hour on Pons launches' with specific examples (insider selling, liquidity leaving, serial launcher, large burn). It conveys a distinct purpose of anomaly detection, though it does not explicitly differentiate from siblings like smart_money or moving_now, which could overlap in intent.

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 temporal context ('last hour') but offers no guidance on when to use this tool versus alternatives. There is no mention of when not to use it or which sibling tools would be more appropriate for related queries, leaving the agent to infer its place.

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

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

Annotations already mark it read-only, idempotent, and non-destructive, and the description reinforces and extends this with operational detail: no gas cost, balances read rather than logs, spending-rights disclosure, sell-back and round-trip loss analysis, router/contract agnosticism, and the meaning of an 'unknown' verdict. It also adds the important caveat that an 'unknown' verdict is not a pass.

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 dense but every sentence earns its place: it front-loads the core action, then covers safety, outputs, edge cases, and the critical warning. The structure flows naturally from what it does to what it returns to how to interpret the result.

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

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

Despite having no output schema, the description explains the return shape (JSON with verdict code, level, text) and the meaning of 'unknown'. It covers what the simulation reveals, what it cannot determine, and what not to do with the result, making it complete for an agent to use correctly.

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

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

Schema description coverage is 100%, so the baseline is 3 and the schema already documents each parameter. The description adds general context around what the simulation reports, but does not add parameter-level meaning beyond the schema, such as additional detail on 'fund' or 'calls'.

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?

States a specific verb and resource: it runs a transaction in a simulation before signing, with explicit scope ('from your own wallet as it stands right now'). It clearly differentiates itself from real execution by saying nothing is sent and nothing costs gas, which distinguishes it from signing or broadcast tools.

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

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

The description establishes clear context: this is for a transaction you are about to sign, and it explicitly warns the result is not a pass and should not be used to buy. It does not name alternative sibling tools or give explicit when-not-to-use scenarios, but the pre-signing context is clear.

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

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

Annotations already cover readOnly, idempotent, and non-destructive behavior. The description adds useful behavioral context: it filters by token, restricts to winning wallets, and computes the best trade per wallet. No contradictory or surprising behavior is disclosed.

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

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

The description is a single, well-structured sentence with no filler. It front-loads the core question—winning wallets holding the token—and follows with the additional output detail about the best trade. Every part earns its place.

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

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

For a one-parameter read-only tool, the description gives enough context: it names the input, the subset of wallets, and the per-wallet output. Minor ambiguity remains around the exact meaning of 'best trade' (e.g., by profit, ROI, or size) and how results are ordered, but nothing critical is missing.

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 schema fully documents the single address parameter, including its checksummed Ethereum-style pattern and that it represents a token contract on Robinhood Chain. The description only references 'this token' and adds no further parameter-specific semantics, 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 a specific function: identify winning wallets that hold a given token and return each wallet's best ever trade. This distinguishes it from sibling tools like token_holders (all holders) and winners (all winning wallets). The resource and query scope are explicit.

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 makes the use case clear: pass a token address to find winning wallets holding it and their best trade. It does not explicitly name alternatives or exclusions, but the token-specific intersection is strongly implied by the wording, giving clear context without needing further inference.

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

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

Annotations already convey read-only, idempotent, open-world, and non-destructive behavior. The description adds valuable behavioral context beyond that: the Chainlink feed incorporates dividends and splits, and the feed steps at half a percent, making sub-threshold gaps noise. This helps an agent interpret results correctly.

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, each earning its place: the first front-loads the full set of returned data, the second explains parameter-driven behavior, and the third surfaces a useful precision caveat. There is no fluff or repetition.

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

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

For a read-only list/detail tool with one optional parameter, the description covers the returned data points and the symbol behavior adequately. There is no output schema, but the description lists the key fields. It stops short of providing exact response field names or a concrete example, which would make it 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?

The input schema already documents the only parameter, symbol, with a clear example and the explicit 'leave it out' behavior, giving 100% schema description coverage. The description reinforces this by saying 'With a symbol, one stock in detail,' but it does not add meaningful semantics 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 identifies the resource (Robinhood stock tokens on-chain) and enumerates the returned data: last trade price, Chainlink share price with adjustments, the gap, and volume. It lacks an explicit verb like 'list' or 'get', and it does not differentiate the tool from siblings, but the intent is still unmistakable.

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 concrete invocation guidance: 'With a symbol, one stock in detail. Leave it out for every stock traded today.' This tells an agent exactly how to control the output. However, it does not compare this tool to alternatives or explain when not to use it.

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

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

Annotations already declare readOnly, idempotent, and non-destructive behavior, and the description adds that this is a simulation without side effects, what data it reports, and that it needs a key with a docs link. This gives an agent behavioral and auth context beyond the structured fields.

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

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

Two short sentences carry action, output, use case, and auth requirement, with no filler or redundancy. The key information is front-loaded.

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

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

For a single-parameter, read-only simulation tool the description is sufficient: it explains what happens, what the agent will see, why to call it, and the auth prerequisite. With no output schema, the description's summary of return values is especially valuable and it is present.

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

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

The sole parameter 'rule' is fully documented in the schema ('The rule to try'), and the description reinforces it by talking about testing a rule, but it does not add syntax or format details. With 100% schema coverage, this meets the baseline without needing extra compensation.

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 names the specific action (replays the last seven days against a rule) and the delivered results (how often it would hit, last ten hits), and explicitly says it does not set the rule — distinguishing it from sibling create_rule. The title reinforces the purpose, but the description alone is sufficient.

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

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

The phrase 'Use it to see how noisy a rule is first' gives a concrete use case, and 'without setting it' implies this is a safe pre-check before creating a rule. It does not explicitly name create_rule as the follow-up alternative, 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: the tool reads from the chain back to the token's first block, and it may return a 'reading' status requiring a retry. This async behavior is not in the annotations and is critical for correct invocation. The description doesn't mention rate limits or data volume, but the async retry note is a significant transparency win.

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 compact and front-loaded: it states the core output first, then the async behavior. Every sentence earns its place. The retry instruction is placed at the end, which is logical since it's a secondary but important detail. No fluff or repetition.

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

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

For a read-only, single-parameter tool with full schema coverage and no output schema, the description is nearly complete. It explains what data is returned, the source (chain back to first block), and the async retry behavior. The only minor gap is that it doesn't specify the exact response format beyond 'Returns json' and the 'reading' status, but since there's no output schema, a bit more detail on the JSON structure could help. Still, the description is sufficient for an agent to call and interpret the 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?

Schema description coverage is 100%, so the schema already documents the single 'address' parameter. The description adds context that the address is a token contract on Robinhood Chain, which reinforces the schema's pattern. However, it doesn't add new semantic details beyond what the schema provides (e.g., no mention of checksum format or how to obtain the address). Baseline 3 is appropriate given full 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?

The description clearly states the tool's purpose: identifying top holders of a token, with specific attributes (wallet age, entry, launch bundle, snipers, deployer, winning wallets). It distinguishes itself from siblings like check_token or smart_money by focusing on holder analysis. The verb 'returns' and resource 'top holders' are specific and unambiguous.

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

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

The description implies when to use this tool: when you need holder distribution and wallet-level insights for a token. It doesn't explicitly name alternatives or exclusions, but the detailed scope (holders, snipers, deployer) makes the use case clear. The async note ('ask again half a minute later') provides practical usage guidance. However, it doesn't explicitly contrast with sibling tools like smart_money or winners, which could overlap.

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

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

Annotations provide readOnlyHint=false, destructiveHint=false, and openWorldHint=true. The description adds the authentication requirement ('Needs a key') and links to docs, which is useful behavioral context. However, it doesn't disclose side effects or behavior beyond that, such as what happens if the wallet isn't being followed. No contradiction with annotations.

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

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

The description is two short sentences with no fluff: it states the purpose first and then the key requirement. It is well-front-loaded and every word earns its place.

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

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

For a simple one-parameter tool, the description provides the core purpose and the authentication requirement. However, it lacks guidance on when to use it (e.g., only if currently following) and doesn't mention any return behavior or potential errors. Given the simplicity and the annotations, it's adequate but could be more 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?

The input schema has one parameter 'address' with description 'The wallet.' and a pattern for Ethereum addresses. Schema coverage is 100%, so the parameter is documented. The tool description adds no additional parameter details, so it relies entirely on the schema. Baseline 3 is appropriate.

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

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

The description clearly states the action: 'Stops following a wallet.' The verb and resource are specific and unambiguous. It doesn't explicitly differentiate from siblings, but the inverse relationship to follow_wallet is evident from the name and title, so it's clear but lacks an explicit distinguishing statement.

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 given on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., must currently be following the wallet) or cases where it should not be used. The only extra instruction is about needing a key, which addresses authentication rather than usage context.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description need not repeat safety. It adds a summary of the data categories returned but does not disclose extra behavioral traits like rate limits, auth requirements, data freshness, or pagination. This is consistent but not additive beyond the annotations.

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

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

The description is a single, concise sentence that front-loads the resource ('A wallet:') and lists the key data categories. It is efficient and to the point, though some phrases like 'how those tokens ended' are mildly vague and could be tightened.

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

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

For a simple read-only tool with one parameter and no output schema, the description provides a reasonable overview of what the tool returns (age, funder, launches, token outcomes, trading record, holdings). It does not mention any limitations or caveats (e.g., time range, network scope), but the annotations cover safety and the tool is simple enough that this is sufficient.

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

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

Schema coverage is 100% and the only parameter (address) is already described in the schema as 'The wallet' with a precise pattern. The description does not add any parameter-specific meaning, so the baseline of 3 applies.

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

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

The description clearly states the tool's scope: it examines a wallet's history including age, funders, launches, token outcomes, trading record, and holdings. This is specific and distinguishes it from sibling tools like follow_wallet (subscription) and smart_money (top traders), even without naming them.

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 given about when to use this tool versus alternatives. It neither names sibling tools nor states conditions for choosing this over follow_wallet, linked_wallets, or smart_money. The usage is only implied by the description.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, covering the safety profile. The description adds the qualitative threshold ('enough people') but does not disclose other behavioral details like sorting, pagination, or return format. Given annotation coverage, a 3 is appropriate as it adds some context but not rich behavioral depth.

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

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

The description is a single, well-structured sentence that front-loads the main subject and criterion. Every word earns its place, and there is 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?

For a simple, parameterless tool with annotations covering safety and no output schema, the description adequately conveys what the tool returns. It could specify what 'enough people' means, but that is a minor gap given the simplicity and annotation coverage.

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 zero parameters, the schema coverage is 100% trivially, and there is nothing for the description to clarify about parameters. Baseline for 0 params is 4, and the description does not need to add parameter semantics beyond that.

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

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

The description states the resource (wallets) and the criterion (consensus on name or mark), making the purpose clear. It does not explicitly differentiate from siblings, but the specific consensus criterion provides enough distinction for an agent to infer when to use it.

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

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

The description implies the tool should be used when an agent needs wallets that have achieved consensus naming or marking. However, it offers no explicit when-not guidance or mentions of alternative tools, leaving usage context to be inferred from the sibling list.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds an important behavioral nuance: it only counts wallets that have sold out of tokens, which is not inferable from annotations. It does not disclose any additional side effects or limitations, but given the read-only nature, this is sufficient.

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, front-loaded sentence that leads with the core purpose, then adds relevant detail on output and the counting rule. There is no redundancy or filler; every clause contributes value.

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

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

For a simple, read-only list tool with no parameters and no output schema, the description fully covers what it does, what data it returns, and the key condition for inclusion. Nothing an agent needs to decide whether to call it is missing.

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 zero parameters and an empty schema with 100% coverage, so the baseline is 4. There is nothing for the description to explain about parameter syntax or meaning; it simply describes the fixed output criteria.

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

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

The description clearly states the tool lists wallets that closed the most profit in the last 24 hours, specifying the resource (wallets), action (closed profit), and time window. It also details the output fields (profit taken, win rate, biggest win) and a key condition (only sold-out tokens count), distinguishing it from sibling tools like smart_money or wallet_history.

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 a clear use case (finding top profit-taking wallets) and even provides a filtering condition (only tokens a wallet has sold out of). However, it does not explicitly state when to use this tool versus alternatives or mention exclusions, leaving the agent to infer its niche from the name and content.

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