check_domainThe five-check DNS audit for a domain: parent and child nameservers agree, no open recursion, DNSSEC chain, TTL sanity, mail posture. A 0 to 100 score with a grade and each check explained.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The domain to audit |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already convey read-only, idempotent, non-destructive behavior, so the description does not need to repeat those. It adds value beyond the annotations by specifying the output shape (0-100 score, grade, per-check explanation) and the behavioral scope of the audit, giving the agent a clear picture of what will happen when invoked.
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 two sentences long and immediately starts with the tool's purpose and the full list of checks. Every sentence adds useful information, and the output format is clearly front-loaded. There is no fluff, repetition, or cryptic wording.
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 covers the main inputs and outputs: it enumerates the checks and explicitly states scoring and grading. Given there is no output schema, mentioning score/grade/explanation is essential and present. It could have gone a little further on error conditions or input validation, but for a single-parameter read-only tool with this richness of description it is nearly complete.
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% and the single 'name' parameter is clearly described as 'The domain to audit' in the schema. The description's mention of DNS checks adds some context to what the parameter will be used for, but it does not add meaning materially beyond the schema, so the baseline of 3 is appropriate.
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 verb ('audit') with the resource ('domain') and enumerates exactly five checks, giving a precise scope. It differentiates the tool from sibling tools like dig or trace by explaining it produces an aggregate score and grade rather than a raw DNS query.
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?
The description implies that the tool is a comprehensive DNS health audit by listing the five check categories, so an agent can infer when it would be used over a single-purpose tool. However, it does not explicitly state when-not-to-use it, name alternative tools, or mention scenarios where a simpler tool should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.