check_domainUse when a domain or website is not working or not resolving (is it DNS?): one call. The first line says whether the name resolves; then the eleven-check audit of its zone, each row ok, warn, fail or skipped and why.
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Ask from the probe in this region | |
| name | Yes | The domain to audit. Also as "domain"; a URL is read as its host. |
Changes observed during successful MCP inspections.
Input schema / properties / fromAdded value: +{
+ "description": "Ask from the probe in this region",
+ "enum": [
+ "north-america",
+ "europe"
+ ],
+ "type": "string"
+}Input schema / properties / name / descriptionPrevious value: -"The domain to audit. Also accepted as \"domain\"; a URL is reduced to its host."New value: +"The domain to audit. Also as \"domain\"; a URL is read as its host."Input schema / properties / name / descriptionPrevious value: -"The domain to audit"New value: +"The domain to audit. Also accepted as \"domain\"; a URL is reduced to its host."Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds genuine value by describing the response shape: a first line on resolution, then eleven rows labeled ok/warn/fail/skipped with reasons — useful given there is no output 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?
Two tight sentences with the trigger condition front-loaded and the output contract in the second. Nothing is padded or repeated from structured fields.
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?
With no output schema, describing the return format is exactly what is needed, and it does so. Parameter and safety context come from schema and annotations, leaving only the absence of explicit sibling routing as a minor gap.
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%, so both parameters are already documented, including the "domain" alias and URL-as-host behavior. The description adds no parameter-level detail beyond the schema, so baseline 3 applies.
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 resource and what the tool produces: resolution status plus an eleven-check zone audit. An agent can tell this is a composite diagnostic rather than a raw query like dig, even though no sibling is named explicitly.
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?
"Use when a domain or website is not working or not resolving (is it DNS?)" gives a clear triggering condition. It stops short of stating when to prefer a sibling such as dig or trace instead.
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.