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

Annotations already cover read-only, idempotent, non-destructive, but the description adds the traits annotations cannot express: it is a paid tool at $0.005/call via x402, returns HTTP 402 with payment requirements, and requires retry with a PAYMENT-SIGNATURE header. It also discloses the computation basis (astronomy-engine ephemeris, ~1′ accuracy, tropical zodiac on true ecliptic of date, geocentric, UTC) and states there is no interpretation. That is exactly the kind of behavior an agent needs before calling a paid endpoint.

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 content is front-loaded: the returned quantities come first, then the computation basis, then the payment mechanics. The opening sentence is a long comma-chained list, which is dense but each item is a genuinely distinct returned field. No filler sentences; only the enumeration style slightly impedes scanning.

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 no output schema, the description carries the burden of describing returns, and it does so field by field, plus pricing, coordinate conventions, and the lat/lon requirement for rise/set. What is missing is response shape (are these flat keys or nested?) and any error behavior for an invalid or out-of-range date.

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 100%, so the baseline is 3; the description earns above that by stating the cross-parameter dependency ('moonrise/moonset when lat and lon are given'), which the schema does not express, and by confirming the default-to-now behavior for the date parameter. It does not add format or range detail beyond the schema, keeping it below 5.

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 opens with a specific verb-and-resource framing ('The Moon at a moment') and enumerates exactly what is computed: phase name and angle, illumination, age, lunar day, sign/degree, ingress, void-of-course, next four phases, rise/set. That is highly specific. It falls short of a 5 because it never explicitly distinguishes itself from the sibling 'moon_calendar' or 'void_of_course', even though it reports void-of-course and phase timing that those tools plausibly overlap with.

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 only implied: it tells the agent that rise/set requires lat and lon, that date defaults to now, and that 'free tools cover the current status and the next retrograde', which hints at a cheaper alternative. There is no explicit 'use moon_calendar for ranges' or 'use void_of_course if you only need that flag' routing, so the agent must infer tool selection.

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