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

With no annotations, the description carries the full burden of behavior disclosure. It explains the calculation scope, level/IV constraints, and the shadow modifier behavior. It does not detail the return structure, but the core behavioral traits of this pure-calculation tool are well communicated.

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 compact sentences with no filler. The main purpose is front-loaded, and the shadow behavior is added in a single follow-up sentence. Every sentence contributes useful 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 6-parameter calculator with no output schema and no annotations, the description is mostly complete: it defines inputs, ranges, and shadow behavior. It could be more complete by describing the output format and the expected pokemon identifier format, but the core calling contract is sufficiently clear.

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 add meaning. It does: level is 1.0-50.0 in 0.5 increments, IVs are 0-15, and shadow=True applies Shadow modifiers. The pokemon parameter is not format-specified beyond the schema title, leaving some ambiguity.

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 computes CP and actual Attack/Defense/HP for an exact IV spread at a given level. It also specifies the level and IV range, which distinguishes it from sibling calculation tools like calculate_powerup_cost and calculate_move_damage.

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: compute exact CP/stats for specific IVs and levels, with shadow handling via a boolean flag. It does not explicitly name alternatives or say when not to use it, but the exact-IV framing and sibling tool names provide enough contextual 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?

With no annotations provided, the description carries the full behavioral disclosure burden. It discloses that the calculation is deterministic, single-hit, and does not simulate a full battle, and it enumerates the multipliers involved. It does not discuss side effects, but this is a calculation tool where no meaningful side effects are expected.

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 core purpose is front-loaded in the first sentence, and every additional sentence adds useful disambiguation or parameter clarification. There is no filler or redundant restatement of the tool name or schema.

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 13-parameter tool with no annotations and no output schema, the description gives a solid orientation: what the tool computes, what it does not do, and how the less obvious optional parameters are encoded. Minor gaps remain, such as a full list of allowed weather condition IDs and an explicit description of the return shape, but these are not blockers for correct use.

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

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

The input schema has 0% description coverage, so the description must compensate. It adds useful semantics for weather, mega_boost_types, and friendship_level, and implies dodging through the multiplier list. However, 13 parameters exist and several parameters such as attacker_shadow, defender_shadow, attacker_level, IVs, and the basic attacker/defender/move meanings are left to inference from their names.

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 opens with a concrete action and resource: 'Damage for one hit of `move` ... against `defender`' and further specifies the output as a full multiplier breakdown. It also explicitly distances itself from a battle simulator, which distinguishes this from a full-fight or broader simulation tool.

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

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

The description clearly defines the scope: a single deterministic hit, not a full fight, and says when optional inputs should be omitted. It does not explicitly name sibling tools as alternatives or state when to use calculate_cp/calculate_powerup_cost instead, so it falls short of a fully explicit routing guideline.

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

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

With no annotations provided, the description carries the full burden. It discloses that cost is species-independent, explains the surcharge/discount logic for Shadow/Purified/Lucky, and clarifies the exclusivity of Shadow vs Lucky/Purified. This is strong behavioral context beyond what the schema provides, though it doesn't mention edge cases like level caps or whether Candy XL is always included.

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 dense paragraph that front-loads the core purpose and then explains modifiers. Every sentence adds value, though the modifier rules could be slightly more structured. It's appropriately sized for the complexity of the tool.

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

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

Given the tool's moderate complexity (5 params, no output schema, no annotations), the description covers the key behavioral rules and parameter semantics. It doesn't mention return value structure or level constraints, but the core information an agent needs to invoke the tool correctly 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?

Schema description coverage is 0%, so the description must compensate. It explains the meaning of current_level and target_level implicitly, and explicitly explains the semantics of the lucky, shadow, and purified boolean flags, including their interactions. It doesn't detail the format of the level numbers (e.g., 0.5 increments), but the core parameter meanings are well covered.

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 ('calculate') and resource ('power-up cost'), and clearly defines the inputs (current_level, target_level) and outputs (Stardust/Candy/Candy XL). It distinguishes itself from siblings like calculate_cp and calculate_move_damage by focusing on power-up costs.

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 cost model's independence from species and details the modifiers for Shadow, Purified, and Lucky, which tells the agent when to set those flags. It doesn't explicitly name alternative tools or state when not to use this tool, but the context is clear enough for an agent to select it for power-up cost calculations.

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

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

