utc-time
Current UTC timestamp.
Input Schema
| 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 |
Current UTC timestamp.
| 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 must disclose behavioral traits. It only says 'Current UTC timestamp' with no mention of side effects, return format, or the relevance of the schema parameters. The unrelated parameters suggest the tool may do more than stated, leaving behavior completely opaque.
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 is a single short sentence, which is concise, but it lacks any structure or additional context. It is under-specified to the point of being unhelpful, and the sentence does not earn its place because it conveys almost no actionable information.
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?
For a tool with four unrelated parameters, no output schema, and no annotations, the description is grossly incomplete. It does not explain what the tool does with the parameters, what it returns, or how it relates to siblings like 'timezone'. An agent cannot correctly invoke this tool based on the description alone.
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?
The schema describes each parameter (e.g., 'HTTPS URL to normalize or cite'), but these descriptions have no connection to the tool's stated purpose of returning a UTC timestamp. The tool description adds no meaning to the parameters and does not explain how they affect the output. With 100% schema coverage but irrelevant descriptions, the description fails to resolve the mismatch.
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 'Current UTC timestamp' names a clear resource (UTC timestamp) and a verb (current), but it does not differentiate this tool from siblings like 'timezone' or 'iana-zones', and it completely ignores the four parameters (url, host, json, zone) in the schema, which are unrelated to a timestamp. The mismatch makes the purpose ambiguous and potentially misleading.
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 provides no guidance on when to use this tool versus alternatives. There is no mention of scenarios, exclusions, or references to sibling tools. An agent has no basis for deciding between this and 'timezone' or 'iana-zones'.
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.