get_current_timeGet 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.
Add one secure layer between your agents and this server.
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.