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?
With no annotations, the description carries the full behavioral burden. It does indicate a read-only current-time lookup, but it does not disclose output format, invalid-zone behavior, or whether the unrelated url/host/json parameters are ignored or meaningful.
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 front-loaded sentence with no filler. Every word contributes to the meaning, and it is appropriately sized for the core purpose.
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 4-parameter, 0-required tool with no output schema and no annotations, the description is under-specified. It does not indicate which parameter drives the lookup, how invalid zone names are handled, or why unrelated optional inputs are present.
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. The description adds no parameter meaning beyond the schema's existing 'IANA timezone name' note, and it doesn't explain why url, host, and json appear in the schema of a timezone tool.
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 is specific: 'Current time' + 'named IANA timezone' clearly identifies the operation and resource. It also distinguishes this tool from the siblings utc-time (no zone) and iana-zones (a list of zone names).
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 implies when to use the tool — when a zone-specific current time is needed — but it never states an explicit alternative, exclusion, or comparison with utc-time or iana-zones. The agent must infer the boundary from the sibling names.
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.
Each tool has a clear, distinct purpose: URL parsing, HTTP status codes, timezone handling, JSON validation, and robots.txt fetching. Even overlapping areas like URL tools focus on different aspects (origin/path vs. host/scheme vs. domain labels).
All tool names follow a consistent lowercase-with-hyphens convention (e.g., normalize-url, validate-json). No camelCase, underscores, or mixed styles, making the naming pattern predictable and uniform.
With 11 tools, the set sits within the typical 3-15 range. The domain is a mix of unrelated utilities (URL, time, JSON, HTTP), which feels slightly unfocused but not excessive.
The tools cover common operations for their respective areas: URL parsing, time/UTC, JSON validation, and HTTP status. Minor gaps exist (e.g., no URL encoding/decoding or generic HTTP request tool), but the current set is reasonably comprehensive for its stated purposes.