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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely new context: a 10-credit Tier 1 cost and the group membership, which matters for budget-aware agents. It says nothing, however, about what the analysis produces or any computational constraints.

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 short and front-loaded, so there is no padding to trim, but the brevity comes from omission rather than efficiency: three of the four lines are metadata tags (group, cost, alias) instead of substantive content.

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 explained, but for a 15-parameter geolocation-and-time chart tool the description gives no indication of required inputs, what the symbolic-degree computation yields, or how it relates to its near-identical long-name sibling. The coverage gap at 33% is not addressed.

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 15 parameters and only 33% schema description coverage, the description is expected to compensate and does not mention a single parameter. The alias sentence provides no parameter guidance, so several parameters (city, name, cosmogram, zodiacType, houseSystem, precision, fields) remain undocumented or thinly documented in either place.

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?

"Symbolic-degree analysis" essentially restates the tool name and title without saying what is actually computed (Sabian symbols? degree meanings? which planets?). The one piece of real information is the alias disclosure, which tells an agent this duplicates `astroway_psychological_modern_rudhyar_symbolic_degrees`, but that is a routing note rather than a purpose statement.

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?

No when-to-use, when-not-to-use, or prerequisite guidance is given. The alias note implies it is interchangeable with the long-named sibling, but it never says which one an agent should prefer, nor when symbolic-degree analysis is appropriate versus the other Rudhyar tools such as lunation_phase or personality_keynote.

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