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

With no annotations, the description carries the behavioral burden. 'Current time' communicates a read-only operation, but the description does not disclose return format, timezone validity handling, or the surprising disconnect between the stated purpose and the unrelated schema parameters. It is not contradictory, but it leaves clear gaps.

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 a single, tightly worded sentence with no filler. The core function and scope are front-loaded, making it highly concise and readable.

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 with nine optional parameters and no output schema, a one-line description is inadequate. There is no connection between the timezone purpose and the supplied parameters, no return-value description, and no guidance on valid IANA names or sibling fallbacks, so an agent cannot reliably invoke the tool.

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?

Although schema parameter descriptions exist, none of them represents an IANA timezone input. The description's 'named IANA timezone' maps to no property, and the schema exposes a grab-bag of unrelated optional fields such as ref, url, city, feed, host, json, and path. This actively misleads parameter selection.

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 phrase 'Current time in a named IANA timezone' clearly identifies the resource and scope of the tool, and implies a read-only lookup. It does not explicitly name or contrast sibling tools such as utc-time or iana-zones, so it misses the highest tier of purpose 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?

No guidance is given on when to use this tool versus utc-time or iana-zones, how to obtain a valid IANA timezone name, or what inputs are actually required. The only implied signal is that a 'named IANA timezone' is needed, but the schema does not expose such a parameter.

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