A
licenseA
qualityC
maintenanceProvides LLMs with current date and time information across any timezone, with configurable defaults and support for IANA timezone identifiers.
1
16 npm
3
Apache 2.0
clock-mcp
by garland3
Click on "Deploy 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., "@clock-mcpwhat's 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.
clock-mcp
A one-tool MCP server that tells the model what day and time it is.
Why
Language models have no clock. Asked for today's date, a model with tools will reach for whatever search tool is in reach — a billed API call and a network round trip to learn something the machine it is running on already knows, and often an answer scraped off a page that is itself stale.
This is the cheap answer: read the system clock, return it. No network, no API key, no state on disk.
Related MCP server: Time MCP Server
The tool
get_current_time(timezone_name: str | None = None)
timezone_name takes an IANA name (America/Denver, Asia/Tokyo) or UTC.
Omit it for the host's local zone. An unknown name raises an error rather than
silently falling back to UTC — a wrong timezone is worse than a refusal.
{
"iso8601": "2026-09-13T14:05:09-06:00",
"date": "2026-09-13",
"time": "14:05:09",
"day_of_week": "Sunday",
"timezone": "America/Denver",
"timezone_abbreviation": "MDT",
"utc_offset": "-06:00",
"utc_iso8601": "2026-09-13T20:05:09+00:00",
"unix_timestamp": 1789243509,
"human": "Sunday, September 13, 2026 at 2:05 PM MDT"
}Both a machine half and a human half, because callers want different ones:
date and unix_timestamp for arithmetic, human for dropping straight into
a reply.
Install
git clone https://github.com/garland3/clock-mcp.git
cd clock-mcp
uv venv && uv pip install -e '.[dev]'
.venv/bin/clock-mcp --list-tools # get_current_time
.venv/bin/python -m pytest -qRegister it
Claude Code:
claude mcp add clock -- /path/to/clock-mcp/.venv/bin/clock-mcp --stdioAnything that reads a JSON MCP config:
{
"clock": {
"command": ["/path/to/clock-mcp/.venv/bin/clock-mcp", "--stdio"],
"transport": "stdio"
}
}One implementation note
The default zone is resolved from $TZ or the /etc/localtime symlink, not
from datetime.now().astimezone(). That call only ever yields a fixed offset
named for the current abbreviation (MDT), which throws away both the zone name
and its DST rules — so the tool would report MDT where you want
America/Denver. tzdata is a dependency so named zones resolve even on a host
with no system zoneinfo tree.
License
MIT
Available Tools
1 toolget_current_timeA
Return the current date, time, and timezone. Use this rather than a web search.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| timezone_name | No | Optional IANA timezone name, e.g. 'America/Denver', 'Asia/Tokyo', or 'UTC'. Omit for the server's local timezone. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.1/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the output (date, time, timezone) but does not explicitly disclose side effects, failure modes, or error handling. For a simple lookup tool this is acceptable but not fully transparent.
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 two short sentences, front-loaded with the core behavior and the practical guidance. Every word earns its place, with no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, an output schema already present), the description and schema together fully specify what an agent needs to know. There are no missing pieces for correct selection or invocation.
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 schema already provides 100% coverage of the parameter semantics, including the optional timezone_name, default behavior, and examples. The description adds no further meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Return the current date, time, and timezone.' It clearly distinguishes itself from a web search and leaves no doubt about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit directive: 'Use this rather than a web search,' which tells the agent when to select this tool over an alternative. However, it does not discuss when not to use it or when the timezone parameter should be provided, leaving some guidance to the schema.
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.
1 tool update
v0.1.0- First observed
get_current_time
TDQS
A4.4/5.0
Scored across 1 tool
Disambiguation5/5
With only a single tool, there is no possibility of confusion between tools. The purpose is singular and the tool description clearly states what it does.
Naming Consistency5/5
The only tool name, get_current_time, follows a clean verb_noun snake_case pattern. Since there is just one tool, the naming is internally consistent.
Tool Count5/5
The server's entire purpose is to provide the current date and time, and one tool fully serves that purpose. A single tool is well-scoped and directly earns its place; adding more would be needless.
Completeness5/5
The domain is the current time, and get_current_time covers it completely by returning date, time, and timezone. There are no missing operations or workflows required for a clock server.
Maintenance
ActivityMaintained
ResponsivenessNo issues
Related MCP Connectors
Current time in any IANA time zone, plus the full time-zone list. Via timeapi.io.
Get the current time anywhere and access concise timezone information. Set your preferred timezone…
Get the current time in any timezone and quickly look up common timezone info. Set a default timez…
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceProvides 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.MIT
- FlicenseBqualityDmaintenanceProvides current time and timezone conversion using IANA timezone names, with automatic system timezone detection.2-
- AlicenseNot gradedqualityDmaintenanceExposes the host device's current date and time, returning local time with timezone offset or UTC.6MIT