Skip to main content
Glama
Sign In
mcp-datetime

mcp-datetime

by ZeparHyfar
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

get_datetime

Retrieves the current date and time in a specified format or custom pattern, optionally using an IANA timezone instead of the server's local time.

Instructions

Get the current date and time in the given format.

The time is in the local timezone of the machine running the server, unless 'timezone' is given as an IANA name such as 'Asia/Tokyo' or 'UTC'.

'format' is one of the format names below, or a custom pattern containing '%'. Custom patterns accept strftime directives (%Y %m %d %H %M %S %a %A %b %B %z %Z %j ...), %-m %-d %-H %-M %-S %-I %-j %-y for no leading zero, and these Japanese directives: %Je era name (令和), %JE era initial (R), %Jy era year (元 for year 1), %JY era year (always a number), %Ja weekday (火), %JA weekday (火曜日). Example: '%Je%Jy年%-m月%-d日（%Ja）' -> 令和6年12月10日（火）. Japanese era is supported from 1873-01-01.

Available formats (example: 2024-12-10 00:54:01 JST):

  • date: 2024-12-10

  • date_slash: 2024/12/10

  • date_jp: 2024年12月10日

  • datetime: 2024-12-10 00:54:01

  • datetime_jp: 2024年12月10日 00時54分01秒

  • datetime_t: 2024-12-10T00:54:01

  • compact: 20241210005401

  • compact_date: 20241210

  • compact_time: 005401

  • filename_md: 20241210005401.md

  • filename_txt: 20241210005401.txt

  • filename_log: 20241210005401.log

  • iso: 2024-12-10T00:54:01+0900

  • iso_basic: 20241210T005401+0900

  • log: 2024-12-10 00:54:01.123456

  • log_compact: 20241210_005401

  • time: 00:54:01

  • time_jp: 00時54分01秒

  • date_wareki: 令和6年12月10日

  • datetime_wareki: 令和6年12月10日 00時54分01秒

  • date_wareki_short: R6.12.10

  • date_jp_weekday: 2024年12月10日（火）

  • datetime_jp_weekday: 2024年12月10日（火） 00時54分01秒

  • weekday_jp: 火曜日

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "format": "<format>"
    },
    "name": "get_datetime"
  }
}

Input Schema

NameRequiredDescriptionDefault
formatYesFormat name such as 'datetime', or a custom pattern containing '%'. See the tool description.
timezoneNoIANA timezone name such as 'Asia/Tokyo', 'UTC' or 'America/New_York'. Omit to use the local timezone of the machine.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • changedInput schema / properties / format / description
      Previous value: -"\nAvailable formats:\n- date: 2024-12-10\n- date_slash: 2024/12/10\n- date_jp: 2024年12月10日\n- datetime: 2024-12-10 00:54:01\n- datetime_jp: 2024年12月10日 00時54分01秒\n- datetime_t: 2024-12-10T00:54:01\n- compact: 20241210005401\n- compact_date: 20241210\n- compact_time: 005401\n- filename_md: 20241210005401.md\n- filename_txt: 20241210005401.txt\n- filename_log: 20241210005401.log\n- iso: 2024-12-10T00:54:01+0900\n- iso_basic: 20241210T005401+0900\n- log: 2024-12-10 00:54:01.123456\n- log_compact: 20241210_005401\n- time: 00:54:01\n- time_jp: 00時54分01秒\n"New value: +"Format name such as 'datetime', or a custom pattern containing '%'. See the tool description."
    • addedInput schema / properties / format / title
      Added value: +"Format"
    • addedInput schema / properties / timezone
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "IANA timezone name such as 'Asia/Tokyo', 'UTC' or 'America/New_York'. Omit to use the local timezone of the machine.",
+  "title": "Timezone"
+}
    • addedInput schema / title
      Added value: +"get_datetimeArguments"
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "result": {
+      "title": "Result",
+      "type": "string"
+    }
+  },
+  "required": [
+    "result"
+  ],
+  "title": "get_datetimeOutput",
+  "type": "object"
+}
  2. First observed

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden and does well: it discloses the default timezone source (the server machine's local zone), the IANA override, the full set of supported directives, and a concrete boundary condition (Japanese era supported from 1873-01-01). It says nothing about side effects, cost, or rate limits, though for a pure clock read those gaps are minor.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose, timezone behavior, then format reference is a sensible front-loaded order. The 25-item format table is long but earns its place because the schema declares no enum, so this is the only place the valid names exist; a slightly tighter grouping of the filename_* and wareki variants would trim it further.

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?

An output schema exists, so return-value explanation is correctly omitted, and both parameters are fully covered with defaults and fallback behavior. The one missing piece relative to a four-tool family is routing guidance distinguishing this from the conversion, shifting, and info siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, yet the description goes well beyond it by enumerating every accepted format name with a rendered example and by documenting custom strftime patterns and the Japanese %J directives that the schema only alludes to. That is exactly the meaning an agent needs to construct a valid 'format' value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence gives a specific verb and resource ('Get the current date and time') plus the format scoping. It never mentions the siblings convert_time, shift_datetime, or get_datetime_info, so an agent cannot tell from the description alone that this tool only reads the current instant rather than converting or offsetting one.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: 'current' signals a read of now, and the timezone sentence hints at localization. There is no explicit statement about when to prefer get_datetime_info over this tool, or that this tool is inappropriate for arithmetic on existing timestamps (which the sibling tools cover).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools