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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds meaningful behavioral detail: result ranking, filtering against a protected zodiac animal, the 93-day limit, and that each candidate day includes officer, pillars, lunar date, and clash animal so reasoning is visible. This goes well beyond the annotations.

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 three sentences with no filler. It front-loads the core search behavior, explains the ranking and filtering logic, describes the response content, justifies the range cap, and closes with the intended audience. Every sentence contributes useful decision-making information.

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 properly compensates by explaining what each candidate day contains: 'its officer, its pillars, its lunar date and the animal it clashes with.' It also covers ordering, filtering, range limits, and representative use cases, which is enough for an agent to call the tool correctly and interpret results.

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%, so the schema already documents every parameter. The description adds reinforcing context such as 'chosen activity' and 'zodiac animal to protect', and it echoes the 93-day range cap, but it does not provide new parameter-level format or syntax details beyond what the schema already offers.

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 uses a specific verb and resource: 'Search a date range for the days a chosen activity is favoured on.' It further distinguishes itself from calendar sibling tools by mentioning ranking by the jian chu day officer, filtering by zodiac animal, and returning pillars and lunar dates. The title reinforces the purpose as date selection for weddings, openings, moving, and travel.

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 gives clear use context: 'Built for wedding planners, business opening tools, and moving and travel date pickers.' It also explains why the 93-day cap exists ('date selection is done inside a planning window rather than across a lifetime'). However, it does not explicitly state when not to use it or name alternative sibling tools.

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