get_dst_schedule

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

With no annotations, the description carries the burden of explaining behavior. It discloses what the tool returns and something about its content, but it does not mention default behavior when no optional parameters are provided, handling of ambiguous locations, or error/fallback behavior.

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-loaded with the core purpose, and the second sentence provides an actionable routing rule. Every sentence earns its place without fluff.

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 7 optional parameters and no output schema, the description gives a broad purpose but does not explain how arguments (year, at, timezone/city/query, countryCode) interact or what happens for missing inputs. It is minimally sufficient but leaves important edge cases uncovered.

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 100%, so the input schema already documents every parameter. The description adds no parameter-specific meaning, but because coverage is complete and the baseline is 3, this is acceptable.

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 uses a specific verb ('Return') and a clear resource ('production DST schedule payload'), and specifies key contents ('current abbreviation and transition details'). It also distinguishes itself from the sibling answer_time_question by explicitly routing relative-date queries there.

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?

It clearly states that relative-date inputs should go to answer_time_question instead of this tool, which is a useful when-not-to-use condition. It does not elaborate on other alternatives like time_snapshot or search_timezones, but it gives enough context for the primary routing decision.

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