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

Annotations already establish readOnlyHint=true, so the description is free to add matching behavior (case-insensitive, exact term) and a rundown of what the response carries, including deck-specific extras like stroke counts, JLPT levels, IPA and audio. The gap is failure behavior: it never says whether a missing term errors, returns null, or returns empty.

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 tight sentences: the operation and exact-match rule come first, case-insensitivity second, return payload last. Every clause carries information; no filler or restatement of the tool name.

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 usefully enumerates the returned fields per deck, which is exactly the burden it must carry. It falls short only on not-found semantics and on any hint that deck ids come from list_decks, though the latter is covered by the schema.

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 baseline is 3, and the description earns an uplift by clarifying that 'term' means the literal script form (kanji, hanzi, jamo, or word) rather than a romanization or id. The deck parameter is left entirely to the schema's enum and its list_decks note.

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 verb and resource ('One deck entry in full') and pins down the matching semantics ('matched on the exact term'), which implicitly contrasts it with the sibling search_deck. An agent can tell what this returns and how it selects the record without opening the schema.

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 is only implied: the emphasis on 'exact term' signals this is the direct-lookup path, but it never names search_deck as the alternative for partial/fuzzy matching, nor states when-not to use it. The deck parameter's pointer to list_decks lives in the schema, not the description.

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