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

Annotations already establish readOnlyHint=true and openWorldHint=false, so the description doesn't need to restate safety. What it does add is genuinely behavioral: the default window is the next 30 days capped at 31, eclipses return contact times, and with a location they return duration of totality/annularity plus Sun or Moon altitude. It stops short of describing ordering or the shape of the returned list.

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 a single front-loaded sentence that opens with scope and the default/cap before the enumeration. The list of event categories is dense but each category earns its place by telling the caller what to expect back. Minor cost: the enumeration is long enough that the location-modifier clause is buried mid-sentence.

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?

Seven optional parameters and no output schema, so the description carries reasonable weight, and it covers the two things an agent most needs to know: what event types exist and that coordinates unlock richer eclipse results. Language, time zone, and result ordering are left entirely to the schema, which is acceptable at full coverage.

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 schema already documents all seven parameters and the baseline is 3. The description adds real meaning for one case — supplying a place changes what eclipse data comes back — but does not explain how time_zone, lang, or kinds interact with the output. That single useful addition keeps it at the baseline rather than below it.

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 gives a specific verb-and-resource ('Events over a period') and then enumerates exactly what counts: Moon phases, perigee/apogee, eclipses, seasons, planet oppositions/conjunctions/elongations, and mission events. An agent can tell this is the calendar/event-listing tool. It falls short of 5 because it never distinguishes itself from near-siblings like perigee_sky_conjunctions or perigee_tonight, which overlap on conjunctions and sky events.

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 by enumeration — an agent can infer 'use this to get a calendar of upcoming events'. There is no explicit when-to-use, when-not, or named alternative such as perigee_tonight for a single-night summary or perigee_sky_conjunctions for a targeted conjunction query. The one implicit guidance present is the hint that supplying a place changes eclipse output.

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