Time

The Time MCP server is an official reference implementation from the Model Context Protocol team. It exposes two tools to any MCP-compatible client: get_current_time, which returns the current datetime in any IANA timezone, and convert_time, which converts a time value between two timezones. Written in Python, installable in one command, zero external dependencies.

LLMs don't know what time it is. This sounds like a minor inconvenience until you're working with an agent that schedules tasks, writes timestamps into code, converts meeting times across timezones, or reasons about deadlines. At that point the model's lack of a clock stops being an abstract limitation and starts producing real mistakes.

The Time MCP server is the smallest possible fix. It's a Python server, officially maintained by Anthropic as part of the MCP reference server collection. Two tools, zero external dependencies, installs in one command. If you've been working around LLM date blindness with manual instructions or prompt hacks, this is cleaner.

What LLMs actually get wrong about time

Before getting into setup, it's worth being specific about the problem. LLMs have a training cutoff date, and they're frequently uncertain about when that is. They also have no mechanism to know how much time has passed since training. This creates several failure modes:

The most common is wrong-year answers. Ask a model "what's today's date?" without any context and it will either refuse or guess based on its training data distribution. Neither answer is useful when you need it to write a function that checks whether a timestamp is in the past.

The second failure mode is timezone math. Even when you give the model the current time explicitly, converting it correctly between timezones that observe daylight saving time on different schedules is the kind of calculation that's easy to get subtly wrong. A model might know that New York is UTC-5 and get the answer right in January, then give you the same answer in August when New York is actually UTC-4.

The third is date arithmetic near DST transitions. "What time will it be in six hours?" sounds trivial but isn't, because "six hours from 23:00 on the day clocks spring forward" is a question with a genuinely unusual answer.

None of this makes LLMs bad tools. It makes them tools that need a clock, the same way a spreadsheet formula needs the system date to calculate =TODAY().

The two tools

The Time MCP server exposes exactly two tools.

get_current_time takes one parameter: a timezone string in IANA format (e.g., America/New_York, Europe/Paris, Asia/Tokyo). It returns the current datetime in ISO 8601 format for that timezone, the UTC offset at this exact moment, and a is_dst boolean.

convert_time takes three parameters: source_timezone, time (in HH:MM 24-hour format), and target_timezone. It returns the equivalent time in the target timezone along with the offset difference and DST status for both zones.

That's it. The entire surface area of this server fits on half a page. If you were expecting something that parses natural language dates like "next Tuesday" or resolves relative expressions like "in two weeks," this isn't it. The server does one thing: accurate, DST-aware time lookup and conversion using IANA timezone identifiers.

For natural language date parsing you'd need a different tool or a preprocessing step where the model first resolves the natural language to an absolute time, then calls convert_time. That two-step pattern works fine in practice.

Setup

The server is published to PyPI as mcp-server-time. The fastest path is uvx, which runs it without a global install:

uvx mcp-server-time

For a persistent setup in Claude Desktop, add this block to your claude_desktop_config.json:

{
  "mcpServers": {
    "time": {
      "command": "uvx",
      "args": ["mcp-server-time"]
    }
  }
}

If your system timezone isn't what you want the server to report as "local," pass the --local-timezone flag:

{
  "mcpServers": {
    "time": {
      "command": "uvx",
      "args": ["mcp-server-time", "--local-timezone=Europe/Paris"]
    }
  }
}

The same config pattern works for Claude Code and Cline. Add the server block, restart the client, and the tools appear. Claude Code in particular benefits from this server because it often needs to write accurate timestamps into code, generate filenames with dates, or reason about build schedules.

A Docker image is also available if you're running servers in containers:

docker run -i --rm -e LOCAL_TIMEZONE mcp/time

When you actually need this

Not every agent setup needs the Time MCP server. If you're using an agent purely for code explanation, content summarization, or question answering about stable facts, the absence of a clock is irrelevant.

You need this server when your agent does any of the following:

Writes timestamps or date-based values into files or code. A coding agent that generates log entries, database seeds, or configuration files with date fields should not be guessing the current date.

Schedules or reasons about meetings and deadlines. Cline or Claude Code working on a project management task, generating a meeting agenda with times, or checking whether a deadline has passed needs accurate time information.

Converts between timezones in a user-facing context. "When does this event start in my timezone?" is a question where a wrong answer creates a real problem. DST is particularly tricky because the same timezone pair has a different offset at different times of year, and the transition dates differ by country.

