Summary
Returning the timezone alongside the time is what makes the other two tools usable — an interval computed in the wrong zone is wrong twice a year.
Date arithmetic is one of the things models get quietly wrong: month boundaries, leap years, and above all daylight saving, where adding twenty-four hours and adding one day are different answers. Doing it in code removes the class. Knowing the user's own timezone is the piece that makes 'in three hours' resolvable at all — a model asked to schedule something has no way to know where the person is unless something tells it. Three tools that each fix a specific failure rather than a general-purpose date library.
What it is
Three date and time tools: timezone conversion, date arithmetic, and the current time with its timezone.
What you get
- convertTimezones moves a datetime string from one zone to another rather than applying an offset.
- mutateDate adds or subtracts days, hours, minutes and larger units — arithmetic done by code rather than in a model's head.
- currentDateTimeAndTimezone returns the current time along with the user's timezone, which is the part a model cannot know.
Requirements
Nothing to supply.
Setup effort
One command — npx -y mcp-remote https://date-time-tools.iabhishek.workers.dev/mcp