How do I use Time MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Time MCP Server convert 3 PM New York time to London time" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Time MCP Server

by fisher1006

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

Time MCP Server

A Model Context Protocol server that provides time and timezone conversion capabilities. This server enables LLMs to get current time information and perform timezone conversions using IANA timezone names, with automatic system timezone detection.

Available Tools

get_current_time - Get current time in a specific timezone or system timezone.
- Required arguments:
  - timezone (string): IANA timezone name (e.g., 'America/New_York', 'Europe/London')
convert_time - Convert time between timezones.
- Required arguments:
  - source_timezone (string): Source IANA timezone name
  - time (string): Time in 24-hour format (HH:MM)
  - target_timezone (string): Target IANA timezone name

Installation

Using uv (recommended)

When using uv no specific installation is needed. We will use uvx to directly run mcp-server-time.

Using PIP

Alternatively you can install mcp-server-time via pip:

pip install mcp-server-time

After installation, you can run it as a script using:

python -m mcp_server_time

Related MCP server: Time MCP Server

Configuration

Configure for Claude.app

Add to your Claude settings:

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

"mcpServers": {
  "time": {
    "command": "docker",
    "args": ["run", "-i", "--rm", "mcp/time"]
  }
}

"mcpServers": {
  "time": {
    "command": "python",
    "args": ["-m", "mcp_server_time"]
  }
}

Configure for Zed

Add to your Zed settings.json:

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

"context_servers": {
  "mcp-server-time": {
    "command": "python",
    "args": ["-m", "mcp_server_time"]
  }
},

Customization - System Timezone

By default, the server automatically detects your system's timezone. You can override this by adding the argument --local-timezone to the args list in the configuration.

Example:

{
  "command": "python",
  "args": ["-m", "mcp_server_time", "--local-timezone=America/New_York"]
}

Example Interactions

Get current time:

{
  "name": "get_current_time",
  "arguments": {
    "timezone": "Europe/Warsaw"
  }
}

Response:

{
  "timezone": "Europe/Warsaw",
  "datetime": "2024-01-01T13:00:00+01:00",
  "is_dst": false
}

Convert time between timezones:

{
  "name": "convert_time",
  "arguments": {
    "source_timezone": "America/New_York",
    "time": "16:30",
    "target_timezone": "Asia/Tokyo"
  }
}

Response:

{
  "source": {
    "timezone": "America/New_York",
    "datetime": "2024-01-01T12:30:00-05:00",
    "is_dst": false
  },
  "target": {
    "timezone": "Asia/Tokyo",
    "datetime": "2024-01-01T12:30:00+09:00",
    "is_dst": false
  },
  "time_difference": "+13.0h",
}

Debugging

You can use the MCP inspector to debug the server. For uvx installations:

npx @modelcontextprotocol/inspector uvx mcp-server-time

Or if you've installed the package in a specific directory or are developing on it:

cd path/to/servers/src/time
npx @modelcontextprotocol/inspector uv run mcp-server-time

Examples of Questions for Claude

"What time is it now?" (will use system timezone)
"What time is it in Tokyo?"
"When it's 4 PM in New York, what time is it in London?"
"Convert 9:30 AM Tokyo time to New York time"

Build

Docker build:

cd src/time
docker build -t mcp/time .

Contributing

We encourage contributions to help expand and improve mcp-server-time. Whether you want to add new time-related tools, enhance existing functionality, or improve documentation, your input is valuable.

For examples of other MCP servers and implementation patterns, see: https://github.com/modelcontextprotocol/servers

Pull requests are welcome! Feel free to contribute new ideas, bug fixes, or enhancements to make mcp-server-time even more powerful and useful.

License

mcp-server-time is licensed under the MIT License. This means you are free to use, modify, and distribute the software, subject to the terms and conditions of the MIT License. For more details, please see the LICENSE file in the project repository.

Available Tools

2 tools

convert_timeC

Convert time between timezones

ParametersJSON Schema

Name	Required	Description
`source_timezone`	Yes	Source IANA timezone name (e.g., 'America/New_York', 'Europe/London'). Use 'UTC' as local timezone if no source timezone provided by the user.
`time`	Yes	Time to convert in 24-hour format (HH:MM)
`target_timezone`	Yes	Target IANA timezone name (e.g., 'Asia/Tokyo', 'America/San_Francisco'). Use 'UTC' as local timezone if no target timezone provided by the user.

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure but offers minimal information. It states what the tool does but doesn't describe how it behaves—no mention of error handling, input validation, timezone database sources, daylight saving time considerations, or output format. For a tool with no annotations, this leaves significant gaps in understanding its operational characteristics.

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

Conciseness5/5

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

The description is extremely concise—a single, clear sentence that states the core functionality without any fluff. It's front-loaded and wastes no words, making it efficient for quick understanding.

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

Completeness2/5

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

Given the tool's complexity (timezone conversion with no output schema and no annotations), the description is inadequate. It doesn't explain what the tool returns (e.g., converted time format, error messages), how it handles edge cases, or any behavioral traits. With no structured fields to compensate, the description should provide more context to be complete.

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