Writes documentation or changelogs with accurate dates. An agent generating a CHANGELOG entry or commit message with a date should pull from a reliable source, not its training distribution.

For tasks like these, the cost of not having this server is periodic wrong answers that the user has to catch manually. The cost of installing it is about three minutes.

When this server isn't enough

There are two gaps worth knowing about before you rely on this server for anything more complex.

First, no natural language date parsing. If you ask the model to "schedule a meeting for next Wednesday at 3pm London time," the model has to resolve "next Wednesday" to a specific date itself before it can call convert_time. For most models this works fine, but it's a model inference step, not a deterministic one. For high-stakes scheduling, you'd want a separate tool that grounds relative dates against an explicit current date.

Second, no calendar integration. The Time MCP server knows what time it is; it has no idea what's on your calendar, what your working hours are, or whether a proposed meeting time conflicts with anything. For that you'd pair it with a calendar MCP server that reads from your actual schedule.

Neither gap is a criticism of this server. It does what it says it does. The point is that "time tools" covers a wide range of possible features, and this server covers the foundational layer: accurate current time and timezone conversion. Build on top of it.

Practical patterns

A few usage patterns that make this server work better in practice:

Explicitly ask for time context in your system prompt. If your agent regularly needs time awareness, instruct it in your system prompt or CLAUDE.md to call get_current_time at the start of any session where date-relevant work might come up. This avoids the model having to decide whether it needs the time; it just always knows.

Use IANA names, not abbreviations. The server requires IANA timezone identifiers like America/Chicago, not abbreviations like CST. This is correct behavior since CST is ambiguous (it's both Central Standard Time and China Standard Time), but it means your prompts should specify full IANA names when possible. The model generally knows these, but an explicit reminder in your system prompt helps.

Pair with the Filesystem or Git MCP servers. When Claude Code is modifying files and needs to write accurate commit dates, timestamps in comments, or changelog entries, having both Time MCP and the Filesystem or Git server available means it can look up the current date and write it correctly without any manual intervention. The best AI agent for coding guide covers this kind of server composition in more depth.

Validate outputs that contain dates. Even with the server available, models occasionally write hardcoded dates from their training data rather than calling the tool. If date accuracy matters in your workflow, a quick review pass or an assertion in your toolchain that checks whether generated dates are plausible catches this.

Honest limitations

The server is a reference implementation. It's maintained by the MCP team as a demonstration of how to build a time utility for agents, not as production infrastructure. For personal agent setups and development workflows, it's entirely fit for purpose. If you're building a commercial product where timezone accuracy is a legal or contractual requirement, you'd want to verify the behavior against your specific IANA database version and DST rule set, and probably add your own tests.

The two-tool surface area is intentional minimalism. If you need recurring time checks, time-based triggers, or cron-like scheduling, you're looking at a different piece of infrastructure. This server answers "what time is it?" and "what is 14:00 Paris in Tokyo?". Everything beyond that is out of scope.

There's also no caching or rate limiting logic in the server. Each call hits the system clock. This is fine for interactive agent use where calls happen on the order of seconds apart. It would be unusual to call this server frequently enough for performance to matter, but it's worth knowing there's no sophistication under the hood.

Bottom line

The Time MCP server solves a real problem in the most direct way possible. LLMs don't have clocks, and the gap between "training cutoff" and "now" keeps growing. Any agent that writes timestamps, handles scheduling, or converts between timezones needs a reliable source of truth for the current datetime.

This server provides that source of truth with two tools, zero external dependencies, and a three-minute install. It won't parse natural language dates, integrate with your calendar, or handle complex scheduling logic. But it gives every MCP-compatible agent an accurate answer to the most basic temporal question an LLM can't answer on its own: what time is it, right now, in this timezone?

Start with the MCP server directory if you're building a broader agent stack. If you're specifically working on coding agents, the best AI agent for coding guide covers how tools like this one fit into a complete agentic setup alongside agents like Claude Code and Cline.

Features

• Get current time in any IANA timezone
• Convert times between any two timezones with DST awareness
• Returns ISO 8601 datetimes with UTC offset and DST status
• Configurable local timezone via flag or environment variable
• Docker image available: mcp/time

How to set up the Time MCP server

1. Install uv if you don't have it (curl -LsSf https://astral.sh/uv/install.sh | sh)
2. Run uvx mcp-server-time to start the server without a permanent install
3. Add the server block to your claude_desktop_config.json or Claude Code MCP config
4. Optionally pass --local-timezone=America/Chicago to override the system timezone
5. Restart your MCP client and the two time tools appear in the tool list