DateTime MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| TIMEFMT | No | Time format: "12" for 12-hour (2:30 PM) or "24" for 24-hour (14:30). Values other than "12" default to 24-hour format. | |
| DEFAULT_TZ | No | Timezone identifier (e.g., "America/New_York", "Europe/London", "UTC"). Invalid timezone defaults to UTC. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Server capabilities have not been inspected yet.
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_current_dateA | Get the current date in ISO format (YYYY-MM-DD). Args: include_weekday: Whether to append the day of the week Returns: ISO date string, optionally with weekday Examples: get_current_date() -> "2024-01-15" get_current_date(include_weekday=True) -> "2024-01-15 (Monday)" |
| get_current_timeA | Get the current time in the configured format. Returns: Time string in 12-hour or 24-hour format based on TIMEFMT setting Examples: With TIMEFMT="12": "2:30 PM" With TIMEFMT="24": "14:30" |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
The two tools have clearly distinct purposes: get_current_date retrieves date information, while get_current_time retrieves time information. There is no overlap in functionality, and an agent would easily differentiate between them based on their names and descriptions.
Both tools follow a consistent verb_noun pattern with 'get_current_' prefix, using snake_case throughout. The naming is predictable and readable, with no deviations in style or convention.
With only two tools, the server feels thin for a DateTime domain. A comprehensive DateTime server would typically include tools for date/time manipulation, formatting, timezone handling, or date arithmetic, not just current date and time retrieval.
The toolset is severely incomplete for a DateTime server. It lacks basic operations like date/time parsing, formatting control, timezone conversions, date arithmetic (add/subtract days), or comparisons. Agents will hit dead ends when needing anything beyond current date/time retrieval.