With no annotations provided, the description carries the responsibility for disclosing behavior. The verb 'Report' signals a read-only observation, and the description explicitly discloses the fallback-to-cache behavior, which is a non-obvious behavioral trait. It could additionally state that no data is mutated or refreshed, but the description is reasonably transparent.

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

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

One sentence, front-loaded with the main purpose, listing all status dimensions without redundancy. Every clause 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-argument status tool with no output schema, the description conveys the full conceptual payload: freshness, validation, size, and fallback state. It doesn't define the units or exact format of size/freshness, but those are return-format details the agent can discover from the actual response.

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 takes zero parameters and the schema coverage is trivially complete, so there are no parameter semantics the description must clarify. Per the rubric baseline, 4 is appropriate because there is nothing missing.

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 opens with a specific verb ('Report') and names the resource ('currently served data snapshot') plus the specific status dimensions reported: freshness, validation status, size, and cache fallback. This makes it easy to distinguish from sibling data-query tools like get_pokemon and from refresh_data, which performs an update rather than reporting status.

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 intended use clear by framing the tool as a status reporter for the served snapshot, and the phrase 'after a failed refresh' implies a useful condition for checking it. It does not name sibling alternatives such as refresh_data or explicitly state when not to use it, so it falls just short of a 5.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It explicitly warns that PvE and PvP fields are separate and should never be mixed, which is a critical behavioral trait. It also notes that PvP fields are only present when the move has them. This is valuable context beyond the schema.

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

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

The description is compact and front-loaded. The first sentence states the action and examples; the second adds the critical PvE/PvP separation warning. 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 single-parameter lookup tool, the description covers the key aspects: what it does, what the parameter accepts, and the important PvE/PvP distinction. It doesn't describe return format, but with no output schema and a simple lookup, the core usage is well covered. The warning about not mixing fields is particularly important for an agent.

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

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

Schema coverage is 0%, so the description must compensate. It does: it explains the 'query' parameter accepts either a display name ('Psycho Cut') or an internal ID ('PSYCHO_CUT_FAST'), giving concrete examples. This adds meaning beyond the bare schema property.

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: 'Look up one move by name or internal id' with concrete examples. It distinguishes itself from sibling tools like search_moves by specifying it retrieves a single move by exact identifier rather than searching.

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 have a specific move name or ID and need its details. It doesn't explicitly say 'use search_moves when you don't know the exact ID,' but the contrast with search_moves is clear from the sibling context and the 'look up one move' phrasing.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It discloses that elite moves are included and that they require a TM/Elite TM, which is useful. However, it does not mention whether the tool is read-only, how 'battle form' is determined, or what happens if the Pokemon is invalid. The description adds some behavioral context but not comprehensive detail.

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 front-loads the core purpose and includes the key caveat about elite moves. It is concise and readable, though the line break in the middle is a minor formatting artifact. No wasted words.

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

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

For a simple one-parameter tool, the description covers the main purpose and the elite-move caveat. However, it lacks guidance on the expected input format for 'pokemon' and does not describe the output structure (no output schema exists). Given the sibling tools and the need to resolve moves, a bit more context about input format and return shape would make it complete.

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

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

Schema description coverage is 0%, so the description must compensate for the single 'pokemon' parameter. The description says 'for one Pokemon battle form' but does not explain what format the pokemon string should take (e.g., name, ID, form suffix), nor does it clarify how to specify a battle form. This is a significant gap for a tool with one undocumented parameter.

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

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

The description states a specific verb ('get') and resource ('moveset for one Pokemon battle form'), and clarifies that it resolves to full move records. It distinguishes itself from siblings like get_move and search_moves by focusing on a Pokemon's moveset rather than individual moves, though it doesn't explicitly name a sibling alternative.

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: it is for retrieving all legal PvE moves for a single Pokemon battle form. It does not explicitly state when to use this tool versus alternatives like get_pokemon or search_moves, nor does it mention exclusions or prerequisites (e.g., needing a specific form name).

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

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

