Current time in a named IANA timezone.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | HTTPS URL to normalize or cite | |
| host | No | Public hostname | |
| json | No | JSON text to validate; discarded after the check | |
| zone | No | IANA timezone name |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states only that it returns the current time but does not disclose the output format, how invalid or unknown zone names are handled, or whether the result includes timezone offsets. This is a minimal gap for a read-only lookup but still incomplete.
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?
A single sentence with no filler; the core purpose is front-loaded and efficient. It loses a point only because it is so terse it omits any clarifying detail about the mismatched parameters.
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 four parameters (none required), no output schema, and no annotations, the description is under-specified. It does not clarify which parameter is the operative one, what the return value looks like, or how it differs from sibling time tools. An agent would struggle to use this tool correctly given the irrelevant url/host/json parameters.
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 100%, so the schema documents all four parameters. However, three of the four parameters (url, host, json) are clearly unrelated to a timezone lookup and appear to be artifacts of a shared schema; the description offers no clarification that only 'zone' is relevant. This is confusing and adds negative value 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 states a clear verb-resource pair: retrieving the current time for a named IANA timezone. It distinguishes itself from sibling utc-time (fixed UTC) and iana-zones (zone listing), though it doesn't explicitly name those alternatives. The purpose is unambiguous enough for an agent to know what the tool does.
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 versus siblings such as utc-time or tz-europe-amsterdam. The description implies usage for any named zone but offers no exclusions or conditions, leaving the agent to infer which time tool fits a given task.
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 `timezone` and `tz-europe-amsterdam` overlap heavily, and `domain-shape`/`normalize-url` both inspect hostnames, creating potential ambiguity.
All names use lowercase kebab-case, but they mix noun labels (`citation`, `status-catalog`, `timezone`) with verb-action names (`inspect-robots`, `normalize-url`, `validate-json`), so no consistent pattern emerges.
Eleven tools is within a typical range, but the set combines URL inspection, timezone, and JSON validation unrelated to the apparent clock/time focus, making the count feel padded.
For a clock/time server, it provides current UTC, named timezone, and Europe/Amsterdam time, but lacks conversion or formatting operations; the unrelated URL/JSON tools do not fill that gap.