Parameters3/5

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

The input schema has 100% description coverage, providing detailed parameter information (e.g., IANA timezone names, 24-hour format, default to UTC). The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline of 3 for high schema coverage without compensating value.

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

Purpose4/5

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

The description clearly states the tool's purpose with a specific verb ('convert') and resource ('time between timezones'), making it immediately understandable. However, it doesn't explicitly differentiate from the sibling tool 'get_current_time', which appears to serve a different function (getting current time vs. converting between timezones).

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. While the sibling tool 'get_current_time' suggests a different use case, the description doesn't mention it or provide any context about when conversion is needed versus getting current time, nor does it address any prerequisites or exclusions.

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

get_current_timeB

Get current time in a specific timezones

ParametersJSON Schema

Name	Required	Description	Default
`timezone`	Yes	IANA timezone name (e.g., 'America/New_York', 'Europe/London'). Use 'UTC' as local timezone if no timezone provided by the user.

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It states what the tool does but lacks behavioral details like whether it's real-time, cached, has rate limits, error handling for invalid timezones, or output format. For a tool with zero annotation coverage, this is insufficient disclosure.

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?

The description is a single, efficient sentence that directly states the tool's purpose. It's appropriately sized for a simple tool, though the plural 'timezones' is slightly awkward. No wasted words or unnecessary elaboration.

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

Completeness2/5

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

Given no annotations and no output schema, the description is incomplete. It doesn't explain what format the time is returned in (e.g., ISO string, timestamp), whether it includes date, or how errors are handled. For a tool with rich context needs (timezone validation, output format), this leaves significant gaps.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema fully documents the single parameter. The description adds no additional parameter semantics beyond implying timezone specificity, which is already clear from the schema. Baseline 3 is appropriate when schema does all the work.

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

Purpose4/5

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

The description clearly states the verb ('Get') and resource ('current time'), specifying it's for specific timezones. It's unambiguous about what the tool does, though it doesn't need to distinguish from siblings since there are none. The minor grammatical issue ('timezones' plural) doesn't affect clarity.

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

Usage Guidelines3/5

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

The description implies usage when current time in a specific timezone is needed, but provides no explicit guidance on when to use it versus alternatives (though none exist here) or any prerequisites. It's adequate for a simple tool with no siblings.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

2 tool updatesv0.6.2Feb 6, 2026
- First observedconvert_time
- First observedget_current_time

Deploy Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.1/5.0

Scored 2026-04-18 06:45 across 2 tools

Disambiguation5/5

The two tools have clearly distinct purposes: one converts time between timezones, while the other retrieves the current time in a specified timezone. There is no overlap in functionality, making it easy for an agent to select the correct tool based on the task.

Naming Consistency5/5

Both tools follow a consistent verb_noun pattern (convert_time, get_current_time) with clear, descriptive names. The naming style is uniform and predictable across the set.

Tool Count2/5

With only two tools, the server feels thin for a time-related domain. While the tools cover basic operations, the scope is limited, and additional functionalities like scheduling, time calculations, or date manipulations might be expected but are missing.

Completeness2/5

The tool set is severely incomplete for a time server. It lacks essential operations such as date parsing, time arithmetic, scheduling, or recurring event handling, which are common in time-related applications. This will likely cause agent failures when more complex time tasks are required.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

time A
pro.worldclock
A real clock for AI agents: current time, timezone conversion, and DST facts from the IANA tzdb.
Developer Tools
52
World Time A
com.invokera
Current time in any IANA time zone, plus the full time-zone list. Via timeapi.io.
Location Services
22
time-mcp A
io.github.jmavid
Current time, timezone conversion & date math for AI agents. On Cloudflare Workers.
Developer Tools
2
chrono-mcp A
io.github.nexus-api-lab
Deterministic time tools for AI agents: timezone conversion, business-day math, cron interpretation.
Developer Tools Calendar Management
2

Related MCP Servers

Time MCP Server
Developer Tools
dumyCq
A
license
B
quality
D
maintenance
Provides time and timezone functionality for LLMs, enabling them to get current time information across different timezones and convert times between zones.
Updated a year ago (2025-08-15 01:01 UTC)
2
MIT
Time MCP Server
asaficontact
A
license
B
quality
D
maintenance
Provides current time information and timezone conversion capabilities using IANA timezone names. Enables LLMs to get current time in any timezone and convert times between different timezones with automatic system timezone detection.
Updated a year ago (2025-10-02 02:44 UTC)
2
MIT
Time MCP Server
Taki-Ta
A
license
B
quality
D
maintenance
Enables LLMs to retrieve current time information for specific IANA timezones or the local system timezone. It provides accurate ISO 8601 timestamps and detects daylight saving time status for requested locations.
Updated a year ago (2025-06-20 02:44 UTC)
1
2
MIT
Time MCP Server
Search
CarterPape
A
license
Not graded
quality
D
maintenance
Provides current time information and timezone conversion capabilities using IANA timezone names and automatic system detection. It enables LLMs to fetch current times across different regions and convert specific times between timezones.
Updated a year ago (2025-06-21 23:27 UTC)
MIT