Skip to main content
Glama
Jambozx

OnlineCyberTools MCP (280+ filterable tools)

time_timezone_converter

Read-onlyIdempotent

Convert wall-clock dates and times between IANA time zones with DST awareness, or compare an instant across up to 12 zones simultaneously.

Instructions

Time Zone Converter. Convert a wall-clock date and time from one IANA time zone to another with DST awareness, or render one UTC instant across up to 12 zones at once. The 'operation' field selects the mode. 'convert' takes a year/month/day (plus optional hour/minute/second), a fromTz and a toTz, and returns the source and target wall clocks, the shared UTC instant, and the signed hours difference. 'compare' takes the same wall clock with a sourceTz and a targetTzs list and renders each target zone. 'listSupportedTimezones' returns a curated IANA name list and ignores all other fields. Use this for zone-to-zone wall-clock math; use time_world_clock for a live ticking multi-city clock, time_iso_8601_formatter for ISO/RFC string parsing, or convert_timestamp for unix-epoch dates. Pure local computation against the bundled tz database, no network or storage; read-only, non-destructive, idempotent, rate-limited (60 req/min anonymous, no auth). Each rendered zone reports its UTC offset, abbreviation, and DST flag.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
operationYesMode to run. 'convert' converts one wall clock from fromTz to toTz. 'compare' renders the same instant across targetTzs. 'listSupportedTimezones' returns the curated IANA list and ignores all other fields.
yearNoWall-clock year 1900-2100. Required for convert and compare.
monthNoWall-clock month 1-12. Required for convert and compare.
dayNoWall-clock day 1-31; must be a real calendar date. Required for convert and compare.
hourNoWall-clock hour 0-23. Optional, defaults to 0.
minuteNoWall-clock minute 0-59. Optional, defaults to 0.
secondNoWall-clock second 0-59. Optional, defaults to 0.
fromTzNoSource IANA time zone name such as America/New_York. Required for convert.
toTzNoTarget IANA time zone name such as Europe/London. Required for convert.
sourceTzNoSource IANA time zone for the wall clock. Required for compare.
targetTzsNoIANA time zone names to render the instant in, 1-12 entries. Required for compare.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
operationNoThe operation that was run, echoed back.
dataNoResult payload; shape depends on operation (object for convert/compare, string array for listSupportedTimezones).
Behavior5/5

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

Beyond annotations (readOnlyHint, idempotentHint), description adds DST awareness, mode behavior, that listSupportedTimezones ignores other fields, and that each rendered zone reports UTC offset, abbreviation, and DST flag. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single paragraph, front-loaded with purpose, then mode details, then sibling comparisons, then behavioral notes. Slightly dense but efficient; every sentence adds value. Could be slightly more structured with line breaks.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (3 modes, many parameters, output schema present), the description covers all necessary context: operation selection, parameter requirements per mode, return value semantics (UTC offset, abbreviation, DST), and performance characteristics (local, rate-limited).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so parameters are already well described. The description adds value by grouping parameters per mode and clarifying which are required for each operation, reinforcing the schema without redundancy.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it's a wall-clock time zone converter with three named modes (convert, compare, listSupportedTimezones). It distinguishes from sibling tools (time_world_clock, time_iso_8601_formatter, convert_timestamp) by specifying their different use cases.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use this tool ('zone-to-zone wall-clock math') and lists three sibling tools for other time-related tasks. Also mentions local computation, no network, and rate limits, setting clear expectations.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Jambozx/onlinecybertools-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server