Skip to main content
Glama

get_current_time

Read-onlyIdempotent

Returns the current time for one identified city, location query, or IANA timezone, helping answer local-time questions while avoiding ambiguous or unknown locations.

Instructions

Return the production current time payload for a single already-identified city, query, or IANA timezone. Do not use this for conversions, overlaps, or meeting search. If the city is unknown or could be more than one place, call search_timezones and retry with suggestedQuery or countryCode; do not guess. Exact country-name queries may be retried through a canonical city when the resolver can do so deterministically. For relative-date inputs ("Tuesday", "next Friday", "tomorrow", "tonight"), route to answer_time_question.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_current_time"
  }
}

Input Schema

NameRequiredDescriptionDefault
cityNoCity name such as "Tokyo".
queryNoFree-form location query, country name, or timezone abbreviation.
timezoneNoDirect IANA timezone, such as "Europe/London".
_endUserIdNoOptional opaque per-call end-user attribution token populated by the MCP host, not the LLM. Use a non-PII hash or token; never send raw email, name, or platform user ID.
countryCodeNoOptional ISO country hint for ambiguous city names.
candidateLimitNoPage size for namesake candidates. Default 6. Follow moreCandidates.resolve or moreCandidates.search for the rest.
candidateOffsetNoSkip this many namesake candidates. Copy from moreCandidates.candidateOffset.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv3.28.1
    • addedInput schema / properties / candidateLimit
      Added value: +{
      +  "description": "Page size for namesake candidates. Default 6. Follow moreCandidates.resolve or moreCandidates.search for the rest.",
      +  "maximum": 50,
      +  "minimum": 1,
      +  "type": "integer"
      +}
    • addedInput schema / properties / candidateOffset
      Added value: +{
      +  "description": "Skip this many namesake candidates. Copy from moreCandidates.candidateOffset.",
      +  "minimum": 0,
      +  "type": "integer"
      +}
  2. First observedv3.27.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds genuine behavioral context beyond that: it will not guess on ambiguity, it exposes a namesake-candidate paging flow, and it hints at deterministic resolver behavior for country names. It stops short of describing the shape of the returned time payload, but that is a modest gap given a read-only tool.

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?

The purpose and the primary exclusion are front-loaded, and most sentences carry actionable routing information. One sentence ("Exact country-name queries may be retried through a canonical city when the resolver can do so deterministically") is dense and somewhat opaque, costing a point on crispness rather than on length.

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?

For a 7-parameter read-only lookup with no output schema, the description covers the decision path, ambiguity handling, and paging hand-off, which is most of what an agent needs. It never describes what the returned current-time payload contains, and it references output-side fields (moreCandidates.resolve, moreCandidates.candidateOffset) that only the schema text explains, leaving a small completeness gap.

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

Parameters4/5

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

Schema description coverage is 100%, so the baseline would be 3. The description still earns extra credit by implying the three location inputs are mutually exclusive alternatives ("a single ... city, query, or IANA timezone") and by framing countryCode as a disambiguation hint tied to the ambiguous-city retry path, which is cross-parameter meaning the per-field schema text does not convey.

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?

States a specific verb and resource ("Return the production current time payload") and narrows the scope to "a single already-identified city, query, or IANA timezone." It then explicitly names what it is not for (conversions, overlaps, meeting search), so an agent can separate it from convert_time, get_overlap_hours, and find_meeting_time without reading any schema.

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

Usage Guidelines5/5

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

Gives explicit when-not rules ("Do not use this for conversions, overlaps, or meeting search") and names the concrete fallbacks: search_timezones for unknown/ambiguous cities, and answer_time_question for relative-date inputs. It even prescribes the retry payload (suggestedQuery or countryCode) and forbids guessing, leaving almost nothing to inference.

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