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

Annotations already declare a read-only, idempotent, non-destructive, closed-world lookup, so the safety profile is covered. Beyond that, the description adds meaningful defaults: the current year when none is given and Polish time as the baseline zone, plus the fact that extra outputs only appear when a place is provided. It stops short of noting precedence when both city and lat/lon are supplied.

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 dense sentence, front-loaded with the primary output (the solstices) and then the conditional extension. There is no filler, and the semicolon cleanly separates the default case from the place-specific case.

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?

The output schema covers return values and the annotations cover the safety profile, so the description only needs to handle defaults and routing. It handles the year and time-zone defaults but leaves open how city interacts with lat/lon/tz and never states why this tool should be chosen over sun_calendar, which is the main remaining gap for a six-parameter optional-input tool.

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 83%, above the high-coverage threshold, so the schema already explains tz, lat, lon, city, lang and year. The description reinforces the year default and the 'place' grouping of the location parameters but adds no format or precedence detail beyond that, making the baseline 3 appropriate.

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 resource and result: December and June solstices to the minute, plus shortest/longest day, earliest sunset and latest sunrise when a place is supplied. It is clear what the tool computes, but it never distinguishes itself from the similarly named siblings sun_calendar and sun_times, so an agent must infer the boundary.

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 through the conditional phrase 'with a place, also its shortest and longest day', which tells the agent that omitting place data yields the plain solstice answer. There is no explicit when-to-use/when-not-to-use guidance and no sibling tool is named as an alternative, so the agent has to construct the routing rule itself.

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