Loading ToolBench
Convert datetime between timezones -- all IANA zones, UTC offset, DST-aware. ISO 8601 input/output.
Single tool 'utility_convert_timezone' has a well-structured schema with all required parameters typed and described. Description is comprehensive (450+ chars) and includes use cases, examples, and anti-patterns (what NOT to use it for). Input schema properly declares datetime, from, to as required strings with IANA timezone guidance. Output structure documented in description with example JSON. However, output schema is not formally declared in the tool definition itself, only described in prose. No parameter constraints (enums, patterns, min/max) are enforced. Tool naming follows verb_noun pattern correctly. Error handling and recovery guidance are absent.
Use this when you need to convert a date/time from one timezone to another. Returns the converted datetime with offset data in JSON. Returns: 1. convertedDatetime (ISO 8601) 2. fromTimezone and toTimezone 3. utcOffset (e.g. "+01:00") 4. abbreviation (e.g. "CET", "EST") 5. isDST (boolean) 6. originalDatetime. Example output: {"originalDatetime":"2026-04-13T14:30:00","fromTimezone":"America/New_York","toTimezone":"Europe/Paris","convertedDatetime":"2026-04-13T20:30:00","utcOffset":"+02:00","abbreviation":"CEST","isDST":true} Use this FOR scheduling meetings across timezones, converting log timestamps, coordinating international events, and displaying local times. Do NOT use for currency conversion -- use finance_convert_currency instead. Do NOT use for unit conversion -- use utility_convert_units instead. Do NOT use for weather data -- use data_get_weather instead.
Output schema not formally declared. Description includes example JSON but tool definition lacks a documented 'returns' or 'output' schema block. LLMs cannot reliably parse unstructured prose output specs.
No parameter constraints (enums, patterns, regex). 'from' and 'to' accept free-form strings; LLMs may pass invalid IANA timezone names. Should declare enum of valid timezones or add pattern validation.
No error handling guidance. Tool description lacks recovery hints for invalid inputs (e.g., 'If timezone is unrecognized, try search_timezones() first'). Agents have no fallback on failure.
Datetime parameter accepts both ISO 8601 and 'human-readable' formats but does not specify which human formats are valid. LLMs may pass ambiguous formats like '01/15/2024' (US vs EU date order).
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 65 | 2025-06-18+ | v2 |
Tool is read-only but lacks explicit idempotentHint annotation in schema. Agents cannot infer from the definition alone that repeated calls are safe.