domain-intel

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description carries the transparency burden. It discloses that the tool uses Cloudflare DoH, indicating an external network dependence. It also implies it resolves multiple record types in one call. It does not describe output format or limitations, but for a read-only lookup, the behavior is transparent enough.

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 a single, well-structured sentence that front-loads the core function, lists specific record types, and includes the implementation detail (Cloudflare DoH). Every word earns its place, with no redundancy.

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 the tool's simplicity (one parameter, no output schema), the description adequately covers the essential context: what it does, for whom, and how. It does not detail return values, but the absence of an output schema is mitigated by the straightforward purpose. Slightly less complete than a tool with richer annotations.

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?

The schema already provides 100% documentation for the single 'domain' parameter with an example. The description reinforces that this domain is used for DNS resolution but does not add detail beyond the schema. As schema coverage is high, the baseline of 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?

The description clearly states the tool's function with a specific verb ('Resolve') and resource ('DNS records'), enumerating the exact record types (A, AAAA, MX, TXT, NS, CNAME, SOA). It distinguishes itself from sibling tools like full_report or phishing_check, which serve different purposes.

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 establishes clear context: use this tool when needing DNS records for a domain. While it does not explicitly name alternative tools or exclusions, the context is unambiguous given sibling tools are unrelated. A slight deduction for not stating when to avoid using it, but the guidance is clear for an agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 the report's contents (DNS, headers, phishing, etc.), which gives some insight into behavior (aggregates multiple checks). However, it omits any details about side effects, performance implications, or the response format, which are relevant for a report tool.

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 a single, well-structured sentence that front-loads the purpose ('Full domain intelligence report') and then enumerates the included components. Every word contributes value, and it is appropriately concise for the complexity.

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 scope of the report well, listing all major data categories. However, there is no output schema and no annotations, so the agent must infer the output structure from the component list. It does not mention response format, potential delays, or error handling, which would be useful for a multi-source report.

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 0% because the description does not explicitly describe the 'domain' parameter. While the tool name and description imply the domain is the input, no additional meaning is provided beyond the schema's type and required flag. The description fails to compensate for low schema coverage.

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 clearly identifies what the tool does: produces a full domain intelligence report, explicitly listing DNS, HTTP headers, phishing signals, registrar hint, and email security (SPF/DMARC). This specific resource and scope distinguish it from the sibling tools (dns_lookup, phishing_check, security_headers), which cover individual aspects.

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 use case is implied rather than directly stated. The word 'Full' suggests use when a comprehensive view is needed, while the sibling names imply alternatives for specific checks. However, the description does not explicitly say 'use this for an all-in-one report' or contrast it with the individual tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses that the analysis is heuristic (not definitive) and returns a risk level with a signal list, but does not elaborate on limitations, edge cases, or how signals are generated. Still, it adds useful context beyond a bare statement.

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 a single, front-loaded sentence that conveys the tool's core function and output without waste. Every word earns its place.

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 simple one-parameter tool with no output schema, the description sufficiently explains what the tool returns (risk level and signal list) and its heuristic nature. It lacks deeper caveats or comparisons to siblings, but given the low complexity, 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 0%, so the description must compensate. Although it does not explicitly mention the 'domain' parameter, the tool's purpose inherently implies the domain is the subject of analysis. This partial compensation is sufficient given the parameter is self-evident.

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 clearly states that this tool performs heuristic phishing/suspicious-domain signal analysis and specifies its output (risk level and signal list). It distinguishes itself from siblings like dns_lookup and security_headers by focusing on phishing risk assessment.

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 for phishing/suspicious-domain evaluation, but provides no explicit guidance on when to use this tool versus alternatives like full_report or security_headers. There are no exclusions or alternative recommendations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It mentions returning a 0–100 score but omits that the tool likely performs a live HTTP request to the target domain, potential side effects, or scoring criteria. This is a significant transparency gap.

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 a single, front-loaded sentence with no wasted words. It concisely conveys the core function and output, making it appropriately sized for a simple single-purpose tool.

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, the description partially explains the return value (0–100 score) but doesn't clarify what the score represents or whether individual headers are also returned. It's adequate for a simple tool but leaves some ambiguity about the exact response structure.

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 0% and the description does not elaborate on the 'domain' parameter, such as expected format (e.g., with or without protocol), input constraints, or edge cases. The parameter name is self-explanatory, but the description adds no additional semantics beyond the schema.

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?

Clearly states the action (check) and resource (HTTP security headers) with specific examples like HSTS, CSP, and X-Frame-Options. This distinguishes it from sibling tools such as dns_lookup and phishing_check, which focus on different security aspects.

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 is provided on when to use this tool versus alternatives like full_report or phishing_check. The description implies usage for header checks but doesn't explicitly state use cases, exclusions, or how it complements other tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.