Uses Cloudflare DNS over HTTPS to resolve subdomains and retrieve A, AAAA, and CNAME records, enabling live-host checks, NXDOMAIN/no-record status, dangling CNAME detection, and wildcard DNS detection.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@subdomain-finder-mcp Find subdomains of example.com and tell me which are live"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Passive subdomain finder for AI assistants: live certificate transparency lookups (certspotter, crt.sh) with DNS checks over Cloudflare DNS over HTTPS.
This is a Model Context Protocol (MCP) server for subdomain enumeration in bug bounty and security recon. It reads public certificate transparency (CT) logs, deduplicates the names, handles wildcard certificates, and reports first seen, last seen and issuer for each host. It can then resolve the hosts to mark which are live and which have dangling CNAMEs. It needs no API key.
It only reads public CT logs and public DNS. It sends nothing to the target's servers.
No port scanning, no HTTP probing, no brute-force wordlists.
Use it on domains you own or are authorised to test, for example inside a bug bounty program's scope.
Related MCP server: External Reconnaissance MCP Server
Tool | What it returns |
| Deduplicated hostnames for a domain from CT logs, with first seen, last seen, valid until, certificate count, issuers and a wildcard flag. Optional DNS check of up to 40 names. |
| A, AAAA and CNAME chain for up to 40 hosts. Marks live, NXDOMAIN, no records and dangling CNAMEs, names cloud services behind CNAMEs, and detects wildcard DNS. |
| Certificates for one host: issuer, validity dates, every SAN, revocation status and SHA-256, plus first and latest issuance and the issuers used. |
| The domain's CT hostnames grouped into development and test, staging, admin, API, auth, mail, remote access, storage and legacy, with naming clusters, issuers and the newest names. |
Every result has structured JSON, a one-paragraph summary, as_of, source (the CT or DNS query URL) and more (the matching tool on bugbountyreality.com).
A domain's current subdomains. New hosts appear in CT logs within minutes of getting a certificate; a model's training data is months old and never had most of them.
Which hosts resolve right now, which CNAMEs point at a deleted cloud resource, and whether the zone has wildcard DNS.
Certificate history: when each name first got a certificate, which CAs issued it, and when the current one expires.
How to read CT data cleanly: precertificate and certificate rows merged, e-mail SANs and out-of-scope names dropped, *. entries reported as wildcards instead of hosts.
Paste this URL. No token, no sign-up.
https://subdomain-finder-mcp.lipmichal.workers.dev/mcpclaude mcp add --transport http subdomain-finder https://subdomain-finder-mcp.lipmichal.workers.dev/mcpOr run it locally over stdio:
claude mcp add subdomain-finder -- npx -y github:theluckystrike/subdomain-finder-mcpAdd to claude_desktop_config.json:
{
"mcpServers": {
"subdomain-finder": { "command": "npx", "args": ["-y", "github:theluckystrike/subdomain-finder-mcp"] }
}
}Add to ~/.cursor/mcp.json:
{
"mcpServers": {
"subdomain-finder": { "url": "https://subdomain-finder-mcp.lipmichal.workers.dev/mcp" }
}
}Add to .vscode/mcp.json:
{
"servers": {
"subdomain-finder": { "type": "http", "url": "https://subdomain-finder-mcp.lipmichal.workers.dev/mcp" }
}
}Node 20 or newer is needed for the local stdio version. The local version uses your own IP for the CT and DNS lookups, so it has its own rate-limit allowance.
"Find subdomains of hackerone.com from certificate transparency and tell me which are live."
"Which of these hosts have dangling CNAMEs: assets.example.com, docs.example.com, status.example.com?"
"Show the certificate history for api.example.com. Did they change CA this year?"
"Summarise the attack surface of example.com. Any staging, admin or VPN hosts?"
"Include expired certificates and list hosts under example.com that first appeared before 2020."
All public and keyless. Full list with fetch dates in DATA_SOURCES.md.
SSLMate certspotter CT Search API (api.certspotter.com), unexpired certificates. Primary.
crt.sh, including expired certificates. Fallback, and used when include_expired is true.
Cloudflare DNS over HTTPS (cloudflare-dns.com/dns-query).
Certificate transparency only shows names that got a publicly trusted certificate. Hosts behind a wildcard certificate (*.example.com) or with no TLS never appear by name. Pair it with other passive sources for full coverage.
certspotter's keyless tier is rate limited per IP (x-ratelimit-limit: 10 observed). Results are cached for an hour, the tool reads at most 5 pages per call, and it falls back to crt.sh when certspotter throttles. If both throttle, the error says to wait a few minutes.
crt.sh is often slow or overloaded, and two calls minutes apart can return different rows (its database replicas lag). Calls time out after 25 seconds, retry once, then fail with a clear message.
Very large domains return the first pages only; the result says when it was truncated.
DNS checks are capped at 40 hosts per call. A "dangling CNAME" is a lead to verify inside an authorised scope, not proof of a vulnerability.
The web versions of these tools, a subdomain takeover checker and a manual recon checklist are on bugbountyreality.com. See also the certificate transparency lookup and the subdomain enumeration checklist.
Part of the Zovo MCP collection: https://mcp.zovo.one
npm install
npm test # builds, then runs the fixture tests against saved CT and DNS payloads
node scripts/smoke-stdio.mjs # live stdio check, one real call per tool
npx wrangler deploy # Cloudflare Worker, Streamable HTTP at /mcpMIT
Each one is free, needs no API key and has a hosted URL you can paste into Claude or ChatGPT.
server | tools | hosted URL |
convert_ingredient, search_ingredients, scale_recipe, convert_oven_temperature |
| |
calculate_dscr, max_loan_for_target_dscr, rent_needed_for_target_dscr, compare_scenarios, amortization_summary |
| |
get_gold_price_per_gram, get_metal_prices, calculate_jewelry_value, convert_gold_units |
| |
search_lakes, get_lake_level, get_lake_history, compare_lakes |
| |
get_minimum_wage, list_upcoming_increases, compare_states, annual_income_at_minimum_wage |
| |
calculate_overtime_deduction, calculate_tips_deduction, calculate_senior_deduction, estimate_tax_savings, explain_eligibility |
| |
calculate_take_home_pay, compare_states_take_home, salary_to_hourly, hourly_to_salary, get_federal_tax_brackets |
| |
calculate_uk_take_home, get_uk_tax_bands, compare_salaries, marginal_rate_at_income |
| |
list_federal_holidays, is_business_day, add_business_days, count_business_days, invoice_due_date |
| |
calculate_sample_size, estimate_test_duration, test_ab_significance, fisher_exact_test, check_peeking_risk |
| |
get_ap_score_distribution, estimate_ap_percentile, compare_ap_exams, list_ap_exams, estimate_ap_score_from_composite |
| |
calculate_car_loan_interest_deduction, calculate_salt_deduction, get_tax_brackets_and_standard_deduction, calculate_child_tax_credit |
| |
lookup_ingredient_nutrition, calculate_recipe_nutrition, round_nutrition_label, scale_recipe_nutrition |
| |
calculate_section_179, calculate_bonus_depreciation, get_vehicle_depreciation_limits, calculate_asset_loan_payment |
|
The paid back-office collection (invoices, VAT, PDFs, spreadsheets) is at https://mcp.zovo.one
Passive subdomain enumeration for a domain from live certificate transparency logs: certspotter (unexpired certificates) with crt.sh as fallback or for expired history. Returns deduplicated hostnames with first seen and last seen issuance dates, certificate count, issuers and whether a wildcard certificate covers the name, plus the list of wildcard entries. Set resolve=true to also check the first 40 names with DNS over HTTPS and mark live hosts. Passive lookup of public certificate transparency logs; nothing is sent to the target. Use it on assets you own or are authorised to test.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max hostnames returned (1-1000). Totals are always reported. | |
| domain | Yes | Registered domain, for example "example.com". A URL is accepted and reduced to its host. | |
| source | No | auto = certspotter first (fast, unexpired certificates), crt.sh if it fails or throttles. crtsh = crt.sh only (includes expired with include_expired). | auto |
| resolve | No | Also resolve up to 40 of the returned names over DNS (newest first). | |
| max_pages | No | certspotter pages to read (1-5). Each page is one request against its keyless rate limit. | |
| include_expired | No | Also include names from expired certificates (uses crt.sh). Finds retired hosts; slower. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, but the description still adds real behavioral context: fallback and throttling logic between certspotter and crt.sh, the keyless rate limit implied by page reads, the 40-name cap on DNS resolution, and the fact that nothing is sent to the target. That is meaningfully more than the annotations convey.
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?
It is a single dense paragraph, front-loaded with the core action and source behavior, with return shape and caveats following in a sensible order. The authorization sentence and some source detail restate schema content, but nothing is egregiously wasteful.
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?
There is no output schema, and the description compensates fully by enumerating the return payload: deduplicated hostnames, first/last seen issuance dates, certificate count, issuers, wildcard coverage flag, and the wildcard entry list. An agent knows both how to call it and what it will get back.
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 coverage is 100%, so the schema already documents all six parameters, including enum and default values. The description reinforces source selection and the resolve cap and adds the useful detail that resolution 'marks live hosts', but most of what it says about parameters duplicates the schema rather than extending it.
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 — passive subdomain enumeration for a domain from certificate transparency logs — and names the concrete data sources (certspotter, crt.sh). It implicitly separates itself from resolve_subdomains by emphasizing 'passive' and 'nothing is sent to the target', but it never names the siblings, so an agent must infer the boundary rather than being told it.
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 gives clear operating context: passive-only lookup, a source-selection rule (auto/certspotter/crtsh, crt.sh for expired history), and an authorization caveat ('assets you own or are authorised to test'). What it lacks is explicit routing against the siblings — e.g. when to follow up with resolve_subdomains or get_certificate_history instead of setting resolve=true here.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Certificates logged in certificate transparency for one hostname (or a whole domain with include_subdomains): issuer organisation and DN, not_before and not_after dates, every SAN on the certificate, revocation status and SHA-256 where certspotter has them. Summarises first and last issuance and the issuers used, which shows CA changes and renewal cadence. Default source certspotter (unexpired); include_expired uses crt.sh for the full history.
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | Hostname, for example "api.example.com" or "example.com". | |
| limit | No | Max certificates returned, newest first (1-100). | |
| source | No | auto = certspotter first (fast, unexpired certificates), crt.sh if it fails or throttles. crtsh = crt.sh only (includes expired with include_expired). | auto |
| include_expired | No | Also include names from expired certificates (uses crt.sh). Finds retired hosts; slower. | |
| include_subdomains | No | Also include certificates for names under the host. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only annotations, the description discloses the returned data fields, summarization behavior, source fallback from certspotter to crt.sh, throttling behavior, and the slower nature of expired-certificate searches. This adds substantial operational context.
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 front-loaded with the resource and scope, then moves through return fields, summary behavior, and source selection. It is dense but mostly efficient, though the first sentence is long and packs many details together.
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 tool without an output schema, the description explains the key returned certificate attributes and summary outputs. It also covers source fallback, expiry inclusion, and subdomain scope, leaving little ambiguity about what the call produces.
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 host, limit, source, include_expired, and include_subdomains. The description reinforces source and include_expired behavior but adds little parameter meaning beyond what the schema already provides.
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: retrieving certificate-transparency history for one hostname or domain. It clearly distinguishes the scoped host/domain lookup from broader sibling tools such as find_subdomains and summarize_attack_surface.
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 explains the main operating modes: default certspotter for unexpired certificates, include_expired for full crt.sh history, and include_subdomains for domain-wide lookup. It does not explicitly name alternatives or when not to use this tool, but the parameter-driven usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve up to 40 hostnames now through Cloudflare DNS over HTTPS (A, AAAA and the CNAME chain). Each host is marked live, nxdomain, no_records or dangling_cname (a CNAME whose target does not exist, a subdomain takeover lead), and CNAME targets on cloud platforms (S3, Azure, Heroku, GitHub Pages, Netlify, Vercel and others) are named. Also probes a random label per parent domain to detect wildcard DNS. DNS lookups only; no connection is made to the hosts.
| Name | Required | Description | Default |
|---|---|---|---|
| hosts | Yes | Hostnames, for example ["www.example.com", "api.example.com"]. Max 40. | |
| check_wildcard | No | Probe one random label under each parent domain (max 3) to detect wildcard DNS. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses important behavior: DNS-only lookups, no host connections, result statuses (live, nxdomain, no_records, dangling_cname), cloud CNAME naming, and wildcard probing. This adds substantial operational context.
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 front-loaded with the core action and remains dense with useful detail. Every sentence contributes to understanding the tool's output or safety profile.
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 compensates by explaining result statuses, CNAME chain handling, cloud platform naming, wildcard detection, and the no-connection guarantee. It provides enough context for correct 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?
Schema coverage is 100%, so both parameters are already documented. The description reiterates the 40-host limit and wildcard probing, but does not add syntax or meaning beyond what the schema provides.
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: resolve hostnames through Cloudflare DNS over HTTPS. It clearly distinguishes resolution from discovery by saying 'now' and describing DNS-only lookups, which helps separate it from siblings like find_subdomains.
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 gives clear context that this is for resolving known hostnames immediately and that no connections are made to hosts. However, it does not explicitly name alternatives such as find_subdomains or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads a domain's subdomains from live certificate transparency and groups them for recon triage: development and test, staging, admin and internal tools, APIs, authentication, mail, remote access (VPN), storage and CDN, legacy and backup. Each group has a count, examples and why it matters. Also returns naming clusters (for example *.eu.example.com), certificate issuers in use, wildcard entries and the 10 newest names. Passive only.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Registered domain, for example "example.com". A URL is accepted and reduced to its host. | |
| source | No | auto = certspotter first (fast, unexpired certificates), crt.sh if it fails or throttles. crtsh = crt.sh only (includes expired with include_expired). | auto |
| include_expired | No | Also include names from expired certificates (uses crt.sh). Finds retired hosts; slower. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety bar is low. The description still adds real value beyond them: 'Passive only' (no traffic touches the target) and a full inventory of what the response contains — counts, examples, rationale, naming clusters, issuers, wildcards, and 10 newest names.
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 first clause front-loads the action and source, followed by the output inventory. The category enumeration is long but each item conveys what an agent will actually receive, so it largely earns its place; it could be trimmed without loss.
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?
There is no output schema, so the description must describe the return payload — and it does so thoroughly, listing every grouping dimension and supplementary section. Missing only the response shape/ordering and pagination or size limits, which matters for consumers of large domains.
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 coverage is 100%, including the source fallback chain and include_expired semantics, so the schema already carries parameter meaning. The description adds nothing about domain normalization, source selection, or the cost tradeoff of expired certificates beyond what the schema states. 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 (reads subdomains from certificate transparency) and immediately qualifies the value-add: grouping for recon triage. The enumerated group categories make it clearly a summarization tool rather than a raw enumeration tool. It never names a sibling to contrast with, so the boundary with find_subdomains must be inferred.
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 trailing 'Passive only' signals the operating mode, which is a useful selection hint versus active-resolution siblings. However, there is no explicit when-to-use, when-not-to-use, or named alternative (e.g., 'for a raw name list use find_subdomains'). Usage must be inferred from the purpose statement.
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.
v1.0.0find_subdomainsget_certificate_historyresolve_subdomainssummarize_attack_surfaceScored across 4 tools
Each tool has a distinct core action (enumerate, resolve, certificate lookup, triage summary), but find_subdomains and summarize_attack_surface both read the same certificate transparency sources for a domain and differ mainly in output presentation. find_subdomains' resolve=true flag also overlaps with resolve_subdomains, so an agent may pick the wrong entry point for a simple DNS check.
All four tools follow a clean verb_noun snake_case pattern (find_, resolve_, get_, summarize_) with the resource as the noun. No mixed conventions or vague verbs.
Four tools is on the lean side but each covers a genuinely different stage of the recon workflow (enumerate, resolve, inspect certs, triage). Nothing feels redundant enough to remove, though the surface is close to thin.
The toolset covers a coherent end-to-end passive recon lifecycle: discovery, DNS liveness/takeover detection, certificate history, and grouped reporting. Minor gaps remain, such as no export/save of results and no way to feed discovered names directly into history lookups in bulk, but core workflows are covered.
Passive OSINT and security recon: DNS, TLS, email posture, IP reputation, CVE/KEV, CT logs.
Certificate Transparency search: subdomains, certificate history and hostname keyword search.
WHOIS/RDAP, DNS, SSL, live subdomains with IPs, and SPF/DMARC/DKIM for any domain.
Passive domain-perimeter checks — cert expiry, subdomain takeover, lookalikes — as agent tools
