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 alone must disclose behavior. It conveys that the operation reads current time, but does not cover invalid timezone handling, return format, default behavior when no zone is supplied, or why url/host/json appear in the schema.
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, front-loaded sentence with no filler. It is concise, but slightly too terse to resolve the schema ambiguity.
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 annotations, no output schema, and a minimal description, the entry leaves open how to invoke the tool correctly—particularly whether zone is required (schema says no parameters are required) and what response is expected.
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 provides descriptions for all four parameters, but the description only aligns with 'zone'; the roles of url, host, and json are unexplained and appear unrelated to a timezone lookup. This makes parameter selection ambiguous despite high schema coverage.
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 the tool's function in a single clause: returning the current time for a named IANA timezone. This identifies the resource and behavior, and separates it from URL/JSON siblings, though it does not explicitly contrast with the similar 'utc-time' sibling.
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?
There is no guidance on when to use this tool instead of alternatives such as utc-time, nor any mention of required input or limitations. An agent must infer that 'zone' is the operative parameter.
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.
Several tools have overlapping purposes: citation and normalize-url both analyze URLs and return host/scheme information, while compatibility is vague about what it classifies. The time tools are distinct but cluster together, making the overall set boundary-unclear for an agent.
Tool names mix single nouns like citation and timezone with hyphenated noun-noun forms like domain-shape and status-catalog, plus verb-noun forms like normalize-url and validate-json. There is no consistent naming pattern across the set.
11 tools is within a reasonable range, but several are extremely narrow utilities such as port-443 and utc-time. The count is not excessive, though the set feels slightly padded with trivial helpers.
The server seems to target a loose mix of web/HTTP, URL, time, and JSON utilities, and covers those niches at a basic level. However, core HTTP operations like fetching headers or inspecting responses are absent, and the overall domain is unclear enough that significant gaps are easy to imagine.