A real clock for AI agents: current time, timezone conversion, and DST facts from the IANA tzdb.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.8/5 across 5 of 5 tools scored.
Tools are mostly distinct, but convert_time and get_current_time have overlapping functionality as both can provide times for multiple locations at a given instant, potentially confusing an agent.
Most tools follow verb_noun pattern (convert_time, get_current_time, get_dst_transitions, search_cities), but time_by_coordinates deviates by starting with a noun, causing inconsistency.
With 5 tools, the server is well-scoped for a time utility, covering essential operations without being too sparse or excessive.
The tool set covers key time-related operations (current time, conversion, DST, location lookup), but lacks a direct tool for listing timezones or offsets, which is a minor gap.
convert_timeConvert a time across locationsAGiven a UTC instant (or a wall time in a source location), return the corresponding local time in each of up to 50 target locations. Results include a source_url linking the matching worldclock.pro page when available.
| Name | Required | Description | Default |
|---|---|---|---|
| utc | No | The instant to convert, as an ISO 8601 string. Read as UTC if it has no zone designator. | |
| from | No | Alternative to `utc`: a wall time in a specific source location. | |
| targets | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, idempotent, non-destructive behavior. The description adds that results include a source_url when available and the 50-target limit. No contradictions, but no further details on error handling or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with core purpose, no redundancy. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the main use cases and constraints (limit, source URL). But it lacks guidance on what happens if both 'utc' and 'from' are provided, and there is no output schema to describe the return format beyond 'local time'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (67%). The description adds meaning by clarifying that 'utc' is read as UTC if no zone designator and that 'from.location' requires exactly one identifier. These are useful but not critical beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: convert a given time (UTC instant or wall time in a source location) to local times for up to 50 target locations. This distinguishes it from siblings like get_current_time (which returns current time) and time_by_coordinates (likely single location).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies when to use the tool (given a UTC instant or wall time) and mentions the 50-location limit. However, it does not explicitly advise when not to use it or compare to sibling tools like search_cities or dst_transitions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_current_timeGet current timeAGet the current local time (or the time at a given instant) in one or more locations. Each location is a city name, an IANA timezone / abbreviation, or coordinates. Up to 50 locations. Results include a source_url linking the matching worldclock.pro page when available.
| Name | Required | Description | Default |
|---|---|---|---|
| at | No | Optional ISO 8601 instant to evaluate instead of now (read as UTC if it has no zone). | |
| locations | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds that results include a source_url, which is not in annotations, and mentions the optional 'at' instant. However, it does not describe the return format (e.g., array of time objects) or any rate limits, so behavioral disclosure is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences. The first sentence states the core purpose, and the second provides details on input types and constraints. Every sentence adds value without redundancy, making it efficient for an AI agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should convey the return structure. It only mentions a 'source_url' link, leaving the agent to guess whether the returned data includes the time value (likely but not explicit). The tool allows up to 50 locations and an optional instant, which are covered, but the lack of output details reduces completeness for an agent needing to consume the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 50% of parameters (the 'at' field has a detailed description). The tool description summarizes location options ('city name, IANA timezone/abbreviation, or coordinates'), which partially overlaps with the schema's item description but adds clarity by grouping. It does not introduce new parameter semantics beyond what is in the schema, so the added value is moderate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the action ('Get the current local time'), the resource ('time at one or more locations'), and the scope ('up to 50 locations', 'city name, IANA timezone/abbreviation, or coordinates'). It distinguishes from siblings by covering multiple identification methods and bulk queries, unlike time_by_coordinates (only coordinates) or convert_time (conversion, not current time).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any explicit guidance on when to use this tool versus siblings like convert_time, get_dst_transitions, or search_cities. It neither states when not to use it nor mentions alternatives, leaving the agent to infer differentiation from the tool name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_dst_transitionsGet DST transitionsAReport whether a location observes daylight saving time, the next clock change, and every summer/winter-time transition (date, local time, and before/after offset) within a year. The result includes a source_url linking the matching worldclock.pro page when available.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Calendar year to list transitions for (default: the current year). | |
| location | Yes | A location identified by exactly ONE of: query, timezone, or latitude+longitude together. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the tool is safe. The description adds that the result includes transitions and a source URL, which is helpful but does not disclose potential quirks (e.g., handling of ambiguous times). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently cover purpose and output format with no unnecessary words. Front-loaded with key verb 'Report' and specific details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but the description explains return values (date, local time, before/after offset, source_url). Covers the main output adequately for a tool with two parameters and a nested object. Could specify whether historical or only future transitions, but still complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so schema already documents parameters. The description adds 'within a year' and mentions 'every summer/winter-time transition', providing slight extra context beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool reports DST observances, next clock change, and all transitions for a year, with a source URL. It clearly differentiates from sibling tools like get_current_time by focusing on DST transitions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for DST information but does not provide explicit when-to-use or when-not-to-use guidance relative to siblings like convert_time or search_cities. No alternatives are suggested.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_citiesSearch citiesAFind cities by name (multilingual, diacritic-insensitive) — useful to resolve a place to a canonical slug, IANA timezone, and coordinates before calling the time tools. Each result includes a source_url linking the city's worldclock.pro page.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 10). | |
| query | Yes | City name or partial name (≥ 2 characters). | |
| country | No | Optional ISO 3166-1 alpha-2 country filter, e.g. "JP". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive. The description adds behavioral detail: multilingual, diacritic-insensitive search, and what each result includes (slug, timezone, coordinates, source_url). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Front-loaded with verb and resource, then adds functional context. Ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description adequately explains return values (slug, timezone, coordinates, source_url) and connects to sibling tools. For a simple search tool with 3 parameters, it is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema already describes all three parameters with 100% coverage. Description adds no new per-parameter semantics beyond the schema, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds cities by name, specifying multilingual and diacritic-insensitive search. It distinguishes from sibling time tools by framing it as a prerequisite for resolving a place to slug, timezone, and coordinates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains it is useful before calling time tools, giving clear context. It does not explicitly list when not to use, but the focus on resolving place data is sufficient for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
time_by_coordinatesGet time by coordinatesBResolve the timezone for a latitude/longitude coordinate (via geo-tz) and return the local time there.
| Name | Required | Description | Default |
|---|---|---|---|
| at | No | Optional ISO 8601 instant to evaluate instead of now (read as UTC if it has no zone). | |
| latitude | Yes | Latitude in degrees [-90, 90]. | |
| longitude | Yes | Longitude in degrees [-180, 180]. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds that it uses geo-tz and returns local time, but lacks details on edge cases (e.g., ocean coordinates) or whether it returns timezone name alongside time.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, 18 words, front-loaded with main action. Every word serves a purpose; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description should clarify the return format. It only says 'return the local time,' which is vague. The essentials are present but incomplete for full agent guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. The description does not add any new information beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it resolves timezone and returns local time for coordinates. However, it does not explicitly differentiate from siblings like search_cities or get_current_time, but the coordinate-based approach is distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. The description does not mention prerequisites or situations where it is preferred over get_current_time or convert_time.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.