The datetime-mcp server exposes the host OS clock as MCP tools over stdio transport, providing lightweight date/time utilities:
Get current date/time (datetime.now): Retrieve the current date and time from the host OS clock, optionally specifying an IANA timezone (e.g., America/New_York). Returns UTC ISO string, epoch milliseconds, and a human-readable format.
Parse a date/time string (datetime.parse): Convert any JS Date-compatible string into canonical forms (UTC ISO, epoch milliseconds, human-readable). Optionally accepts an IANA timezone for localized output.
Check server health (datetime.health): Retrieve server metrics including wall clock epoch time, monotonic time (immune to NTP adjustments), and process uptime in milliseconds.
A default timezone can be configured via the MCP_TZ environment variable (defaults to Australia/Perth). The server can be run via npx, global npm install, or local development, and integrates with Claude Code or Claude Desktop.
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., "@datetime-mcp What's the current time in New York?"
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 lightweight MCP server that exposes the host OS clock as date/time tools over stdio transport.
npx datetime-mcpOr install globally:
npm install -g datetime-mcpRelated MCP server: Utility MCP Server
datetime.nowReturns the current date/time from the host OS clock.
Parameter | Required | Description |
| no | IANA timezone (e.g. |
{
"tz": "Australia/Perth",
"utcIso": "2026-01-22T03:30:00.000Z",
"epochMs": 1737516600000,
"human": "Thu, 22 Jan 2026, 11:30:00 AWST"
}datetime.parseParses a date/time string and returns canonical forms.
Parameter | Required | Description |
| yes | Date/time string parseable by JS |
| no | IANA timezone for human-readable output |
{
"input": "2026-01-22",
"tz": "Australia/Perth",
"utcIso": "2026-01-22T00:00:00.000Z",
"epochMs": 1737504000000,
"human": "Thu, 22 Jan 2026, 08:00:00 AWST"
}datetime.healthReturns server health metrics including monotonic time (won't jump with NTP adjustments).
{
"wallEpochMs": 1737516600000,
"monotonicMs": 12345678,
"processUptimeMs": 5000
}Add to ~/.claude/settings.json or project .mcp.json:
{
"mcpServers": {
"datetime": {
"command": "npx",
"args": ["-y", "datetime-mcp"],
"env": {
"MCP_TZ": "Australia/Perth"
}
}
}
}Add to your Claude Desktop MCP config:
{
"mcpServers": {
"datetime": {
"command": "npx",
"args": ["-y", "datetime-mcp"],
"env": {
"MCP_TZ": "Australia/Perth"
}
}
}
}Variable | Default | Description |
|
| Default IANA timezone |
pnpm install
pnpm dev # run with tsx (hot reload)
pnpm build # compile TypeScript
pnpm start # run compiled outputMIT
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| tz | No | IANA timezone, e.g. Australia/Perth |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | A date/time string parseable by JS Date | |
| tz | No | IANA timezone, e.g. Australia/Perth |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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.1.0datetime.healthdatetime.nowdatetime.parseThe three tools have clearly distinct purposes: health likely checks server status, now retrieves the current datetime, and parse converts datetime strings. There is no overlap or ambiguity between these functions.
All tool names follow a consistent pattern with a common prefix 'datetime.' and clear, concise suffixes (health, now, parse). This uniformity makes the set predictable and easy to understand.
Three tools is a borderline count for a datetime server; it covers basic operations but feels thin, potentially lacking advanced features like formatting, timezone handling, or date arithmetic that might be expected in this domain.
The tool set is significantly incomplete for datetime operations; it includes core functions (now, parse) but lacks essential tools for formatting, timezone conversion, date arithmetic, or validation, which are common in datetime libraries and could cause agent failures.
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.
A time server that keeps your AI honest about time. Real clock + drift guard, zero dependencies.
Current time, timezone conversion & date math for AI agents. On Cloudflare Workers.
Deterministic time tools for AI agents: timezone conversion, business-day math, cron interpretation.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/joshuaboys/datetime-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
