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

Annotations already cover the safety profile (readOnlyHint true, destructiveHint false, openWorldHint true), and the description adds real context beyond them: answers are computed by server-side code on the server's UTC clock rather than by a model, unsupported asks are refused, and the result carries an "open" link to the card. Those are non-obvious behavioral facts an agent could not get from the annotations.

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?

Roughly half the text is promotional boilerplate about provenance and benchmark ratings that does not help an agent call the tool, and the functional statement is embedded mid-paragraph rather than front-loaded. The genuinely useful facts (server clock, UTC, refusal behavior, card link) are buried among filler.

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 two-parameter read-only skill with no output schema, the description supplies what matters: what kinds of asks work, that unsupported asks are refused, that computation is server-side on UTC, and where the card lives in the result. Only the response_type options go unaddressed in prose, and the schema covers those.

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 schema already documents both parameters and the default/unsupported enum value. The description reinforces the `ask` parameter with example phrasings but says nothing about response_type, so it adds only marginal meaning over the structured fields.

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 does identify the resource and the kind of question answered, with concrete asks ("time in tokyo", "sunset in rome") that make the domain unambiguous. It distinguishes itself implicitly from siblings like moon_phase or drive_time by scoping to clock time and sun events for a place, but the marketing framing ("proven skills with the most evidence") pushes past the point of clarity.

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?

Example asks convey the expected input shape and the note that unsupported asks are refused rather than guessed is useful usage context. However, it never states when to prefer this over closely related siblings such as drive_time, moon_phase, or skill_constellation, leaving routing to inference.

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