Convert times between IANA zones and detect skipped or ambiguous DST local times.
Scored across 1 tool
With only one tool, there is no ambiguity or overlap to confuse an agent. The tool's purpose is clearly scoped to timezone conversion.
The single tool name follows a clear verb_noun pattern: convert_time. There are no conflicting conventions to create inconsistency.
A single tool feels thin for an MCP server, even for a narrow domain. However, timezone conversion is a focused task, so the count is borderline rather than inappropriate.
The tool fully addresses the complexities of timezone conversion: nonexistent times, ambiguous times, variable offsets, abbreviation pitfalls, and clock changes. It leaves no major gaps within its stated purpose.
Convert a wall-clock time between two IANA timezones, and report the ways the conversion can be wrong.
ALWAYS use this instead of doing the arithmetic. Timezone conversion looks like addition and is not: the mapping from a local time to an instant is not a function.
On the spring-forward date, an hour of local time DOES NOT EXIST. Asked to convert 02:30 on that date, a model will return a plausible timestamp for a time that never happens. This tool returns null and says why.
On the fall-back date, an hour happens TWICE. There are two correct answers an hour apart; this returns both rather than silently choosing.
The gap between two zones is not constant. Zones start and end daylight saving on different dates, so a cached offset is wrong for weeks each year.
Not all offsets are whole hours: India is +05:30, Nepal +05:45.
Input: time must be YYYY-MM-DD HH:MM (or with T, and optional seconds) — free-form dates are refused rather than guessed. from and to must be full IANA names such as "America/New_York".
ABBREVIATIONS ARE REJECTED, deliberately, even though most runtimes accept them. Node resolves "BST" to Bangladesh Standard Time (UTC+06:00) when nearly everyone writing it means British Summer Time (UTC+01:00) — a five-hour error that yields a perfectly plausible timestamp. Same for CST, IST, PST, and EST.
Returns: the chosen UTC instant (null if the local time does not exist), every candidate instant, both zone readings with the offset and abbreviation that applied on THAT date, the difference between the zones, upcoming clock changes for both, and warnings. Check warnings for severity "error" before using the result.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Target zone as a full IANA name, e.g. "Asia/Tokyo". | |
| from | Yes | Source zone as a full IANA name, e.g. "America/New_York". Abbreviations like BST, CST, IST, PST and EST are REJECTED because they are ambiguous. | |
| time | Yes | Wall-clock time as YYYY-MM-DD HH:MM (T separator and seconds also accepted). Do NOT include an offset or zone in the string. Free-form dates such as "next Tuesday" are refused rather than guessed. | |
| prefer | No | Which occurrence to use when the local time happens twice (a fall-back hour). Defaults to the earlier one. Both are always returned in candidates. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traps well beyond the readOnlyHint: nonexistent local times return null, ambiguous fall-back hours return both candidates, zone gaps vary over time, and abbreviations are deliberately rejected because of real-world ambiguity. It also tells the agent to check 'warnings' for severity 'error' before trusting the result.
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 long but every section earns its place: purpose, edge cases, input constraints, rejected abbreviations, and return format. Key guidance is front-loaded with 'ALWAYS use this instead of doing the arithmetic', and the bulleted pitfalls are organized for quick comprehension.
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?
Even without an output schema, the description enumerates what is returned: the chosen UTC instant, all candidates, zone readings with offsets and abbreviations, the zone difference, upcoming clock changes, and warnings. Combined with 100% schema coverage and no sibling tools, nothing an agent needs to call this correctly is missing.
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?
Although schema coverage is 100%, the description adds substantive meaning: strict YYYY-MM-DD HH:MM format, refusal of free-form dates, full IANA names for from/to, and a concrete example of why abbreviations fail ('BST' resolving to Bangladesh Standard Time instead of British Summer Time). The prefer parameter's behavior with dual candidates is also reinforced.
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 the exact verb 'convert' and the resource 'wall-clock time between two IANA timezones', and immediately distinguishes itself from ad-hoc arithmetic via 'ALWAYS use this instead of doing the arithmetic'. This is precise and unambiguous even without sibling tools.
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?
Explicitly tells the agent when to use this tool and what to avoid: 'ALWAYS use this instead of doing the arithmetic.' It also provides strong exclusions, such as free-form dates being refused and abbreviations being rejected, so an agent knows the acceptable usage envelope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
convert_timeA real clock for AI agents: current time, timezone conversion, and DST facts from the IANA tzdb.
Time zone conversion, meeting-slot finding across countries, DST checks and .ics invites. All.
Deterministic time tools for AI agents: timezone conversion, business-day math, cron interpretation.
Add one secure layer between your agents and this server.
