Check your published DNS TXT record. Proves domain control only, not agent identity or safety. Checks limited to once per minute. Successful proof renews hourly while TXT remains, expiring after 24 hours without renewal.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | Yes | ||
| agent_id | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true. The description adds valuable behavioral details beyond annotations: the once-per-minute check limit, hourly renewal on success, and 24-hour expiry. This gives the agent a realistic model of side effects and limitations without contradicting the annotations.
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 carry essential information: the action, the limitation, and the lifecycle behavior. There is no filler or repetition, and the most important scoping statement is front-loaded.
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 verification lifecycle well and an output schema exists, so return-value documentation is not needed. However, it omits the prerequisite relationship with agent_domain_challenge, and it never explains which domain the TXT record should be on or how agent_id and api_key map to that domain. This leaves gaps for an agent deciding whether it has everything needed.
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?
There are two required parameters, agent_id and api_key, with 0% schema description coverage. The description says nothing about what either parameter means, which domain is verified, or how the API key is used. The schema only provides titles, so the agent must guess crucial invocation details.
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 uses a specific verb and resource ('Check your published DNS TXT record') and immediately clarifies the scope ('Proves domain control only, not agent identity or safety'), distinguishing it from identity or safety verification tools. The purpose is unmistakable.
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 usage: check a DNS TXT record after publishing it, and use it when domain control proof is sufficient. It does not explicitly state when to prefer this tool over siblings like agent_domain_challenge, nor does it give an explicit when-not-to-use condition, though the 'not agent identity or safety' caveat provides useful context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.