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

With no annotations provided, the description carries the full burden for behavioral disclosure. It mentions that names are stored in the card's own language, which is a key behavior, but it doesn't disclose other important aspects: whether multiple results can be returned, if the search is case-insensitive, or any pagination/default behavior (though the schema does provide defaults). It also doesn't mention any authentication or rate limits. That said, it does add some unique behavioral 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 concise, two sentences, with the key filtering detail (search by localized name) front-loaded. Every sentence adds value, and there is no fluff 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?

Given the tool's complexity (search with multiple params) and low schema coverage, the description is under-specified. It lacks information on return format (though no output schema exists), default behavior when no results found, and how 'lang' interacts with the search (e.g., is it a filter only?). Since there is no output schema, the description should clarify what the response contains, but it doesn't. Still, it covers the most crucial aspect: localized search 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?

Schema description coverage is only 25%, meaning the schema documents only the 'lang' parameter explicitly. The description adds meaning for 'q' by explaining that it's a name and that it must be in the card's native language, but it doesn't elaborate on 'limit' or 'offset' semantics (which are somewhat obvious from schema defaults and bounds). The description partially compensates for the low coverage by clarifying the search term, but it doesn't fully address the undocumented parameters.

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

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

The description clearly states the tool's purpose: searching Pokémon TCG cards by name, with a specific note on language handling. It distinguishes itself from siblings like get_card (which likely fetches by ID) and list_cards_in_set (which lists cards in a set) by focusing on name-based search. The verb 'search' and resource 'cards' are specific, and the language nuance adds clarity.

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 to find cards by name, especially in non-English languages. It does not explicitly say when not to use it or mention alternatives, but the sibling tools are distinct enough (e.g., get_card by ID, list_cards_in_set by set) that the context is clear. The guidance on using localized names is a strong usage hint.

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