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 is the current time in Tokyo?"
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.
基于官方MCP项目修改
原作者：Mariusz 'maledorak' Korzekwa
原仓库：modelcontextprotocol/servers
原项目路径：src/time
A Model Context Protocol server that provides time capabilities. This server enables LLMs to get current time information 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')
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_timeBuild and run with mcp-proxy for HTTP/SSE access:
# Build the SSE-enabled Docker image
docker build -f Dockerfile.sse -t mcp-time-sse .
# Run the container (accessible via HTTP on port 8999)
docker run -p 8999:8999 mcp-time-sseRelated MCP server: Timezone MCP Server
Add to your Claude settings:
{
"mcpServers": {
"time": {
"command": "uvx",
"args": ["mcp-server-time", "--local-timezone", "Asia/Shanghai"]
}
}
}{
"mcpServers": {
"time": {
"command": "uv",
"args": [
"run",
"--directory",
"D:/WorkSpace/demo/servers/src/time",
"mcp-server-time",
"--local-timezone",
"Asia/Shanghai"
]
}
}
}{
"mcpServers": {
"time": {
"command": "docker",
"args": ["run", "-i", "--rm", "mcp/time"]
}
}
}{
"mcpServers": {
"time": {
"command": "python",
"args": ["-m", "mcp_server_time", "--local-timezone", "Asia/Shanghai"]
}
}
}Add to your Zed settings.json:
"context_servers": [
"mcp-server-time": {
"command": "uvx",
"args": ["mcp-server-time", "--local-timezone", "Asia/Shanghai"]
}
],"context_servers": {
"mcp-server-time": {
"command": "python",
"args": ["-m", "mcp_server_time", "--local-timezone", "Asia/Shanghai"]
}
},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", "--local-timezone", "Asia/Shanghai"]
}
}
}
}{
"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=Asia/Shanghai"]
}Get current time:
{
"name": "get_current_time",
"arguments": {
"timezone": "Asia/Shanghai"
}
}Response:
{
"timezone": "Asia/Shanghai",
"datetime": "2024-01-01T20:00:00+08:00",
"is_dst": false
}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?"
"What time is it in New York?"
"Get the current time in London"
Docker build:
cd src/time
docker build -t mcp/time .Docker build with SSE support:
cd time
docker build -f Dockerfile.sse -t mcp-time-sse .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.
Get current time in a specific timezones
| 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. |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.6.2get_current_timeWith only one tool, there is no possibility of ambiguity or overlap between tools. The single tool has a clear, distinct purpose that cannot be confused with any other tool in the set.
A single tool inherently has perfect naming consistency, as there are no other tools to compare it against. The tool name 'get_current_time' follows a clear verb_noun pattern, but consistency cannot be assessed across a set of one.
A single tool for a time server is too few for the apparent scope, as time-related operations typically include more functionality (e.g., time conversion, scheduling, or date calculations). This minimal set feels thin and underdeveloped for the domain.
The tool set is severely incomplete for a time server, covering only current time retrieval in specific timezones. Obvious gaps include time conversion between zones, date arithmetic, scheduling, or historical time data, which agents would need for common time-related tasks.
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 in any IANA time zone, plus the full time-zone list. Via timeapi.io.
Current time, timezone conversion & date math for AI agents. On Cloudflare Workers.
Get the current time in any timezone. Explore concise timezone info to pick the right region. Simp…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Taki-Ta/mcp-server-time'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
