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

Annotations already indicate read-only and non-destructive behavior, so the description's job is lighter. It adds useful observable behavior: the operations returns all 64 hexagrams in King Wen sequence with Chinese names, English translations, and trigram compositions. This is meaningful beyond what the annotations and schema alone communicate.

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 short and the core operation is front-loaded in the first sentence. The second sentence adds functional context about ordering, but the final sentence about 'profound wisdom for decision-making' is promotional and does not help an agent select or invoke the tool, adding unnecessary fluff.

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 read-only listing tool with a fully documented input schema, the description supplies the key unstated facts: what content is returned and how it is ordered. It omits pagination shape and exact response object, but the parametrical documentation plus annotations make this a fairly complete picture for correct invocation.

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 100% for all four optional parameters, and defaults, enums, ranges, and compact-shape behavior are already documented in the input schema. The description adds no operational detail about lang, limit, offset, or compact, so it neither adds nor detracts from schema-level semantics.

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 opens with a specific verb and resource: 'Browse all 64 I-Ching hexagrams', and enumerates the included data (Chinese names, English translations, trigram compositions). Emphasizing 'all 64' and the King Wen sequence clearly differentiates it from sibling lookup, number, and random tools, even though those names are not explicitly cited.

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 use case of browsing the full, ordered list is implied by 'Browse all 64' and the King Wen ordering, which suggests it is the tool for comprehensive listing. However, there is no explicit guidance on when to prefer this tool over get_iching_hexagrams_lookup, get_iching_hexagrams_number, or get_iching_hexagrams_random, and no exclusions or alternatives are given.

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