Look up a Chinese idiom's definition, origin, and classical examples, along with its learning progress such as times drawn, mastery status, and notes.
查一个成语的释义、出处、古文例句，以及学习进度（抽中次数、状态、备注）。
Args: word: 成语原文，如 守株待兔
| Name | Required | Description | Default |
|---|---|---|---|
| word | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true is consistent with a lookup tool and the description adds the useful detail that progress metadata (draw count, status, notes) is bundled into the response. However, that return content is largely already captured by the output schema, and nothing is said about failure behavior for unknown idioms or about how notes/status are sourced.
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 front-loaded sentence states the tool's output scope, followed by a compact Args block. No filler, though the Args block partly restates the schema rather than adding new constraint detail.
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 read-only tool with an output schema and a readOnly annotation, the essentials are present. What's missing is the not-found behavior and the boundary against search_idiom, which an agent needs to route correctly among six siblings.
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% — the 'word' property carries only a title, no description — so the description must carry the parameter, and it does: '成语原文' plus a concrete example (守株待兔) tells the agent to pass the exact idiom form, not a keyword or partial string. A short note on whether variant/simplified forms are accepted would close the remaining gap.
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 (查/look up) and resource (an idiom's detail), then enumerates exactly what comes back: definition, origin, classical example sentences, and learning progress. That enumeration distinguishes it in substance from search_idiom and draw_idiom, though no sibling is named explicitly.
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: 'word: 成语原文' hints that this is for a single exact idiom rather than a fuzzy query, which is the natural split from search_idiom. But the description never states when to prefer this over search_idiom, nor what happens for a word that isn't in the collection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.