Free. Check that a domain or URL is well-formed and get the normalized hostname, before calling a paid check. Offline: no network request, no payment. Rejects IP addresses, single-label names and URLs with credentials.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Hostname or URL to normalize, e.g. example.com or https://www.example.com/path |
Changes observed during successful MCP inspections.
Input schema / properties / domain / descriptionAdded value: +"Hostname or URL to normalize, e.g. example.com or https://www.example.com/path"Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, but the description adds behavior that annotations do not convey: it is free, performs no network request, and rejects malformed inputs outright. That is meaningful extra context for an agent deciding whether a call is safe and what failure means.
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?
Three short sentences, front-loaded with the most decision-relevant fact ('Free'), then the action, then the boundaries. No filler and nothing buried.
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?
For a one-parameter offline validator with no output schema, the description covers cost, network behavior, return value (normalized hostname) and rejection cases. Nothing an agent needs to call it correctly is missing.
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 coverage is 100% and the schema already shows the example formats, so the baseline is 3. The description adds semantics beyond the schema by stating the value is normalized to a hostname and by enumerating what input forms are rejected, which constrains what the single parameter will accept.
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 verb and resource ('check that a domain or URL is well-formed') plus the payoff ('get the normalized hostname'), and positions it explicitly as the free pre-step to a paid check, which separates it from the paid check_* siblings. An agent can tell exactly what it does and does not do.
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?
Clearly signals the usage window: run this 'before calling a paid check'. It also lists rejection cases (IP addresses, single-label names, credentialed URLs), which is useful boundary information. It stops short of naming specific sibling tools as the alternatives, so it is clear context rather than fully explicit routing.
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.