timetree_timezone_status

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description still adds real value by disclosing that the check is local and requires no credentials or calendar access, plus the important caveat that availability is not a guarantee of occurrence-tool support. It does not say what a negative or partial result implies, 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?

Three short sentences, front-loaded with the action and the credential-free local nature of the call; no filler. The closing caveat about availability is useful but its referent ('occurrence tools') is only loosely anchored, costing a point.

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?

There is no output schema, so the description carries the burden of explaining what a diagnosis yields, and it never says what the result contains (e.g., which zones resolved, pass/fail shape). Combined with the vague availability caveat, an agent knows when to call it but not exactly what it will get back.

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% and the single optional parameter is already documented with an example (Asia/Tokyo) and the omit-to-check-all behavior. The description restates the default-vs-single-zone distinction and adds the count of five supported zones, but nothing about accepted formats or behavior for unsupported zone strings beyond the schema.

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+resource: diagnosing installed IANA timezone data, run locally. It also states scope precisely (all five supported occurrence zones by default, or one requested zone), which is enough to distinguish it from siblings like timetree_status or timetree_login without opening either schema.

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?

It establishes the conditions under which the tool applies (no credentials, no calendar reads, no writes) and warns that a zone being available here does not mean occurrence tools support it, which implies a pre-check use case. It stops short of explicitly naming an alternative tool or saying 'call this before create/move occurrence', so it is clear context but not full when/when-not routing.

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