Get Moon Phase

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

Annotations already establish readOnly, idempotent, non-destructive, closed-world behavior. The description adds genuinely new operational context: the values are 'Computed locally — no NOAA data involved,' which tells the agent not to expect a NOAA dataset lookup or external calls, plus the exact fields returned.

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 first sentence is front-loaded and efficient, and the second paragraph delivers a compact domain hint. The enumeration of return fields overlaps with the existing output schema and is the only mildly expendable part.

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?

With an output schema present, the return-value list is optional, and the description still covers range behavior, local computation, and tide interpretation. It would be complete if it acknowledged the sibling for 'next' phase queries or clarified the latitude/longitude role.

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 100%, so the baseline is 3; the schema already documents date format, end_date range semantics, lat/long bounds, and the response_format enum. The description adds only the day-by-day range behavior, and never explains what latitude/longitude actually change (topocentric vs geocentric precision).

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 verb+resource (moon phase for a date/range) and enumerates the returned quantities, and the 'each day of a date range if end_date is given' clause implicitly separates it from astro_get_next_moon_phase. It stops short of naming that sibling, so the differentiation is inferred rather than explicit.

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 date/range framing (use it for a specific day or a span), but there is no explicit when-to-use/when-not guidance and no mention of the alternative astro_get_next_moon_phase for forward-looking queries. The tide-context paragraph explains relevance but not tool selection.

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