With no annotations, the description carries the behavioral disclosure burden. It explains the key non-obvious behavior: multiple matching forms return a structured ambiguous_pokemon error listing candidates instead of guessing. It does not cover not-found behavior or response shape, but it does address the main edge case.

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, front-loaded with the action and example forms, followed by the important ambiguity caveat. Every clause earns its place; there is 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 one-parameter lookup with no output schema and no annotations, the description is nearly complete: input semantics and the main edge case are covered. The absence of explicit alternative routing and any success/not-found response details are minor 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 schema only provides a bare 'query' string with 0% descriptive coverage, and the description fully compensates. It specifies that query accepts battle form names or internal ids, with examples including special forms and internal constants.

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

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

The description uses a specific verb ('look up') and resource ('Pokemon battle form'), and clarifies that it returns exactly one form by name or internal id, with concrete examples. This clearly distinguishes it from search_pokemon by emphasizing a single canonical lookup.

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 precise lookup use case: the caller already has a name or internal id, and ambiguous matches produce an error rather than guesses. It does not explicitly name search_pokemon or state when to prefer it, so it stops short of full 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?

With no annotations provided, the description carries the full burden and discloses a concrete failure mode: the previously-served snapshot keeps being used and the error surfaces via get_data_status.last_refresh_error. It also conveys that this is an active force operation rather than a passive read, though it does not describe the success return.

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 crisp sentences with no wasted words. The action and pipeline are front-loaded, and the failure-behavior 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, no-annotation tool, the description covers the operation, the failure fallback, and where to observe errors. It omits the success return value, but the core invocation context is sufficiently 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?

This is a zero-parameter tool, so the baseline is 4. There are no parameters needing explanation, and the description does not add redundant or conflicting parameter information.

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 an explicit action ('Force') on a specific resource: a fetch/normalize/validate/promote cycle against the upstream provider. This clearly distinguishes refresh_data from the sibling query/calculation 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?

Implies usage when an immediate refresh is desired, but does not explicitly state when to choose it over alternatives or when it should be avoided. The pointer to get_data_status for failure reporting provides some routing context, but there is no direct when/when-not 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?

The description carries full behavioral burden because no annotations are provided. It discloses only that the search is substring-based and targets display names; it says nothing about read-only behavior, result shape, limit application, case sensitivity, or edge cases. This is a thin behavioral profile for an agent relying solely on the description.

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. Its one sentence clearly conveys the core operation and matching behavior, making it efficiently scannable for an agent.

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

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

For a basic search tool, the description covers the operation and the key query behavior, and the schema supplies the parameters. However, there is no output schema and no mention of what results contain or how the limit affects them, leaving some ambiguity about the tool's full call contract.

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 tool description must compensate. It clarifies that the 'query' parameter is matched as a substring against move display names, which adds real meaning. However, it does not explain the semantics of the 'limit' parameter beyond the schema default, so compensation is only 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 names a specific verb ('search'), a concrete resource ('move display names'), and the matching mode ('substring'), so an agent can distinguish this from get_move and search_pokemon. The scope is precise and leaves little ambiguity about what the tool operates on.

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?

Usage context is implied rather than stated: 'substring search' suggests it is appropriate for partial or inexact move-name lookup. However, no explicit when-to-use or when-not-to-use guidance is given, and no alternatives are named despite relevant siblings like get_move and search_pokemon.

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

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

No annotations are provided, so the description carries the behavioral burden. It does disclose substring matching behavior, but it does not mention result ordering, case sensitivity, limit semantics, or what a typical response looks like. Adequate but incomplete.

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

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

Two sentences with no filler. The first sentence states the core behavior and the second provides routing guidance, making it easy to scan and act 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?

For a simple search tool, the purpose and usage context are clear. However, with no output schema and no mention of result shape or limit behavior, an agent is left without some details needed to fully anticipate the call's outcome.

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 clarifies that query is a substring over Pokemon display names, but it says nothing about the limit parameter or its default behavior, leaving one of two parameters undocumented.

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

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

The description uses a specific verb and resource: 'Substring search across Pokemon display names.' It also clearly differentiates this tool from get_pokemon by contrasting substring discovery with exact-name lookup.

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

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

It explicitly states when to use this tool ('discovery/browsing when you don't know the exact name') and when to use the alternative ('use get_pokemon when you already know which Pokemon/form you want').

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