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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuinely useful operational context beyond that: a concrete cost of 10 credits (Tier 1), the HTTP endpoint, and the required-field set, which an agent needs for budgeting and validation before calling.

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 core purpose and system are front-loaded in the first sentence, with structured metadata ([Group]/[Endpoint]/[Required]/[Cost]) following. The bracketed lines are somewhat boilerplate, but each carries usable information and the alias note is short and placed last.

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?

An output schema exists, so return values need not be described, and annotations cover safety. The definition supplies cost, endpoint, required fields, and system context adequate for a simple computation tool; the only minor gap is that `name`/`date` semantics rest entirely on the 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?

Schema description coverage is 60% (year, fields, precision are documented in-schema; name and date are not). The description only restates that name and date are required, which the schema's `required` array already declares, so it adds little meaning for the two undocumented parameters and nothing for the documented ones. Baseline 3 is appropriate.

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?

States a specific verb (Calculate) and resource (Personal Year number) for a given calendar year, and locates it in the Pythagorean system. Against siblings sharing the same number type across Chaldean/Kabbalistic/Vedic systems, the 'Pythagorean' qualifier plus the explicit alias note cleanly disambiguates it from astroway_numerology_pythagorean_personal_year and the astroway_numk/numks variants.

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 implies when to use it (reading the 9-year personal cycle for a specific calendar year) but gives no explicit when-to-use vs alternatives, e.g. personal_year vs life_path, or Pythagorean vs other numerology systems. The alias note does helpfully signal equivalence with the canonical tool, so the routing hint is partial rather than absent.

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