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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the description is free to add other context — and it does, disclosing the exact algorithm provenance (Meeus, ch. 47-48) and the three output components. With no output schema present, naming the return values is genuinely useful behavioral disclosure, though it omits accuracy/precision caveats or the default date behavior.

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?

A single sentence with no filler, front-loading the substantive outputs (fraction, waxing/waning, phase name) before the provenance citation. Every clause earns its place.

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 simple, idempotent, read-only calculation with full schema coverage on its one optional parameter, the description is nearly complete: it states outputs and algorithmic basis. The only material omission is the default behavior when 'date' is omitted, which the agent must infer from the schema rather than the description.

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?

There is a single parameter with 100% schema description coverage ('An ISO date or date-time (UTC). Leave it out for now.'), so the schema already carries the semantics. The description adds nothing about the date parameter (e.g., range limits, default resolution), so the baseline 3 applies.

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 resource (the moon's phase) and enumerates exactly what is produced: illuminated fraction, waxing/waning state, and phase name. That is enough to distinguish it from the unrelated siblings (meteor_showers, ask_void, review_code) without opening the schema, though the verb is left implicit ('The moon's illuminated fraction...' rather than 'computes/returns').

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: a single-purpose astronomical calculation with no declared alternatives, prerequisites, or exclusions. The phrase 'for a moment' plus the schema note 'Leave it out for now' hints at a default-to-now behavior, but the description itself never says when to call it or when not to.

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