Domain & Company Intel MCP

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

Annotations already cover readOnly, idempotent, openWorld and destructive=false, so the safety profile is handled. The description adds genuinely useful behavioral context beyond them: the upstream provider (Cloudflare DoH, a third-party network dependency) and the enumerated record set returned. It omits failure behavior for nonexistent domains or empty record sets, which would be the remaining 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?

Two sentences, zero filler, front-loaded with what the tool does before the usage hint. Every clause carries information (mechanism, record types, use cases).

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?

An output schema exists, so return structure need not be explained, and annotations cover the safety semantics. Purpose, scope and usage are all present; only edge-case behavior (nonexistent domain, empty results, rate limiting on the upstream resolver) is unaddressed.

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 both parameters are already documented in the schema. The description reinforces the record-type dimension by enumerating A, AAAA, MX, NS, TXT, CNAME and SOA, but adds no format or syntax detail beyond that. 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 precise verb+resource ('Look up DNS records for a domain') plus the mechanism (Cloudflare DNS-over-HTTPS) and the exact record types returned, so the agent knows this is a raw DNS resolver rather than an aggregate. It does not explicitly name or contrast with siblings like domain_intel or domain_report, which keeps it 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?

Gives clear usage context ('Use to see where a domain is hosted, who runs its mail and DNS, and what verification/policy TXT records it publishes'), which maps directly to concrete intents. No when-not conditions or named alternatives are offered, so it is context without routing.

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?

Annotations already declare readOnly, idempotent, non-destructive and open-world behavior, so the safety profile is covered. The description adds useful behavioral context beyond that: it discloses the data source (RDAP) and the full set of returned fields, including domain age and abuse contact, which helps an agent judge fitness for vetting tasks.

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: the first front-loads the core identity and the RDAP disclosure, the second covers use cases. The long enumeration of return fields is dense but earns its place as a scannable capability list; nothing is padded.

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?

An output schema exists, so the description need not explain return values, yet it summarizes them anyway for quick scanning. With annotations covering safety and a single well-documented parameter, the definition supplies everything needed to invoke the tool correctly; only sibling routing remains thin.

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?

With a single parameter at 100% schema description coverage, the schema already documents 'domain' and its no-scheme requirement. The description adds no additional syntax or format guidance beyond the schema, so the baseline 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?

States a specific verb+resource ('Registration intelligence for a domain via RDAP') and clarifies the mechanism with a parenthetical definition. It enumerates exactly what data is returned, so an agent can tell it apart from dns_lookup or tech_stack, but it does not distinguish itself from the sibling domain_report, which may overlap.

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?

Gives clear intent contexts – 'vet a company, assess a lead, or judge how established a domain is' – which tells the agent when this tool is appropriate. It stops short of naming alternatives or stating when-not-to-use (e.g. vs domain_report or dns_lookup), so routing among siblings is still partly inference.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, covering the safety profile. The description adds the key behavioral trait that it fans out across four data sources in one call, but does not disclose latency implications, rate limits, or whether partial failures are possible.

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 front-loads what the tool returns and the sources it combines, the second delivers usage guidance. No filler, 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?

An output schema exists, so return-value explanation is unnecessary, and the description correctly focuses on what data categories are combined and when to use it. It is complete enough for confident invocation; missing only handling of partial failures or whether dedicated sibling tools return richer data.

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% with a single, simply documented parameter (domain with example 'stripe.com'). The description reinforces the input being a domain but adds no new formatting or syntax detail beyond the schema, and with only one parameter at full coverage a baseline of 4 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 and resource ('full dossier on a domain') and enumerates exactly what is aggregated: RDAP registration, DNS records, email deliverability, and tech stack. This explicitly distinguishes it from the siblings dns_lookup, email_deliverability, and tech_stack by positioning itself as the combined one-call alternative.

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?

It states clear use cases (lead qualification, company research, recon) and implicitly routes the agent away from the four separate sibling calls. However, it does not specify when NOT to use it – e.g., when only one data type is needed, or whether dedicated tools offer deeper/more complete results. Explicit exclusions would raise this to a 5.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds real behavioral value by enumerating the response content (MX presence, SPF, DMARC, provider classification, overall verdict), though it says nothing about failure modes, caching, or rate limits.

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 compact sentences: the capability first, the returned signals second, the use case last. No filler, and the most decision-relevant information 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?

For a one-parameter read-only tool with an output schema already defined, the description supplies everything an agent needs: what it checks, what it returns in summary, and when to reach for it. Return-value detail can safely live in the output schema.

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 parameter already documents that it accepts a domain or an email address. The description's "(or the domain of an email address)" restates what the schema says rather than adding new semantics, so the baseline 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?

States a specific verb ("Assess whether... can receive mail and how strong its sender authentication is") against a specific resource (domain or email domain), and enumerates the exact checks it performs. This is enough to distinguish it from generic siblings like dns_lookup or domain_intel, which return raw records rather than a deliverability verdict.

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?

"Use to qualify leads and flag throwaway signups" gives a clear intended context for invocation. It stops short of naming when-not-to-use or pointing at an alternative sibling (e.g. dns_lookup for raw records), so it misses the top tier.

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?

Goes well beyond the annotations (readOnly/openWorld/idempotent/destructive) by disclosing that two sources are queried in parallel, that the first responder's result is returned (non-deterministic provenance), and that failure of both sources yields an error instead of a silent empty list. The failure-mode disclosure is exactly the kind of context annotations cannot carry.

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 sentences, each earning its place: what it does and how, what it is for, and how it fails. The most important information (mechanism and source) 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?

With an output schema present, return values need no explanation, and the description still covers mechanism, provenance, intended use, and failure behavior. Nothing an agent needs to call this correctly is missing.

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?

Only one parameter with 100% schema description coverage ('Registrable domain, e.g. stripe.com'), so the schema already does the work. The description adds the notion of public subdomains of a domain but no format or edge-case detail beyond the schema, making the baseline 3 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 verb and resource ('Discover a domain's public subdomains') and names the exact data sources (Certificate Transparency logs, crt.sh, Cert Spotter). This is specific enough to separate it from siblings like dns_lookup or domain_intel, which would not be CT-log based.

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?

Gives clear usage context ('useful for mapping a company's public attack surface or infrastructure'), which tells the agent when this tool is a good fit. It does not name an alternative or a when-not condition, so it falls short of a 5.

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?

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds real behavioral context beyond them: it fetches the homepage, follows redirects (reporting the final URL), and surfaces key response headers. Rate limits and failure behavior remain undisclosed, keeping this at a 4.

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 tight sentences with the core verb+resource front-loaded, followed by detection coverage and a use case. The parenthetical examples (WordPress, Shopify, Next.js) aid agent matching, and no sentence is wasted.

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?

An output schema exists, so return values need not be explained, yet the description helpfully previews them anyway. For a one-parameter read-only tool with full annotation coverage, the definition is essentially complete; only edge-case/error behavior is absent.

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% for the single 'domain' parameter, including the 'Domain or full URL, e.g. shopify.com' hint, so the schema already does the work. The description adds nothing about the parameter itself; 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 verb and resource — 'Fingerprint the technology behind a website by fetching its homepage' — and enumerates what is detected (web server, CMS/framework, CDN, analytics). An agent can immediately tell this is a tech-detection tool rather than a DNS or domain-report tool. It stops short of explicitly naming how it differs from domain_intel or dns_lookup.

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?

'Use for competitive research and lead enrichment' gives a broad context but not the conditions that select this tool over its siblings (domain_intel, dns_lookup, subdomains). No exclusions or prerequisites are stated, so the routing signal is implied rather than explicit.

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