Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Time MCP Server what time is it in Tokyo right now?"
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.
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.
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
When using uv no specific installation is needed. We will
use uvx to directly run mcp-server-time.
Alternatively you can install mcp-server-time via pip:
pip install mcp-server-timeAfter installation, you can run it as a script using:
python -m mcp_server_timeRelated MCP server: MCP Time Server
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"]
}
}
}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"]
}
},For quick installation, use one of the one-click install buttons below...
For manual installation, add the following JSON block to your User Settings (JSON) file in VS Code. You can do this by pressing Ctrl + Shift + P and typing Preferences: Open User Settings (JSON).
Optionally, you can add it to a file called .vscode/mcp.json in your workspace. This will allow you to share the configuration with others.
Note that the
mcpkey is needed when using themcp.jsonfile.
{
"mcp": {
"servers": {
"time": {
"command": "uvx",
"args": ["mcp-server-time"]
}
}
}
}{
"mcp": {
"servers": {
"time": {
"command": "docker",
"args": ["run", "-i", "--rm", "mcp/time"]
}
}
}
}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"]
}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",
}You can use the MCP inspector to debug the server. For uvx installations:
npx @modelcontextprotocol/inspector uvx mcp-server-timeOr 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"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"
Docker build:
cd src/time
docker build -t mcp/time .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.
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.
Convert time between timezones
| Name | Required | Description | Default |
|---|---|---|---|
| source_timezone | Yes | Source IANA timezone name (e.g., 'America/New_York', 'Europe/London'). Use 'Etc/UTC' as local timezone if no source timezone provided by the user. | |
| target_timezone | Yes | Target IANA timezone name (e.g., 'Asia/Tokyo', 'America/San_Francisco'). Use 'Etc/UTC' as local timezone if no target timezone provided by the user. | |
| time | Yes | Time to convert in 24-hour format (HH:MM) |
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 the tool's function but doesn't disclose behavioral traits like error handling, format validation, or what happens with invalid inputs. For a tool with no annotations, this leaves significant gaps in understanding its operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded and appropriately sized for the tool's complexity, making it easy to understand quickly without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on behavior, error cases, or output format, which are important for a conversion tool without structured output documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 all parameters. The description adds no additional meaning beyond what's in the schema, such as examples or edge cases. Baseline 3 is appropriate as the schema handles parameter documentation effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Convert time between timezones' clearly states the verb (convert) and resource (time), specifying the operation's scope. It distinguishes from the sibling 'get_current_time' by focusing on conversion rather than retrieval, though it doesn't explicitly mention this distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites, constraints, or compare it with 'get_current_time'. Usage is implied by the purpose but lacks explicit context 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 time in a specific timezones
| Name | Required | Description | Default |
|---|---|---|---|
| timezone | Yes | IANA timezone name (e.g., 'America/New_York', 'Europe/London'). Use 'Etc/UTC' as local timezone if no timezone provided by the user. |
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. It mentions getting current time but doesn't specify whether this requires authentication, has rate limits, returns errors for invalid timezones, or provides output format details. This leaves significant gaps for a tool that interacts with time data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's appropriately sized for a simple tool with one parameter and gets straight to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the output looks like (e.g., timestamp format, timezone handling), error conditions, or behavioral constraints. The simplicity of the tool doesn't compensate for these missing contextual elements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the parameter 'timezone' fully documented in the schema (including IANA format and default behavior). The description adds no additional parameter information beyond what's in the schema, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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' with the scope 'in a specific timezone', making the purpose understandable. However, it doesn't explicitly differentiate from the sibling tool 'convert_time', which likely handles time conversion rather than current time retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 the sibling 'convert_time' or any alternatives. It lacks context about when this tool is appropriate versus other time-related operations, offering only a basic functional statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0convert_timeget_current_timeThe two tools have clearly distinct purposes: one converts time between timezones, and the other retrieves the current time in a specific timezone. There is no overlap or ambiguity in their functions, making it easy for an agent to select the correct tool based on the task.
Both tool names follow a consistent verb_noun pattern (convert_time and get_current_time), using snake_case throughout. The naming is predictable and readable, with no deviations or mixed conventions.
With only 2 tools, the server feels thin for a time-related domain. While the tools cover basic time conversion and current time retrieval, there are likely missing operations such as time calculations, scheduling, or handling date formats, which could limit functionality for agents.
The tool surface is severely incomplete for a time server. It lacks essential operations like adding/subtracting time, parsing dates, formatting times, or handling recurring events. Agents will encounter dead ends when trying to perform common time-related tasks beyond the two provided tools.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A real clock for AI agents: current time, timezone conversion, and DST facts from the IANA tzdb.
Current time, timezone conversion & date math for AI agents. On Cloudflare Workers.
Timezone MCP — wraps WorldTimeAPI (free, no auth)
A time server that keeps your AI honest about time. Real clock + drift guard, zero dependencies.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ssinha3/mcp-time-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
