Common IANA timezone names for clock calls.
| 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 adds some useful scope ('Common' and 'for clock calls'), but it does not explain whether the tool returns a list, accepts parameters, filters by zone, or what the output format is. This is especially important given the unrelated-looking parameters 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 concise, front-loaded sentence with no wasted words. It is efficient, though it stops short of being a complete statement of behavior or usage.
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 and no annotations, the tool description is the only guide for invocation. It fails to explain what the agent should provide, how the four parameters are used, what response to expect, or how this differs from the timezone-related sibling tools. The description is too thin for an agent to confidently call the tool correctly.
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 baseline is 3 and the schema already documents each parameter. The description adds no additional meaning about how 'url', 'host', 'json', or 'zone' relate to the tool's behavior, but because the structured schema is complete, the parameter semantics are minimally adequate.
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 resource ('Common IANA timezone names') and the intended context ('for clock calls'), which is more specific than the bare name 'iana-zones'. However, it lacks an explicit verb such as 'list' or 'return', and it does not clearly distinguish this tool from sibling tools like 'timezone' or 'utc-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 phrase 'for clock calls' implies when the tool is relevant, but there is no explicit guidance about when to use this tool versus siblings like 'timezone', 'utc-time', or 'rfc3339-now'. No exclusions or alternatives are named.
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 occupy overlapping territory: rfc3339-now and utc-time both return current UTC time, while citation and normalize-url both surface host/scheme metadata for URLs. The compatibility tool is also vague and could be confused with citation's request classification role.
All names use lowercase hyphenation, but the pattern is inconsistent: citation, timezone, and status-catalog are noun-style, while normalize-url, inspect-robots, and validate-json are verb-style. There is no consistent verb_noun convention.
Eleven tools is a reasonable count for a toolkit that spans time, URL inspection, robots, and JSON validation. However, the near-duplicate time and URL utilities could likely be consolidated without losing capability.
The toolset covers its apparent privacy-focused metadata utilities well: current time, timezone names, URL shape, HTTP status, robots.txt, and JSON validation. Minor gaps like timezone conversion or custom timestamp formatting exist, but agents can work around them.