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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds non-derivable behavior: that nouns and verbs are dictionary-checked, and that results can legitimately be empty for rare language pairs. That caveat is exactly the kind of trait an agent cannot infer from structured fields. It does not describe ordering, pagination, or how count interacts with availability.

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 short sentences, front-loaded with what the tool returns before the quality note and the empty-result caveat. The dictionary-checking sentence is the weakest link but still informs trust in the output. No filler or repetition 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 and read-only annotations, the description carries the return-shape burden and does so by naming translations, forms, and examples, plus the empty-result case. What is missing is minor for a lookup: how the count default of 30 is applied when fewer words exist, and result ordering.

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 60%, with topic, native, and target documented and level/count carrying only enum/default metadata. The description reinforces that topic and level drive the lookup but says nothing about count, and critically does not disambiguate which language is the source (native) versus the produced word (target). Minimum-viable; it neither compensates for the coverage gap nor misleads.

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 concrete resource ('words already in Ordkort's shared bank'), scoped to a topic and level, and describes what each item carries (translations, forms, examples). It implicitly distinguishes itself from the lookup siblings list_topics/list_languages, which only supply the ids this tool consumes. It stops short of an explicit verb like 'retrieve', so it is clear rather than crisp.

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 fallback clause 'May be empty for a rare pair of languages; then write the words yourself' tells the agent what to do on an empty result, which is genuine usage guidance. However, there is no explicit statement of when to reach for this tool versus create_deck/design_guide, or of prerequisites such as needing a topic id from list_topics first. Usage is implied rather than spelled out.

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