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

Annotations already declare readOnlyHint=true, destructiveHint=false, so the safety profile is covered structurally. The description adds useful context beyond that: the shape of each returned record and the fact that values are fixed UTC offsets (not DST-dependent names), plus the underlying HTTP endpoint for traceability. Auth/rate-limit behavior remains unspecified, keeping it below 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?

Two short sentences plus an endpoint: identity, payload, and downstream purpose, all front-loaded with zero filler. Every clause earns its place, including the endpoint token which costs four words and adds traceability.

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 no-parameter, read-only lookup with no output schema, the description supplies what an agent needs: what comes back and why it matters. It does not state whether the list is paginated or statically ordered, though for a static meta endpoint that omission is minor.

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 tool takes zero parameters, so the baseline is 4 and there is nothing for the description to compensate for. It spends its words usefully by documenting the response fields (id, name, fixed UTC offset) that the absent output schema would otherwise have had to carry.

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?

States a specific verb and resource ("List Emailchef's timezones") and immediately enumerates what each entry contains (id, name, fixed UTC offset). This is unmistakable against siblings like emailchef_list_custom_fields or emailchef_list_senders, and the endpoint (GET /meta/timezones) removes any ambiguity about which resource is being read.

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 id is required to schedule a campaign" tells the agent exactly why it would call this tool and where the results feed in, which is a genuine usage cue. It stops short of explicit when-not-to-use guidance or naming emailchef_schedule_campaign directly as the counterpart, so it is clear context without full routing instruction.

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