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

Annotations already establish this as a read-only, idempotent, non-destructive, non-open-world calculation. The description adds meaningful behavioral content by naming the progressed Sun, progressed Moon, transiting Sun, per-planet crystals, and outer-planet transit hits. It still omits practical constraints such as the meaningful effect of birth data, location sensitivity, and the 730-day maximum window.

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 compact and front-loads the core idea: crystals over time from a specific degree table. The first sentence is long and lists many output categories, but each clause earns its place by clarifying what the tool returns.

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?

Because an output schema exists, the description does not need to explain return values, and it does a good job enumerating the timing products. For a complex 10-parameter tool, however, it leaves a significant gap around required birth data, location inputs, and the time window parameter.

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 only 40%, so the description needs to compensate for undocumented parameters. It gestures at a 'coming window' and 'the moment,' but it does not explain that date and time are birth data, how place versus latitude/longitude/timezone should be supplied, or how asOf relates to date/time.

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 states a specific resource and method: crystals over time from Costelloe's degree table, including yearly, monthly, daily, planetary, and transit-window crystals. It distinguishes the Western tropical approach from Jyotish, but does not explicitly distinguish it from the nearby crystal siblings such as calculate_crystal_profile or lookup_crystal.

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 usage context is implied by 'crystals over time' and the mention of a 'coming window,' and the final clause separates it from Jyotish practice. However, there is no explicit when-to-use guidance, no when-not-to-use guidance, and no named alternative among the sibling tools.

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