Split a hostname into labels without WHOIS or ownership data.
| 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, and it does disclose a meaningful limitation: it deliberately omits WHOIS/ownership data. However, it doesn't explain how the four parameters relate to the operation, what the output looks like, or how errors are handled, so transparency is only partially achieved.
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 sentence with zero filler, and it front-loads the verb and the resource. Every word contributes either to what the tool does or to an important boundary.
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?
Although the parameter schema is fully documented, the description doesn't tie the parameters to the stated operation: url, json, and zone seem unrelated to 'splitting a hostname'. There is no output schema and no annotation, so an agent would be left guessing about return format and how to choose between url and host.
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 all four parameters. The description itself adds no parameter-level detail, but it also doesn't need to compensate for a schema gap.
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 action and object: 'Split a hostname into labels', which is enough for an agent to understand the core function. The negative clause 'without WHOIS or ownership data' adds useful scoping. However, it doesn't differentiate from actual siblings—the sibling list only contains 'domain-shape' itself—so it falls short of a 5.
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?
No guidance is given on when to use this tool versus alternatives, and there are no named prerequisites or exclusions. The 'without WHOIS or ownership data' phrase hints at when not to use it, but it never points to a concrete alternative or context.
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.