get_time_zone

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context (that the offset depends on the timestamp, implying seasonal DST variations), which is beyond the annotations. However, it does not specify what the tool returns if the coordinate is invalid or over ocean areas, which could be relevant.

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 description is two sentences, front-loads the purpose, and each sentence adds value. The first specifies what the tool does and returns; the second explains the critical usage note about timestamp dependency. No fluff or repetition.

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?

Given the tool's moderate complexity (three parameters, no enums), the description is adequate. The output schema exists, so return values are documented. The description covers the key nuance of DST and provides use-case context. It does not mention edge cases like invalid coordinates, but for a read-only tool with an output schema, this is not a critical gap.

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 0%, so the description must compensate. It explains the semantic significance of the timestamp parameter ('Pass the moment you care about, because the offset changes across the year') and mentions the output includes IANA id and offset, which adds meaning beyond param names. Latitude and longitude are standard, but the timestamp's importance is well-clarified.

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 clearly states the tool's purpose: to get the time zone at a coordinate, including IANA id, name, and UTC offset with DST. It distinguishes itself from sibling tools like get_elevation and get_air_quality by focusing on time zone retrieval.

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 description provides explicit usage guidance: it tells the agent to use this tool when needing to reason about local times or business hours, and emphasizes the importance of passing the relevant timestamp because offsets change seasonally. This effectively differentiates it from other geographic tools.

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