Domain & Company Intel MCP

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 transparently identifies the underlying mechanism (Cloudflare DNS-over-HTTPS) and the exact data returned. While it doesn't discuss rate limits, errors, or caching, a DNS lookup is inherently read-only and the disclosure is sufficient for safe invocation.

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: the first states the action and method, the second delivers use cases. Every sentence adds information and the description is front-loaded with the core purpose. No filler or repetition of schema details.

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 read-only DNS lookup with only two well-documented parameters and no output schema, the description covers the essential trigger conditions and expected returns. It could be more complete by noting the output format or pointing to sibling tools for WHOIS/domain intelligence, but nothing critical is missing for agent invocation.

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 documents both parameters, but the description adds value by listing the specific record types that constitute the 'all common types' default for the optional 'types' parameter. This clarifies what the tool will return when the parameter is omitted, going beyond the schema's generic wording.

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: 'Look up DNS records for a domain via Cloudflare DNS-over-HTTPS.' It clearly enumerates the record types returned (A, AAAA, MX, NS, TXT, CNAME, SOA) and states concrete use cases. It does not explicitly distinguish itself from the sibling tools (domain_intel, domain_report, etc.), so it stops short of a 5.

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 phrase 'Use to see where a domain is hosted, who runs its mail and DNS, and what verification/policy TXT records it publishes' gives clear, actionable context for when to invoke this tool. It does not name alternative tools or state when not to use it, so it lacks explicit exclusions/alternatives.

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 provided, the description must carry the full burden of behavioral disclosure. It does state the data source (RDAP), lists the output fields, and notes the computed 'domain age in years,' making the read-only nature apparent. However, it does not mention potential data incompleteness, rate limits, or network dependency, which are relevant caveats for a live registration lookup.

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 composed of three targeted sentences: purpose, return values, and use cases. Each sentence delivers distinct value with no filler or redundancy, and the core purpose is front-loaded in the first sentence.

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 one-parameter tool with no output schema and no annotations, the description covers the purpose, input expectations, return contents, and usage scenarios. It does not detail output formatting or error behavior, but these are less critical for a read-only lookup with an enumerated output list. The slight gap around data-availability caveats keeps it from a perfect score.

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 input schema already documents the single 'domain' parameter with an example and the constraint '(no scheme)', achieving 100% schema description coverage. The description does not add further parameter-specific semantics beyond what is in the schema, so the baseline score 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 identifies the tool as providing 'Registration intelligence for a domain via RDAP' and enumerates the specific return data: registrar, dates, domain age, EPP codes, nameservers, DNSSEC state, and abuse contact. This specific verb-resource pairing distinguishes it from sibling tools like dns_lookup, subdomains, or tech_stack.

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 provides explicit use cases: 'vet a company, assess a lead, or judge how established a domain is.' These give an agent clear guidance on when to call the tool. It does not explicitly exclude or compare against sibling tools, but the use-case framing is strong enough to make the intended context clear.

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 behavioral burden. It discloses the tool aggregates multiple data sources into a single report, which is the key behavioral trait. It does not detail response format or potential failures, but the read-only reporting nature is clear.

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 sentences, each earns its place: the first defines what the tool does and what it includes; the second gives practical use cases. No filler or 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?

