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?
There are no annotations describing side effects, safety, or resource usage. The description only says 'Split a hostname into labels' but does not disclose what happens with the other inputs (url, json, timezone), whether it performs network calls, or whether it has side effects. This lack of transparency is especially problematic given the mismatched 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 extremely short and front-loaded, but it is incomplete and includes ambiguous wording ('without WHOIS or data'). It does not provide enough structure or detail to be useful, and the brevity comes at the expense of necessary clarity.
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?
Given the complex mismatch between the description and the parameters, the tool is far from complete. There is no output schema, no explanation of how the parameters interact, and no guidance on expected behavior. The description leaves too many critical gaps for an agent to use the tool correctly.
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?
The schema provides descriptions for all four parameters, but they are inconsistent with the tool's stated purpose. 'url' is described as 'HTTPS URL to normalize or cite', 'json' as 'JSON text to validate', and 'timezone' as 'IANA timezone name'—none of these relate to splitting a hostname into labels. Only 'host' seems relevant. The description adds no clarification.
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 the core action ('Split a hostname into labels') but the phrase 'without WHOIS or data' is unclear, and the input schema includes unrelated parameters such as url, json, and timezone. This muddles the tool's actual purpose and does not clearly distinguish it from sibling tools like normalize-url or validate-json.
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 usage guidance is provided. The description does not indicate when to use this tool over alternatives, nor does it explain when splitting hostnames is appropriate. The presence of irrelevant parameters adds confusion rather than clarifying usage.
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 are clearly distinct, but 'citation' and 'compatibility' have vague descriptions that could overlap with HTTP status handling, and 'status-catalog' adds further potential confusion. URL-related tools are distinguishable but require careful reading.
All names consistently use lowercase hyphenated style, but they mix noun phrases like 'timezone' and 'status-catalog' with verb-object forms like 'normalize-url' and 'validate-json'. This is mostly predictable but not perfectly uniform.
With 11 tools, the set is reasonably sized and not overwhelming. Each tool appears to serve a single utility purpose, fitting the apparent web-utility domain.
The collection covers common web development utilities: URL handling, HTTP status, time, timezone, JSON validation, robots.txt inspection, and language tags. There are no major dead ends, though the server name 'Language zh' does not strongly align with the broader tool set.