Skip to main content
Glama

datetime_current_time

Read-onlyIdempotent

Retrieves the current date and time, optionally for a specified timezone and format, for scheduling, logging, or timestamping workflows.

Instructions

Get the current date and time, optionally in a specific timezone.

Input Schema

NameRequiredDescriptionDefault
formatNo
timezoneNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.5

TDQS

C2.8/5.0
Behavior2/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered. The description adds nothing beyond that—it does not disclose the default timezone, the expected format semantics, or the shape of the returned value.

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?

A single front-loaded sentence with no wasted words. It is appropriately sized for a simple two-parameter utility.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with zero schema descriptions and no output schema, the description leaves the format parameter completely opaque and the default timezone unstated. An agent cannot reliably use the format option based on the provided definition.

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

Parameters2/5

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

Schema description coverage is 0% for both parameters. The description mentions the timezone parameter implicitly ("optionally in a specific timezone") but says nothing about the format parameter—whether it accepts strftime-style tokens, ISO 8601, or something else. It fails to compensate for the documentation gap.

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 description states a specific verb ("Get") and resource ("current date and time") with an optional timezone qualifier, so the core operation is unambiguous. However, it offers no differentiation from a crowded set of datetime siblings such as time_api_current_by_zone, epoch_now, or datetime_convert_timezone.

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

Usage Guidelines2/5

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

The only usage hint is that a timezone can optionally be supplied. It never says when to choose this tool over siblings like time_api_current_by_zone or datetime_convert_timezone, nor does it state the default timezone behavior when the parameter is omitted.

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