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 provided, so the description carries the full burden. It discloses only that the tool does not return WHOIS/ownership data; it says nothing about network calls, data retention, error behavior, or what happens with the unrelated optional params. This is minimal behavioral disclosure.
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?
Single sentence, front-loaded with the action and no filler. Every clause earns its place, and the negative scope is useful context.
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 zero required parameters, no output schema, and no annotations, the description should clarify invocation and expected return. It only says split a hostname; it doesn't state what labels look like or which param to pass. The tool is too underspecified for an agent to call confidently.
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 descriptions cover 100% of parameters, so the baseline is 3, but the description adds no link between 'hostname' and the four optional inputs (url, host, json, zone). It never says which parameter to provide, whether multiple parameters are allowed, or what happens when none are provided, so the high schema coverage does not resolve the ambiguity.
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?
States a specific action ('Split a hostname into labels') and adds a scope exclusion ('without WHOIS or ownership data'). It is clear about the core operation, though it does not name an alternative sibling and the schema's extra params create some ambiguity.
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 about when to choose domain-shape over siblings such as normalize-url, validate-json, or iana-zones. The only hint is the negative scope ('without WHOIS or ownership data'), which is not enough to route an agent correctly.
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 have distinct outputs, but the URL-related tools (citation, normalize-url, domain-shape) and time-related tools (utc-time, timezone, iana-zones) form overlapping clusters that an agent could misselect. Descriptions clarify the differences, but the boundaries are not immediately obvious.
All names use lowercase hyphenation, but the set mixes imperative verb_noun names (inspect-robots, normalize-url, validate-json) with noun/adjective names (citation, compatibility, timezone, base64-ok). This is readable but not a consistent naming pattern.
Eleven tools is a reasonable size for a general-purpose utility server and none seem redundant enough to cut. A few could be consolidated, such as timezone and utc-time, but the count is not excessive.
The server covers several utility categories, including URL analysis, time, JSON validation, HTTP status, and base64, but has noticeable gaps such as no base64 decode, no timezone conversion, and no URL encoding/decoding. These missing operations limit what an agent can accomplish without another server.