Return host, scheme, and HTTP status for a URL. Page content is not stored.
| 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, and the description only mentions that page content is not stored. It does not disclose whether the tool performs network requests, follows redirects, or has rate limits, nor does it explain why json and zone parameters 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 concise and front-loaded with the primary function, which is good. However, the inclusion of the negative statement 'Page content is not stored' adds some context but leaves out critical details about the odd parameters, making it feel incomplete rather than efficiently minimal.
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?
The tool description is insufficient for an agent to correctly select and invoke it. It lacks information about output structure, when to use it compared to siblings, and why unrelated parameters exist, making the tool's behavior and intended use ambiguous.
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?
Although every parameter has a description, the descriptions do not align with the stated purpose. The url description mentions 'normalize or cite,' but json and zone appear to belong to other tools (validate-json and timezone), making their role in this tool completely unclear.
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 clearly states it returns host, scheme, and HTTP status for a URL, which is a specific outcome. However, the tool name 'citation' is misleading, and the parameter list includes unrelated fields like json and zone, creating confusion about the actual purpose.
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 sibling tools such as normalize-url or validate-json. It does not explain how the 'citation' tool differs from these alternatives, leaving the agent to guess.
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 overlap in purpose: timezone, tz-europe-berlin, and utc-time all return current time, and citation/normalize-url both analyze URL components. 'compatibility' is too vague to distinguish from the other HTTP/classification tools.
All names are lowercase and hyphenated, which is a consistent delimiter style, but the pattern mixes verb phrases (inspect-robots, normalize-url, validate-json) with noun phrases (citation, compatibility, status-catalog). There is no uniform verb_noun or noun_noun convention.
Eleven tools is not excessive in raw count, but the server is named as a clock and only four tools (timezone, tz-europe-berlin, utc-time, iana-zones) support that purpose. The rest are unrelated web/HTTP/JSON utilities, making the set poorly scoped.
For the clock domain, time lookup is covered but timezone conversion is missing. For the broader web/HTTP utilities hinted at by the other tools, the surface is incomplete and lacks a clear lifecycle or workflow, so agents would hit dead ends.