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

Annotations already establish readOnly/idempotent/non-destructive, so the description is not required to restate safety. It adds genuinely new behavioral context: the credit cost and tier, the POST endpoint, the geocentric reference frame, and the specific ephemeris method (Meeus Ch.48). The word 'Current' is slightly imprecise next to the required date/time, but 'at a given moment' immediately corrects it.

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?

Three short lines, front-loaded with the purpose and outputs before the grouped metadata (group, endpoint, required, cost). Every line carries information; there is no filler or restated verbosity.

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-value documentation is not needed, and the annotations carry the safety profile. What is missing is guidance for a 15-parameter request: no note on which optional parameters meaningfully affect a moon-phase result, no mention of timezone/timezoneOffset interaction for a location-based calculation (though the schema itself covers that well), and no differentiation from the render sibling.

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?

Only 33% of the 15 parameters carry schema descriptions, so the description must compensate and largely does not. Its single parameter line merely restates the four required fields already declared in the schema's 'required' array, and adds no meaning for undocumented parameters such as city, name, cosmogram, zodiacType, houseSystem, or ayanamsaId — several of which look only tangentially relevant to a moon-phase calculation and would benefit from explanation or a usage note.

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 computed resource (moon phase) and enumerates its outputs: illumination %, age in days, elongation, waxing/waning, and sun/moon zodiac signs, plus the computational basis (Meeus Ch.48, geocentric Sun-Moon elongation). An agent can tell exactly what this returns. It does not, however, name or differentiate itself from the close sibling astroway_render_moon_phase or astroway_calendar_lunar_calendar, which likely overlap in subject matter.

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?

Usage is implied by the output list and the '[Required: date, time, latitude, longitude]' line, but there is no explicit when-to-use statement, no exclusion, and no routing to alternatives such as the render or lunar-calendar siblings. The '[Cost: 10 credits (Tier 1)]' line gives useful context for choosing among tools but is not a usage rule.

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