Perform WHOIS + DNS + SPF/DMARC lookup for a domain.
Args:
domain: Domain name to look up (e.g. "example.com").
include_dns: Include DNS records (A, MX, NS, TXT, etc.).
include_security: Include SPF/DMARC email-security check.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | ||
| include_dns | No | ||
| include_security | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It enumerates the included lookup components (WHOIS, DNS, SPF/DMARC), which adds some behavioral context, but it does not disclose response format, network implications, or error behavior. This is moderate value beyond the plain purpose.
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 compact, well-structured docstring: a single summary line followed by an args list. No redundant text, and every sentence adds necessary information. It is front-loaded with the primary action.
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 lack of output schema and annotations, the description covers the operation and parameters clearly. However, it does not explicitly state the return value structure or any limitations such as rate limits or latency. For a straightforward 3-parameter lookup tool, this is a minor but acceptable 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?
The Args section in the description thoroughly explains each parameter beyond the schema. For example, include_dns is described as 'Include DNS records (A, MX, NS, TXT, etc.)' and include_security as 'Include SPF/DMARC email-security check'. Since schema coverage is 0%, this completely compensates and significantly enriches parameter understanding.
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 opens with a clear imperative: 'Perform WHOIS + DNS + SPF/DMARC lookup for a domain.' This specifies the exact resources and operations, distinguishing it from sibling tools like extract_contacts and lookup_business.
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 does not explicitly state when to use this tool vs alternatives or mention any exclusions. Usage is implied by the tool name and description, but there is no direct guidance, so it falls in the 'implied usage' category.
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.
Each tool has a clearly distinct purpose: web contact extraction, company registration lookup, director search, domain intelligence, and financial statements. Even the two ONRC-based tools differ in query type (name/CUI vs director name), eliminating ambiguity.
Four of five tools follow the consistent 'lookup_' prefix with a clear noun (business, director, domain, financials). The fifth, 'extract_contacts', uses a verb-noun pattern but with a different verb. This is a minor deviation and still readable, but slightly breaks the uniform style.
With exactly 5 tools, the set is well-scoped for a lead-generation server. Each tool covers a distinct aspect of lead research without redundancy, making the count appropriate for the purpose.
The toolset covers the core leadgen workflow: find companies, identify directors, extract contacts, check domains, and review financials. Minor gaps exist (e.g., no social profile lookup or email verification), but the surface is sufficient for typical lead generation tasks.