currentdt-mcp
This MCP server gives AI assistants real-time date and time access with timezone-aware formatting.
Get current date/time in ISO 8601 or custom token formats (e.g.,
YYYY-MM-DD HH:mm:ss)Choose timezone via IANA names like
Asia/TokyoorEurope/BerlinSelect provider: local system clock or remote network time service
Convert timezones with DST-correct offsets for the given date
Structured output: returns both human-readable text and machine-readable
structuredContentwith UTC, local time, offset, timezone, and epoch millisecondsUse in workflows: timestamped migrations, logs, changelogs, filenames, and dated documentation
MCP-compatible: works with Cursor, Claude Desktop, VS Code, Windsurf, and other MCP clients
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., "@currentdt-mcpWhat's the current date and time in ISO format?"
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.
@strix-ai/currentdt-mcp
Real-time date and time access for AI assistants via Model Context Protocol (MCP)
Built for AI, Built with AI - Enhancing AI assistant capabilities through intelligent tooling
π Table of Contents
Related MCP server: DateTime MCP Server
Overview
@strix-ai/currentdt-mcp is an MCP server that provides AI assistants with instant access to current date and time information. Essential for generating timestamped code, migration files, and dated documentation.
Quick Start
# No install required -- point your MCP client at npx (see integration guides below)
npx -y @strix-ai/currentdt-mcp
# Or install globally
npm install -g @strix-ai/currentdt-mcpRequires Node.js 18 or newer.
User Flow
βββββββββββββββββββββββ βββββββββββββββββββ βββββββββββββββββββββββ
β User Asks for βββββΆβ AI Assistant βββββΆβ get_current_ β
β Timestamped Code β β β β datetime Tool β
βββββββββββββββββββββββ βββββββββββββββββββ βββββββββββββββββββββββ
β
βΌ
βββββββββββββββββββββββ βββββββββββββββββββ βββββββββββββββββββββββ
β Timestamped Output ββββββ Current Time ββββββ CurrentDT MCP β
β Generated β β Returned β β Server β
βββββββββββββββββββββββ βββββββββββββββββββ βββββββββββββββββββββββ
β
βΌ
βββββββββββββββββββ βββββββββββββββββββββββ
β Formatted ββββββ Local/Remote β
β DateTime β β Time Provider β
βββββββββββββββββββ βββββββββββββββββββββββCore Features
Never ambiguous about timezone - every response states the same instant as UTC, as local time with its real offset, and as epoch milliseconds
Any IANA timezone -
timezone: "Asia/Tokyo"on the current time, and aconvert_timezonetool that is DST-correct for the date in questionMultiple Formats - ISO 8601, named patterns, token patterns (
YYYY-MM-DD HH:mm Z)Structured output -
structuredContentwith a declared schema, plus plain text for older clientsZero Configuration -
npx -yand go; Node 18+MCP Compatible - Cursor, Claude Desktop, VS Code, Windsurf
MCP Client Integration
Every client below uses the same server entry. npx -y fetches the package on first
use and suppresses the install prompt, so nothing needs to be installed beforehand.
{
"command": "npx",
"args": ["-y", "@strix-ai/currentdt-mcp"]
}Cursor
Add to ~/.cursor/mcp.json (global) or .cursor/mcp.json in a project:
{
"mcpServers": {
"currentdt": {
"command": "npx",
"args": ["-y", "@strix-ai/currentdt-mcp"]
}
}
}Claude Desktop
One-click: download currentdt-mcp.mcpb from the
latest release and
open it -- Claude Desktop installs it as an extension. No Node, npm or config file needed.
Or by config: edit claude_desktop_config.json -- on macOS at
~/Library/Application Support/Claude/, on Windows at %APPDATA%\Claude\:
{
"mcpServers": {
"currentdt": {
"command": "npx",
"args": ["-y", "@strix-ai/currentdt-mcp"]
}
}
}VS Code
Add to .vscode/mcp.json in a workspace, or under "mcp" in user settings.json:
{
"servers": {
"currentdt": {
"command": "npx",
"args": ["-y", "@strix-ai/currentdt-mcp"]
}
}
}Windsurf
Add to ~/.codeium/windsurf/mcp_config.json, same mcpServers shape as Cursor.
Installed globally instead
If you prefer a fixed install over npx, run npm install -g @strix-ai/currentdt-mcp
and use "command": "currentdt-mcp" with no args in any of the configs above.
Real-World Usage Examples
1. SQL Migration Files
User: "Create a migration to add user preferences table"
Result: Migration file named 2025-08-26-143000_add_user_preferences.sql with current timestamp
MCP Tool Call Example:
{
"tool": "get_current_datetime",
"arguments": {
"format": "YYYY-MM-DD-HHmmss",
"provider": "local"
}
}2. Timestamped Logging
User: "Generate a logger that includes timestamps"
Result: Logger implementation with current ISO datetime format
3. Dated Documentation
User: "Update the changelog with today's date"
Result: Changelog entry with current date: ## [Unreleased] - 2026-09-16
API Reference
Tool: get_current_datetime
Parameters:
format(optional):"iso"(default) or a token pattern like"YYYY-MM-DD HH:mm:ss"timezone(optional): IANA name, e.g."Asia/Tokyo". Sets the zone forlocal,offset,timezoneand any token format. Defaults to the host's zone.iso/utcare always UTC regardless.provider(optional):"local"(default) or"remote"
Returns: the formatted string as text content, plus structuredContent stating the
same instant from every clock -- so there is never any doubt whether a value is UTC or local:
{
"formatted": "2026-09-16 16:01:08",
"iso": "2026-09-16T14:01:08.624Z",
"utc": "2026-09-16T14:01:08.624Z",
"local": "2026-09-16T16:01:08.624+02:00",
"offset": "+02:00",
"timezone": "Europe/Berlin",
"epochMs": 1789567268624,
"provider": "local"
}Invalid input (a token-less format, an unknown timezone, a failed provider) comes
back as a tool error (isError: true) with a message written to be read by the model.
Tool: convert_timezone
Re-states a time in another zone, DST-correct for the date -- the case where a remembered offset is most likely wrong.
Parameters:
time(required): ISO 8601. With an offset ("2026-03-29T01:30:00+01:00","...Z") it pins an instant. Without one it is a wall-clock reading andfromis required.from(optional): IANA zone the wall-clocktimewas read in.to(required): IANA zone to convert into.format(optional): token pattern for the text result, rendered into.
Returns: the same structured shape as above (minus provider), plus from and
dstTransition -- true when the instant is within an hour of a DST changeover in to.
{
"tool": "convert_timezone",
"arguments": { "time": "2026-07-15T09:00:00", "from": "America/New_York", "to": "Europe/Berlin" }
}Result: local: "2026-07-15T15:00:00.000+02:00". The same call for a January date yields
+01:00, because the offset follows the calendar, not a constant.
A wall-clock time that never exists (the spring-forward gap) resolves to the instant
after the gap; one that exists twice (the autumn repeat) resolves to the first. An
offset-less time with no from is refused rather than guessed.
Example:
{
"tool": "get_current_datetime",
"arguments": {
"format": "YYYY-MM-DD HH:mm:ss",
"provider": "local"
}
}Configuration (Optional)
Create currentdt-config.json for custom settings:
{
"defaultFormat": "iso",
"defaultProvider": "local",
"providers": {
"local": { "name": "local", "priority": 1 },
"remote": {
"name": "remote",
"priority": 2,
"config": {
"url": "https://worldtimeapi.org/api/timezone/UTC",
"timeout": 5000
}
}
},
"debug": false,
"logLevel": "error"
}Environment variables override the file: CURRENTDT_FORMAT, CURRENTDT_PROVIDER,
CURRENTDT_DEBUG, CURRENTDT_CONFIG.
Common Format Patterns
Timezone:
"iso"returns UTC. Every token pattern renders the wall clock intimezone(default: the host's zone). Add theZtoken to emit the real UTC offset -- never write a literalZinto a pattern, since that would label local digits as UTC.
For timezone: "Europe/Berlin" (UTC+02:00 in summer), at the instant 2025-08-26T14:30:00.123Z:
format | output | zone |
|
| UTC |
|
| local |
|
| local |
|
| local |
|
| local |
|
| local + offset |
Tokens: YYYY MM DD HH mm ss SSS Z (+02:00) ZZ (+0200).
Named patterns: filename, logdate, simple.
A pattern must contain at least one token. Free text such as "what time is it" is
rejected rather than echoed back.
Troubleshooting
Tool Not Available
# Verify installation
npm list -g @strix-ai/currentdt-mcp
# Test server directly
npx @strix-ai/currentdt-mcp --testDebug Mode
export CURRENTDT_DEBUG=true
npx @strix-ai/currentdt-mcpDevelopment
git clone https://github.com/biswajitpanday/CurrentDT-mcp.git
cd currentdt-mcp
npm install
npm run devnpm Scripts
npm run build- Build TypeScriptnpm test- Run all testsnpm run lint- ESLint checknpm run format- Prettier format
Contributing
Fork the repository
Create a feature branch:
git checkout -b feature/amazing-featureCommit changes:
git commit -m 'Add amazing feature'Push to branch:
git push origin feature/amazing-featureOpen a Pull Request
Support & Links
Issues: GitHub Issues
Documentation: GitHub Repository
npm Package: @strix-ai/currentdt-mcp
Author: Biswajit Panday - AI-Assisted Development Enthusiast
Contributor: Abdullah Saleh Robin robinabdullah@yahoo.com
License
MIT License - see LICENSE file for details.
Made with β€οΈ by Biswajit Panday
Available Tools
1 toolget_current_datetimeA
Get the current date and time with optional formatting and provider selection. Essential for creating timestamped files, logs, database migrations, and any time-sensitive development tasks. Supports ISO format (default) and custom formats using tokens like YYYY, MM, DD, HH, mm, ss, SSS.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Date format: "iso" for ISO 8601 (default), or custom format using tokens (YYYY, MM, DD, HH, mm, ss, SSS). Common examples: "iso", "YYYY-MM-DD", "YYYY-MM-DD HH:mm:ss", "MM/DD/YYYY", "YYYY-MM-DD-HHmmss" | iso |
| provider | No | DateTime provider: "local" for system clock (default), "remote" for network time service | local |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of disclosing behavior. It mentions the ability to format output and select a provider, and implies a read-only operation with 'Get'. However, it does not clarify timezone behavior, potential latency with the remote provider, or safety characteristics. This is a moderate level of transparency, sufficient for a simple getter but with notable omissions.
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 two sentences, with the action verb and resource front-loaded in the first sentence. The second sentence adds use cases and format details, all relevant and without fluff. Every part earns its place, making it highly concise and well-structured.
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?
The tool is simple, with all parameters fully described in the schema. The description explains the intended output (a formatted string, with default ISO) and provides sufficient context for use. Minor gaps like explicit timezone handling or exact return type are inferable from the schema and tool nature, making this adequately complete, though not perfect.
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 input schema descriptions are comprehensive: `format` describes the ISO default and token examples, and `provider` explains local/remote options. The tool description repeats key points (ISO default, tokens, provider selection) but adds no new meaning beyond what the schema already provides. With 100% schema coverage, baseline of 3 is appropriate.
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 begins with 'Get the current date and time', which is a specific verb and resource. It also mentions optional formatting and provider selection, making the tool's purpose entirely clear. Though there are no sibling tools to differentiate, the description leaves no ambiguity 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists use cases: 'timestamped files, logs, database migrations, and any time-sensitive development tasks', giving clear context for when to use this tool. It does not state when not to use it, but since there are no alternative tools listed, the guidance is adequate, though slightly below the 'explicit when/when-not' standard.
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
v1.1.7- First observed
get_current_datetime
TDQS
Scored across 1 tool
With only one tool, there is no possibility of confusion or overlap. The tool's purpose is crystal clear and distinct.
The single tool name 'get_current_datetime' follows a clear verb_noun pattern, which is consistent and predictable even without other tools to compare against.
The server has exactly one tool, which is slightly below the typical 3-15 range, but it is perfectly appropriate for the narrow scope of providing current datetime functionality. The tool is not trivial and fully serves the server's purpose.
The sole tool covers the entire domain of retrieving current datetime, including optional formatting and provider selection. There are no obvious gaps or missing operations for this single-purpose server.
Maintenance
Related MCP Connectors
Current time, timezone conversion & date math for AI agents. On Cloudflare Workers.
A real clock for AI agents: current time, timezone conversion, and DST facts from the IANA tzdb.
Time and date math for AI agents: Unix timestamp conversion, DST-correct time zone conversion, durations, epoch arithmetic, cron schedules, and holiday countdowns. Eight tools, no key.
A time server that keeps your AI honest about time. Real clock + drift guard, zero dependencies.
Related MCP Servers
- AlicenseAqualityDmaintenanceA Model Context Protocol server for time manipulation tasks, enabling AI models to get the current date/time and calculate duration between timestamps.7258 npm2MIT
- AlicenseBqualityDmaintenanceA Model Context Protocol server that provides tools to get the current date and time in various formats, supporting different timezones and custom formatting options.113 npm1MIT
- AlicenseCqualityDmaintenanceProvides current time and date information with timezone support and multiple formatting options. Enables AI assistants to answer time-related queries in different timezones with detailed temporal information.210 npmMIT
- AlicenseAqualityNot gradedmaintenanceProvides AI assistants with real-time date, time, and timezone information, enabling them to access current temporal data, format dates, calculate day of week, and work with different timezones.47 npm-