answer_time_question

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

The annotations already declare readOnly, idempotent, non-destructive, and open-world behavior, so the safety profile is covered. The description adds genuinely new context beyond that: the tool is an intent classifier that dispatches to other operations internally, which explains why identical-looking input may resolve differently. It stops short of saying what the response contains or how ambiguity is surfaced back to the caller.

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?

Front-loaded with the preferred-use claim, then examples, then exclusions — a logical ordering with no filler sentences. It runs slightly long, and the timezone-disambiguation sentence sits a little apart from the main use/don't-use thread. Still, each sentence carries routing value.

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 6-parameter, no-output-schema classification tool, the description is complete on the selection question and safe calling. The main remaining gap is return behavior: with no output schema, an agent cannot learn what an answer looks like or whether the tool can report its own low confidence. That is a noticeable but not fatal omission for a read-only entry point.

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 schema already documents query, date, now, locale, userTimezone, and _endUserId; the description adds no format or precedence detail for any of them. The one piece of semantic guidance it offers — don't pre-resolve unknown cities, call search_timezones — concerns a sibling tool rather than a parameter of this one. Baseline 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?

States a specific role — "PREFERRED entry point for vague, messy, or mixed time/timezone/scheduling questions" — and immediately explains the mechanism (findtime.io classifies intent and dispatches internally). It also names the exact sibling tools it must not be confused with, so an agent can route without opening any schema.

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?

Gives concrete positive triggers with example prompts ("Tuesday", "tomorrow", "in 3 weeks") and explicit exclusions (don't use it to dump structured from/to fields; use convert_time, get_current_time, or find_meeting_time instead). It also adds a fallback rule for ambiguous cities pointing at search_timezones, leaving nothing to inference.

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