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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered by structured data. The description adds nothing beyond that: it doesn't disclose that output is sign-derived, whether it is deterministic for a given chart, or how the credit cost relates to execution. Given the low bar enabled by annotations, this is a weak addition.

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 very short (one line plus two bracketed metadata tags). Nothing is wasted, but it is under-specified rather than concise: the content is so sparse that 'front-loaded' barely applies.

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 15-parameter tool with 33% schema coverage, an output schema, and a dense sibling toolset, the description is far too thin. It omits how the required chart inputs map to a sign, what the result contains, and why this tool is chosen over adjacent Wellness tools. The annotations and output schema lighten the safety/return-format burden, but the purpose and parameter context remain incomplete.

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 coverage is only 33%; 15 parameters exist and the description explains none of them. It gives no hint that date/time/latitude/longitude define a chart whose sign drives the yoga output, nor any guidance on the many optional astrological parameters (zodiacType, ayanamsa, houseSystem). This is a significant gap the description should compensate for.

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 names a specific domain (yoga) and its content (sign-specific asanas and pranayama), so the purpose is identifiable. However, it is a fragment rather than a stated verb+resource, and it never explains that the output is derived from the input chart or distinguishes it from siblings like astroway_wellness_exercise or astroway_wellness_diet.

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?

There is no when-to-use guidance, no mention of alternatives (exercise, diet, herbs within the Wellness group), and no statement of prerequisites or how the required date/time/coords relate to getting sign-specific yoga. The agent must infer applicability from the name alone.

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