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?
With no annotations, the description carries the full burden of behavioral disclosure. It usefully adds 'Page content is not stored,' which is a meaningful privacy-relevant trait. However, it does not mention what happens on network failures, redirects, unreachable URLs, or side effects of the json/zone parameters. The behavioral picture is thin.
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?
Two sentences, no filler, and the primary result is front-loaded. The privacy note earns its place as a distinct behavioral trait. This is appropriately concise for what information is provided.
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 has 4 parameters, no output schema, and no annotations, so the description must do substantial work. It explains only the URL-related output and ignores the json, zone, and host parameters entirely, as well as the meaning of 'citation.' For an agent selecting this tool, the description is insufficiently complete.
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 coverage is 100%, so the baseline is 3. The description adds little beyond the schema—it implies url is the main input but does not clarify how host, json, and zone relate to the documented behavior of returning host, scheme, and HTTP status. It neither contradicts nor meaningfully enhances the schema.
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 a specific verb and resource: 'Return host, scheme, and HTTP status for a URL.' However, this does not align with the tool name 'citation' and covers only the url-related behavior, leaving the json and zone parameters unexplained. The purpose is partially clear but incomplete and not differentiated from sibling tools like normalize or validate.
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 such as normalize or validate. There is no mention of prerequisites, limitations, or contextual conditions for choosing citation. The usage context is entirely absent.
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.
Most tools have distinct outputs, but there are overlapping clusters: citation and normalize-url both return host information, timezone/utc-time/iana-zones all revolve around time, and domain-shape/punycode-ok both target hostnames. An agent would need to read descriptions carefully to avoid picking the wrong one.
Naming style is inconsistent: some names are verbs (normalize-url, validate-json, inspect-robots), some are nouns (citation, compatibility, timezone), and some are quirky compounds (punycode-ok, iana-zones). The consistent lowercase/hyphen formatting is the only pattern.
Eleven tools is not an unreasonable count by itself, but the server is named for punycode host checking while many tools are unrelated URL, time, and JSON utilities. The set feels padded rather than deliberately scoped.
The tool surface has no coherent domain to be complete against: a punycode host checker would need at least IDN conversion or comparison, while the URL/time/JSON utilities appear as unrelated extras. Significant coverage gaps would likely force agents to combine or externalize work.