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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the timezone functionality, but the input schema reveals that the tool accepts many other parameters (ref, url, city, feed, etc.) that are discarded after shape checks. The description fails to disclose that these parameters are ignored, that the tool performs shape validations, or that it has no disk access. This is a significant omission, as the tool appears to have broader (or different) behavior than the description suggests.

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, concise sentence with no wasted words. It front-loads the core functionality clearly. However, given the tool's complexity (9 parameters), the brevity might be insufficient, but the description itself is appropriately structured and to the 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?

The tool has a complex input schema with many parameters, yet the description only explains the timezone aspect. It does not mention the other parameters, their purpose, or that they are discarded. An agent might be confused about why these parameters exist and whether they affect the output. The description is incomplete for the full scope of the tool, though the schema does document each parameter individually. The overall tool behavior is not fully conveyed.

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 covers 100% of parameters with descriptions, so the baseline is 3. The description adds meaning by linking 'named IANA timezone' to the 'zone' parameter, but it does not elaborate on syntax or format beyond what the schema provides. The description adds minimal value over the schema for parameter understanding, so a score of 3 is appropriate.

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 primary function: returning the current time for a named IANA timezone. It is specific about the verb ('Current time') and resource ('named IANA timezone'), and it is distinguishable from siblings like 'utc-time' (which implies UTC) and 'tz-asia-yerevan' (a specific zone), though it does not explicitly name alternatives. The description is clear enough for the main use case.

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?

There is no guidance on when to use this tool versus alternatives. The description does not mention that it is the appropriate choice for timezone lookups, nor does it exclude other uses. An agent would have to infer from the name and the parameter 'zone' that this is for timezone queries, but no explicit usage context or alternative routing is provided.

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