Generate BaZi Report (PDF or HTML)

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

Beyond the annotations (readOnlyHint false, idempotent false, openWorld true), the description adds real behavioral context: that PDF output is stored and returned as a URL whereas HTML/Markdown are not stored, that no AI is involved, and that gender is what unlocks the ten-year luck pillar section. It does not discuss idempotency of repeated generation or how stored PDFs are retained, leaving some mutation semantics unstated.

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?

It is dense and front-loaded: the output artifact and its default format come first, the section inventory follows, then the inputs. The single long enumerative sentence is efficient but somewhat list-heavy, and the format/price note in the schema echoes the 'same price in every format' point without the description restating it well.

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 14-parameter, paid, file-generating tool with an output schema already present, the description covers what an agent needs: what gets produced, which format is stored, what the cost is, that confirmation is required, and which input unlocks an optional section. Return-value detail can be left to the output 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?

With 14 parameters and only 36% schema description coverage, the description must compensate and largely does, grouping the birth inputs (date, time, timezoneOffset or timezone, longitude, trueSolarTime, dayBoundary) with the cover fields (name, city) and explaining that gender conditionally enables luck pillars. It omits any mention of language, stageSchool, and whitelabel, which are the largest undocumented blocks in the schema.

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 — the /bazi/chart reading rendered as an A4 PDF (default), HTML, or Markdown — and enumerates the exact contents (four pillars, ten gods, hidden stems, na yin, twelve stages, day master, element counts, strength verdict, symbolic stars, interactions, luck pillars). That clearly separates it from the data-only siblings such as astroway_bazi_four_pillars or astroway_bazi_chart.

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?

It signals the usage context by tying the output to a format choice and by noting 'No AI', plus a warning that this costs 5,000 credits (~50% of a free monthly budget) and should be confirmed with the user first. It does not explicitly say 'use astroway_bazi_chart instead when you only need raw data', so the routing guidance is implied rather than stated.

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