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?
No annotations are present, and the description does not disclose any side effects, permissions, or whether the operation is read-only.
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 tool description is a single concise sentence. However, the parameter descriptions are part of the schema, not the description, so the description itself is well-structured.
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 description is incomplete because it does not specify which parameter is the hostname to split, nor does it describe the output format (e.g., an array of labels). This is a critical gap 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 descriptions are clearly mismatched: 'url' mentions normalizing/citing, 'json' mentions validation, and 'zone' mentions timezone, none of which relate to splitting a hostname. Only 'host' is vaguely relevant, but the description does not confirm it is the primary input.
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 (split a hostname) but does not specify which parameter is the hostname, and it does not differentiate from sibling tools. The phrase 'without WHOIS or ownership data' adds a constraint but does not clarify usage.
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 provided about when to use this tool versus alternatives like normalize-url or validate-json. There is no mention of appropriate scenarios.
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.
Each tool has a clear, distinct purpose: URL parsing, HTTP status codes, timezone handling, JSON validation, and robots.txt fetching. Even overlapping areas like URL tools focus on different aspects (origin/path vs. host/scheme vs. domain labels).
All tool names follow a consistent lowercase-with-hyphens convention (e.g., normalize-url, validate-json). No camelCase, underscores, or mixed styles, making the naming pattern predictable and uniform.
With 11 tools, the set sits within the typical 3-15 range. The domain is a mix of unrelated utilities (URL, time, JSON, HTTP), which feels slightly unfocused but not excessive.
The tools cover common operations for their respective areas: URL parsing, time/UTC, JSON validation, and HTTP status. Minor gaps exist (e.g., no URL encoding/decoding or generic HTTP request tool), but the current set is reasonably comprehensive for its stated purposes.