Tech stack, email security (SPF, DMARC, MX provider) and domain age API + MCP. 25 free domains/day.
Scored across 4 tools
Each tool has a clearly stated scope (registration, email/DNS, tech stack, or a full one-domain report), and descriptions explicitly cross-reference when to use each alternative. The main overlap is that domain_report subsumes all three narrow tools, which could tempt an agent to always pick it, but the cost/speed and multi-domain limits in the descriptions mitigate the confusion.
All four names use consistent snake_case noun phrases (domain_registration, domain_report, email_security, tech_stack). The pattern is predictable and readable, with no mixing of conventions or verb styles.
Four tools is on the lean side but each targets a distinct aspect of domain intelligence, so none feels redundant. A slightly richer surface (e.g. a bulk or monitoring tool) could help, but the current count is well-scoped for the purpose.
The set covers registration/RDAP, email and DNS security, website tech stack, and a comprehensive single-domain profile, which is solid lifecycle coverage for domain reconnaissance. Minor gaps remain, such as bulk monitoring or historical data, but core workflows have no dead ends thanks to domain_report.
Domain registration only, for 1-10 domains, from the official RDAP registries. Use this when you need to spot newly registered (possibly risky) domains, check who a domain is registered with, or find upcoming expiries. The fastest and cheapest tool here; no DNS, email or website checks (use domain_report for everything). Input: domains (1-10 domains, URLs or email addresses). Returns results[] with, per domain: registration (registrar, created, updated and expiry dates, age in days, status codes), errors, analyzedAt and cached. Limits: each domain counts as one lookup; answers cached for 1 hour per domain; 25 free domains a day per IP without a key, more with a paid key in the x-api-key header. Read-only: nothing is stored, no email is sent.
| Name | Required | Description | Default |
|---|---|---|---|
| domains | Yes | 1-10 domains, website URLs or email addresses (the domain part is used) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: cost model (each domain counts as one lookup), 1-hour per-domain caching, 25 free lookups/day per IP, x-api-key auth for higher limits, and explicit 'nothing is stored, no email is sent'.
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?
Front-loaded with purpose and routing, then input, returns, and limits in a logical order. Dense but nearly every clause carries usable information; the return-value detail is justified because there is no output schema.
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 and no nested parameters, the description fully compensates by enumerating the results[] fields (registrar, created/updated/expiry dates, age in days, status codes, errors, analyzedAt, cached), plus rate limits and auth requirements. An agent has everything needed to call 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?
Schema description coverage is 100%, so the schema already documents the domains array, its 1-10 bounds, and that URLs/emails have their domain part extracted. The description restates this and adds only the cost-per-domain framing, 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 and resource ('Domain registration only... from the official RDAP registries') and immediately distinguishes itself from siblings by ruling out DNS, email and website checks and naming domain_report as the catch-all 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?
Gives three concrete use cases (spotting newly registered risky domains, checking registrar, finding upcoming expiries) and an explicit exclusion with a redirect ('use domain_report for everything'). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Everything about ONE domain in a single call. Use this when you need to profile one company or website end to end (sales research, vendor or security review, due diligence). For several domains or only one aspect, use email_security, tech_stack or domain_registration instead (cheaper and faster). Input: domain (a domain, URL or email address). Returns check and results[0] with reachable, finalUrl, statusCode, title, description and language of the homepage; technologies[] (CMS, e-commerce, frameworks, analytics, CDN…, each with the evidence it was detected from); email (MX provider, SPF and DMARC policy); dns records and verification tokens; securityHeaders; registration (RDAP registrar, created and expiry dates, age); files (robots.txt, sitemap, llms.txt, security.txt); a one-line summary, analyzedAt and cached. exists tells whether the domain resolves; a site that blocks bots is flagged blocked=true. Limits: each domain counts as one lookup; answers cached for 1 hour per domain; 25 free domains a day per IP without a key, more with a paid key in the x-api-key header. Read-only: nothing is stored, no email is sent.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | One domain, URL or email address, e.g. stripe.com, https://stripe.com/pricing or ops@stripe.com (the domain part is used) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/openWorld, but the description goes further: 1-hour per-domain caching, 25 free lookups per IP per day with a paid key in the x-api-key header, one lookup charged per domain, nothing stored and no email sent, plus the blocked=true and exists flags for edge cases. That is exactly the operational context annotations cannot express.
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?
Front-loaded with purpose, then routing guidance, then input, then the return shape and limits. The enumeration of return fields is long, but it is load-bearing because no output schema exists, so nearly every sentence 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?
With no output schema, the description fully specifies the return payload (check/results[0], technologies, email, dns, securityHeaders, registration, files, summary, analyzedAt, cached) and covers limits, auth and edge cases like bot-blocked sites. Nothing an agent needs to call it 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?
Schema description coverage is 100%, so the single domain parameter is already documented including the URL/email examples. The description restates the accepted input forms and adds only the 'one domain counts as one lookup' constraint, which is billing context rather than parameter semantics. 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 and resource ('Everything about ONE domain in a single call') and immediately scopes it against the sibling tools email_security, tech_stack and domain_registration. An agent can pick this tool without opening any schema.
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 explicit when-to-use scenarios (sales research, vendor or security review, due diligence) and an explicit when-not: several domains or a single aspect should route to the cheaper siblings. Alternatives are named with the condition that selects them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Email and DNS setup only, for 1-5 domains. Use this when you need to check email deliverability or spoofing protection, or to see which email provider (Google Workspace, Microsoft 365…) a company uses. Does not fetch the website (use tech_stack) or registration data (use domain_registration). Input: domains (1-5 domains, URLs or email addresses). Returns results[] with, per domain: exists; email (MX hosts and provider, SPF record and its all qualifier, DMARC policy, pct and rua); dns (A/AAAA/NS records); verifications (services proven by TXT site-verification tokens, e.g. google, apple, atlassian); errors, analyzedAt and cached. Limits: each domain counts as one lookup; answers cached for 1 hour per domain; 25 free domains a day per IP without a key, more with a paid key in the x-api-key header. Read-only: nothing is stored, no email is sent.
| Name | Required | Description | Default |
|---|---|---|---|
| domains | Yes | 1-5 domains, website URLs or email addresses (the domain part is used) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, open-world and non-destructive, so the safety profile is covered; the description goes further by disclosing per-domain lookup accounting, a 1-hour per-domain cache, the 25 free domains/day per IP quota, the x-api-key header for paid keys, and that nothing is stored or emailed.
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?
Front-loaded with purpose and routing before details, and the limits/auth/read-only facts all earn their place. The 'Input: domains (1-5 domains, URLs or email addresses)' clause is mildly redundant with the schema, keeping it just short of 5.
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 usefully enumerates the return shape (results[] with exists, email, dns, verifications, errors, analyzedAt, cached) and covers quota and auth. An agent has everything needed to call 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?
Schema description coverage is 100% for the single `domains` parameter, so the baseline is 3. The description restates the same 1-5 domain / URL-or-email constraint the schema already documents, adding no new syntax or format meaning.
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 ('check email deliverability or spoofing protection', 'see which email provider a company uses') and explicitly names the sibling tools it is not (tech_stack, domain_registration). An agent can distinguish it from all three siblings without opening a schema.
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 explicit when-to-use triggers (deliverability, spoofing protection, provider identification) and explicit when-not alternatives, routing website lookups to tech_stack and registration data to domain_registration. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Website technologies only, for 1-3 sites. Use this when you need to know what a website is built with, for lead qualification by technology or competitor research. Fetches each homepage once; no DNS, email or registration data (use email_security or domain_registration). Input: domains (1-3 domains or URLs). Returns results[] with, per site: reachable, blocked, finalUrl, statusCode, title, description, language; technologies[] (CMS, e-commerce platform, frameworks, analytics, tag managers, CDN, chat and more, each with category and the evidence it was detected from); securityHeaders the homepage sends; errors, analyzedAt and cached. Sites that block bots return blocked=true. Limits: each domain counts as one lookup; answers cached for 1 hour per domain; 25 free domains a day per IP without a key, more with a paid key in the x-api-key header. Read-only: nothing is stored, no email is sent.
| Name | Required | Description | Default |
|---|---|---|---|
| domains | Yes | 1-3 domains, website URLs or email addresses (the domain part is used) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only/idempotent safety profile, but the description goes well beyond them: it discloses that each homepage is fetched once, that bot-blocking sites return blocked=true, the caching window, the rate limits and auth header, and that nothing is stored and no email is sent. This is rich operational context an agent needs.
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?
Front-loaded with purpose and usage, then segmented with 'Input:', 'Limits:' and 'Read-only:' labels, which keeps a long paragraph navigable. The return-value enumeration is lengthy but earns its place given there is no output schema; a small amount of redundancy exists between the homepage-fetch and per-domain-lookup statements.
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?
Even without an output schema, the description enumerates the response shape (results[] with reachable, blocked, finalUrl, statusCode, technologies[], securityHeaders, errors, analyzedAt, cached), which is exactly what an agent needs to consume the result. Rate limits, auth, caching and safety are all covered.
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 schema already documents the single domains parameter, making 3 the baseline. The description adds the cost semantics ('each domain counts as one lookup') but its '1-3 domains or URLs' phrasing omits the email-address input the schema explicitly permits, adding no meaningful 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?
States a specific verb+resource ('Website technologies only, for 1-3 sites') and immediately differentiates from siblings by naming email_security and domain_registration as the tools for DNS/email/registration data. An agent can distinguish this from domain_report without opening any schema.
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?
Explicitly states when to use it (lead qualification by technology, competitor research), when not to use it (no DNS, email or registration data) and names the alternatives for those cases. Limits are also spelled out: one lookup per domain, 1-hour cache, 25 free domains/day per IP, paid key via x-api-key.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
domain_registration3 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / domains / descriptionPrevious value: -"1-10 domains, URLs or email addresses, e.g. [\"example.com\"]"New value: +"1-10 domains, website URLs or email addresses (the domain part is used)"Input schema / properties / domains / examplesAdded value: +[
+ [
+ "stripe.com",
+ "example.com"
+ ]
+]domain_report2 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / domain / examplesAdded value: +[
+ "stripe.com"
+]email_security3 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / domains / descriptionPrevious value: -"1-5 domains, URLs or email addresses, e.g. [\"stripe.com\", \"shopify.com\"]"New value: +"1-5 domains, website URLs or email addresses (the domain part is used)"Input schema / properties / domains / examplesAdded value: +[
+ [
+ "stripe.com",
+ "shopify.com"
+ ]
+]tech_stack3 fields changedInput schema / additionalPropertiesAdded value: +falseInput schema / properties / domains / descriptionPrevious value: -"1-3 websites as domains or URLs, e.g. [\"stripe.com\"]"New value: +"1-3 domains, website URLs or email addresses (the domain part is used)"Input schema / properties / domains / examplesAdded value: +[
+ [
+ "stripe.com"
+ ]
+]domain_registration1 field changedInput schema / properties / domains / descriptionAdded value: +"1-10 domains, URLs or email addresses, e.g. [\"example.com\"]"domain_report1 field changedInput schema / properties / domain / descriptionPrevious value: -"e.g. stripe.com"New value: +"One domain, URL or email address, e.g. stripe.com, https://stripe.com/pricing or ops@stripe.com (the domain part is used)"email_security1 field changedInput schema / properties / domains / descriptionAdded value: +"1-5 domains, URLs or email addresses, e.g. [\"stripe.com\", \"shopify.com\"]"tech_stack1 field changedInput schema / properties / domains / descriptionAdded value: +"1-3 websites as domains or URLs, e.g. [\"stripe.com\"]"domain_registrationdomain_reportemail_securitytech_stackDomain enrichment: email provider, DMARC/SPF/DKIM, WHOIS age, SSL, hosting and CDN per domain.
Email verification and domain intelligence for AI agents. MX, RDAP, SSL checks. 25 free credits.
Tech stack, WHOIS, DNS, SSL, hosting and SEO checks for lists of domains.
Domain intel for AI agents: RDAP registration, DNS, email deliverability, tech stack.
Add one secure layer between your agents and this server.