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

Annotations already establish that this is a read-only, idempotent, non-destructive, closed-world calculation. The description adds useful context that DST is accounted for and that UTC offset plus DST status are returned, but it does not add much beyond that.

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?

The definition is short and the main purpose is front-loaded. However, the final sentence pointing to list_bundles for unrelated "temps-rh" calculators does not earn its place and distracts from the actual tool.

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 tool whose schema requires from_zone and to_zone, the description never explains those parameters and instead describes a single IANA timezone input. The presence of an output schema means return details need not be fully repeated, but the input description is inaccurate and incomplete.

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?

The schema fully documents two required enum parameters, from_zone and to_zone. However, the description says the input is a single "timezone (IANA name)," which conflicts with the schema and omits the actual source/target zone parameters, making it potentially misleading.

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 first sentence gives a specific verb and resource: compute the current UTC offset for a timezone, including DST. It is understandable in isolation, but it does not distinguish this tool from close siblings such as calculate_timezone_convert or calculate_time_zone_difference.

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?

The only usage guidance is the vague phrase "Use for scheduling and date math." It does not say when to choose this tool over sibling timezone tools, nor does it state any exclusions or prerequisites.

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