TimezoneDB MCP. Get accurate global time from any coordinates or zone.

Look, you don't wanna be relying on guesswork when dealing with global time. The clock changes everywhere, and old calendars are useless. This server gives your AI client an authoritative source for worldwide clock data, so you never have to manually look up offsets or guess what Daylight Saving Time (DST) rules mean in another hemisphere.

It handles the whole mess of coordinate conversions and zone definitions.

Before anything else, you'll want to run check_api_status. This single call confirms if the entire TimezoneDB server is live and responding correctly. You gotta make sure it's up before your agent runs any mission-critical queries; otherwise, all that work hits a dead end.

When you need context—say, you just want to know what time zones exist in Canada, but you don't know the specific city or date—you use list_timezones. This tool returns an exhaustive list of every supported timezone. You can even narrow it down by country if you only care about one region.

If you already know the zone identifier—like 'Europe/Paris' or 'America/Los_Angeles'—you jump straight to get_time_by_zone. This call doesn't just spit out a time. It returns the current local time and all the necessary metadata for that specific timezone string, giving you full details on its offset and structure.

Sometimes, you don't know the zone ID; you only have coordinates—say, latitude 34.05 and longitude -118.24. That’s when you use get_time_by_location. You plug in those exact geographic coordinates, and your agent gets back the precise current local time for that spot on Earth, along with the correct timezone ID to go with it.

Here's where things get tricky: DST changes. If you schedule a meeting across different zones, you need to know if Daylight Saving Time is active right now. You run get_dst_status and tell it the specific time zone. It checks whether or not that region is currently observing DST rules, which is critical for accurate scheduling and avoiding off-by-an-hour errors.

Every tool here works together to solve timing problems. For example, if you're building a system that needs to calculate an offset between two points on Earth, your agent first uses list_timezones to confirm both zones are supported. It then might use get_dst_status for each zone to account for any seasonal shifts before finally running get_time_by_location with the coordinates of one point and cross-referencing it against a time pulled from get_time_by_zone at another location.

This gives you an audited, reliable time difference.

This server eliminates the need to consult external APIs or rely on hardcoded offsets that fail when DST kicks in. You're working with real-time data management for over 400 worldwide zones. It ensures your agent always knows the accurate local time based on whether you provide a clean zone string, raw coordinates, or just want to verify if the whole damn thing is operational.