For a single-parameter tool with no output schema, the description adequately covers the input and the nature of the output. It could mention return structure or error conditions, but the phrase 'single report' plus the listed data categories gives an agent enough to select and invoke it correctly.

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 is only one parameter, domain, and the schema already describes it with an example. The description adds no additional parameter-level detail beyond the schema, but because schema coverage is 100%, 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 clearly states the tool produces a combined domain dossier covering RDAP registration, DNS, email deliverability, and tech stack. It distinguishes itself from the sibling single-purpose tools by emphasizing 'one-call' aggregation versus separate calls.

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 explicitly names use cases: fast lead qualification, company research, and recon. It implies when to use this tool over individual lookups by noting it avoids four separate calls, though it does not explicitly state when not to use it.

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 provided, the description carries the full burden of behavioral disclosure. It clearly states what the tool returns (MX, SPF/DMARC policy, provider type, verdict) and implies a read-only assessment, which is sufficient for basic transparency. It does not mention auth needs, rate limits, or live DNS lookup caveats, but these are minor gaps for a stateless assessment 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 exactly two sentences. The first sentence states purpose, and the second lists outputs and use cases. There is no filler, redundancy, or unnecessary detail—every clause 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 single-parameter tool with no output schema and no annotations, the description is self-sufficient: it explains what the tool does, the exact outputs an agent can expect, and when to use it. An agent has enough information to invoke it correctly and interpret the result.

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 input schema already provides 100% description coverage for the single parameter, defining domain_or_email as 'A domain (stripe.com) or an email address (a@stripe.com)'. The description merely restates the same concept ('domain of an email address') without adding new parameter-specific detail, so 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 states a specific action ('Assess whether a domain... can receive mail') and a clear resource ('a domain or the domain of an email address'). It enumerates concrete outputs (MX presence, SPF, DMARC, free/disposable provider, overall verdict), which clearly distinguishes it from sibling tools like dns_lookup or domain_intel by focusing on email deliverability and sender authentication.

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 explicitly gives use cases: 'Use to qualify leads and flag throwaway signups.' This is clear context for when to apply the tool. However, it does not name sibling alternatives or explain when not to use it (e.g., when raw DNS records are needed instead), so it lacks explicit when-not/exclusion guidance.

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 full responsibility. It discloses best-effort behavior, potential slowness of crt.sh, and a fallback note if unavailable. It could add more details about return structure, but the key operational caveats are covered.

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 concise sentences: purpose, use case, and caveat. Every sentence adds value and the main action is front-loaded with no filler.

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 single-parameter, read-only tool without an output schema, the description covers purpose, source, use case, and failure mode. It does not explicitly state the return format, but 'Discover subdomains' strongly implies a list and the operational note covers error behavior.

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 only parameter 'domain' has a complete schema description ('Registrable domain, e.g. stripe.com'), and the tool description adds no additional semantic meaning beyond that. With 100% schema coverage, baseline 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?

States a specific action ('Discover subdomains') and a distinct resource ('public Certificate Transparency logs (crt.sh)'). This is precise enough to distinguish it from sibling tools like dns_lookup or tech_stack, even without naming them 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?

Provides a clear use case ('mapping a company's public surface') with examples of subdomain patterns. It does not list exclusions or name alternatives, so it lacks explicit 'when not to use' guidance.

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 provided, the description carries the burden of disclosing behavior. It transparently states that the tool fetches the homepage, follows redirects, and extracts specific information. While it does not mention potential blocks, rate limits, or whether JavaScript rendering is used, it provides a solid behavioral picture for a read-only scanning 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 compact and front-loaded: the first sentence states the core action and method, and the second sentence enumerates outputs and use cases. Every sentence contributes value without 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 simple input (one domain parameter), the absence of annotations, and the absence of an output schema, the description sufficiently covers what is needed to invoke the tool correctly and interpret its results. It states the input method, the outputs, and the intended use cases.

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%, so the single domain parameter is already well documented in the schema with an example. The tool description adds no new parameter-level meaning beyond the overall purpose, matching the baseline for high 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 defines the tool as fingerprinting the technology behind a website via its homepage, listing specific detectable categories (web server, CMS/framework, CDN, analytics) and concrete return values (page title, final URL, response headers). This distinguishes it from sibling tools like dns_lookup and subdomains, which focus on different aspects of domain investigation.

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 provides clear use cases: 'competitive research and lead enrichment.' It does not explicitly mention when not to use the tool or compare it to alternatives, so it falls short of a 5, but the usage context is well established.

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