Skip to main content
Glama
biswajitpanday

currentdt-mcp

@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

npm version node License: MIT TypeScript

πŸ“‘ 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-mcp

Requires 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 a convert_timezone tool that is DST-correct for the date in question

  • Multiple Formats - ISO 8601, named patterns, token patterns (YYYY-MM-DD HH:mm Z)

  • Structured output - structuredContent with a declared schema, plus plain text for older clients

  • Zero Configuration - npx -y and 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 for local, offset, timezone and any token format. Defaults to the host's zone. iso/utc are 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 and from is required.

  • from (optional): IANA zone the wall-clock time was read in.

  • to (required): IANA zone to convert into.

  • format (optional): token pattern for the text result, rendered in to.

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 in timezone (default: the host's zone). Add the Z token to emit the real UTC offset -- never write a literal Z into 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

"iso"

2025-08-26T14:30:00.123Z

UTC

"YYYY-MM-DD"

2025-08-26

local

"YYYY-MM-DD HH:mm:ss"

2025-08-26 16:30:00

local

"MM/DD/YYYY"

08/26/2025

local

"YYYY-MM-DD-HHmmss"

2025-08-26-163000

local

"YYYY-MM-DDTHH:mm:ss.SSSZ"

2025-08-26T16:30:00.123+02:00

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 --test

Debug Mode

export CURRENTDT_DEBUG=true
npx @strix-ai/currentdt-mcp

Development

git clone https://github.com/biswajitpanday/CurrentDT-mcp.git
cd currentdt-mcp
npm install
npm run dev

npm Scripts

  • npm run build - Build TypeScript

  • npm test - Run all tests

  • npm run lint - ESLint check

  • npm run format - Prettier format

Contributing

  1. Fork the repository

  2. Create a feature branch: git checkout -b feature/amazing-feature

  3. Commit changes: git commit -m 'Add amazing feature'

  4. Push to branch: git push origin feature/amazing-feature

  5. Open a Pull Request

License

MIT License - see LICENSE file for details.


Made with ❀️ by Biswajit Panday

Available Tools

1 tool
get_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.

ParametersJSON Schema
NameRequiredDescriptionDefault
formatNoDate 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
providerNoDateTime provider: "local" for system clock (default), "remote" for network time servicelocal

TDQS

A4/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 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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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. 1 tool updatev1.1.7
    • First observedget_current_datetime

TDQS

A4.2/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility of confusion or overlap. The tool's purpose is crystal clear and distinct.

Naming Consistency5/5

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.

Tool Count4/5

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.

Completeness5/5

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

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    B
    quality
    D
    maintenance
    A Model Context Protocol server that provides tools to get the current date and time in various formats, supporting different timezones and custom formatting options.
    1
    13 npm
    1
    MIT
  • A
    license
    C
    quality
    D
    maintenance
    Provides 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.
    2
    10 npm
    MIT
  • A
    license
    A
    quality
    Not graded
    maintenance
    Provides 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.
    4
    7 npm
    -