get_pokemon

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.