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 provided, the description must fully disclose behavior, but it only states that the tool does not include WHOIS/ownership data. It does not mention any side effects, read-only guarantees, or the fact that json input is 'validated and discarded' per the schema, leaving mutation and data-retention behavior unspecified.
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 concise sentence and is easy to parse. However, it is under-specified for a tool with four unrelated parameters; brevity here sacrifices completeness rather than being efficient.
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?
No output schema, no annotations, and four optional parameters. The description leaves unclear what the result of splitting looks like, how url vs host are chosen, why json and zone exist, and what happens after the operation. For an agent to call this correctly, significant inference is required.
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. The description adds no parameter-level meaning beyond 'hostname', and it fails to connect url, json, or zone to the stated operation, but the schema already documents each parameter's format, so the description does not need to compensate.
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 operation ('split a hostname into labels') and an explicit exclusion ('without WHOIS or ownership data'). However, the input schema includes url, json, and zone parameters whose descriptions point to URL normalization/citation, JSON validation, and timezone handling, none of which are accounted for by the description, leaving the tool's actual scope ambiguous.
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 explicit when-to-use or alternative tool guidance is provided. The only implied signal is the exclusion of WHOIS/ownership data, which suggests a use case but does not tell an agent when to prefer this tool over siblings or what inputs are appropriate.
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 target clearly distinct resources: URL components, IP version, robots.txt, time zones, JSON, and HTTP status codes. However, citation and normalize-url both operate on URLs, and compatibility is vague enough that an agent might pause to determine which tool applies.
All names use lowercase hyphenation, which gives a consistent visual style. However, the set mixes verb-object names like normalize-url and validate-json with noun compounds like status-catalog and iana-zones, so there is no consistent semantic naming pattern.
Eleven tools is a reasonable number for a utility server, and each tool performs a distinct small task. The scope is broad—covering URLs, HTTP, time, and JSON—so it feels less tightly focused than a single-domain server.
The set covers simple URL inspection, HTTP status lookup, current time retrieval, and JSON validation. Natural gaps remain, such as timezone conversion, HTTP header inspection, or deeper network diagnostics, so the surface is useful but not comprehensive.