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

With no annotations, the description carries the full behavioral burden and does well: it declares the azimuth convention (0=north, clockwise), distinguishes geometric from apparent (Sæmundsson refraction) elevation, and flags that polar day/night is returned explicitly rather than as an error or null. It does not state elevation units or the return shape, which keeps it from a 5.

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 core output (azimuth/elevation) before the refinements (conventions, refraction variants, polar state). Every clause adds information the agent needs, especially since there is no output schema. The em-dash chaining makes it dense to parse, which is the only knock.

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?

No output schema exists, so the description must describe returns, and it does: azimuth convention, two elevation variants, declination, hour angle, and explicit polar handling. Combined with fully documented parameters, an agent has enough to call this correctly and interpret the results.

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 lat, lon, and 'at' are each documented in-schema, including ranges and the east-positive convention. The description adds only the framing 'a location and instant' and does not supply format or interpretation detail beyond the schema. Baseline 3 applies when the schema already does the work.

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 the exact resource and scope: azimuth/elevation for a given lat/lon and instant, plus the derived quantities (declination, hour angle, polar state). An agent can tell this computes solar geometry rather than calendar or ephemeris-table data, as the siblings (solar_terms, calendar, ganzhi) imply. It stops short of explicitly contrasting itself with any named sibling, which keeps it off a 5.

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?

There is one genuine boundary statement: 'measurement link only, no direction is inferred from photos', which tells the agent not to use this for photo-based orientation work. The schema also hints at passing 'at' explicitly for reproducible digests. However, there is no positive statement of when to reach for this tool and no named alternative, so usage is implied rather than specified.

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