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 provided, the description carries the full burden of behavioral disclosure. It does disclose that 'Page content is not stored', which is a useful privacy note, but it omits other behavioral traits: whether the URL is fetched, what happens on redirects, whether JSON is validated against any schema, why a timezone zone is accepted, and what the output format looks like. The description is incomplete for a tool with four seemingly unrelated parameters.
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 short and front-loaded with the primary action, which is efficient. The phrase 'Page content is not stored' is a useful privacy note packed into one clause. However, it is so terse that it sacrifices necessary explanation of the tool's broader scope, leaving the agent to guess about the extra params.
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 no annotations and no output schema, and the description only covers a fraction of the tool's apparent behavior. The input schema suggests the tool handles URL normalization, HTTP status, JSON validation, and timezone validation, but the description only mentions host, scheme, and HTTP status. With zero annotations and no output schema, the description must carry far more weight than a single sentence. This is a serious gap in contextual completeness.
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 schema documents each parameter's type and a terse description (e.g., 'HTTPS URL to normalize or cite', 'JSON text to validate; discarded after the check'). However, the tool's description does not explain how these parameters relate to each other. An agent cannot tell whether 'host' is an input or an output, whether 'json' and 'zone' are optional inputs or irrelevant, or how they interact. The description adds no meaning beyond the schema; it even introduces confusion by omitting json and zone entirely.
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 says 'Return host, scheme, and HTTP status for a URL' which names a specific action and resource, so it barely avoids a tautology. However, the tool name is 'citation' and the description does not explain how returning host/scheme/status relates to citing or normalizing a URL, and it fails to differentiate from sibling tools like normalize-url or status-check. The input schema's mention of JSON validation and timezone names is completely unaddressed in the description, making the tool's actual purpose unclear.
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. Sibling tools like normalize-url, status-check, and validate-json suggest overlapping functionality, but there is no mention of when citation is preferred. It also does not state prerequisites (e.g., HTTPS requirement), limitations, or use cases.
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 the URL/host space (citation, normalize-url, domain-shape, inspect-robots), so an agent may need to read descriptions carefully to select the right one. The time and HTTP tools are mostly distinct, but 'compatibility' is vague enough to create selection uncertainty.
All names use lowercase kebab-case, but the underlying convention is mixed: verb-first names like normalize-url and validate-json coexist with noun-first compounds like semver-parse and domain-shape, plus bare nouns like citation and timezone. The set is readable but lacks a consistent naming pattern.
For the broad set of read-only utilities exposed, 11 tools is a reasonable count and none feels redundant. However, the scope spans URLs, time, HTTP status, JSON, and semver, which feels slightly broad for a server whose name implies a narrow 'SemVer numbers only' purpose.
The tools cover several useful read-only operations, including URL inspection, time lookups, status codes, JSON validation, and semver parsing. The overall domain is diffuse, and there are notable gaps such as timezone conversion, URL redirect/validation details, and semver comparison.