How long does a domain analysis take?

Best move: pick the profile that matches the depth you need. Fast answers in seconds, deep trades time for history and follow-on probes.

Why it works: every profile runs one call. What changes is how many network round-trips that one call makes, and each added probe costs time.

Key takeaways

• The fast profile returns the full five-layer dossier in about 1 to 3 seconds, with no key.
• Standard and deep take longer because they add AI-stack fingerprinting, firmographics, and follow-on probes.
• Round-trips drive the timing, not parsing. Each external lookup is a fresh request against a live host.
• Deep waits on its slowest external probe, usually the Wayback first-seen history call.
• Every profile returns all five layers correlated in one call, so you never pay the round-trip cost of five separate MCP servers.

What decides how long a call takes?

Three things, in order of weight. First, the profile. Fast does a single crawl and reads what that crawl surfaces. Standard and deep bolt more work onto the same call. Second, network round-trips. Bassethound reads DNS, TLS, and headers from live hosts, and each external lookup is its own request with its own latency. Parsing the response is cheap. Waiting on the wire is not. Third, the target. A slow origin server, an aggressive rate limiter, or a page that needs a JavaScript render all push the call out. None of that is under your control, and none of it is under ours. The dossier reports what it reached and flags what it could not. So the honest answer to how long is a range. You set the floor by choosing a profile. The target sets the ceiling by how fast it answers.

How fast is the fast profile?

About 1 to 3 seconds. Fast is deterministic and keyless by design. It fetches the page once, then reads the layers that fetch exposes: the tech stack from loaded scripts and markup, the infrastructure from DNS, ASN, MX, and the TLS certificate, and the response headers. No AI-stack fingerprinting, no firmographics, no history. Skip the follow-on probes and the timing barely varies. You send the domain, you get the dossier back in the time it takes to crawl one host and resolve its records. That makes fast the right call for a first pass over a list, an ICP triage sweep, or any loop where you score hundreds of domains for a quick signal to sort on. When a hit comes back warm or hot, you run standard or deep on that one domain and pay the extra seconds where they matter.

Why do standard and deep take longer?

Standard is the default, and it earns its extra time. On top of the fast layers it runs the AI-stack fingerprinting (model providers, SDKs, orchestration, vector stores, observability, llms.txt) and the firmographics pass (company, vertical, contacts, social, structured data). That is more of the page to read and more lookups to make. Deep goes further. It adds follow-on probes for llms.txt, .well-known AI files, and MCP endpoints, computes the security header and TLS grades, and calls the Wayback Machine for a first-seen date. Each of those is another round-trip. The Wayback call carries the widest spread, because you wait on an external archive you do not run. The rule of thumb holds without exact numbers: standard costs more than fast, deep costs more than standard, and the gap is round-trips, not compute. You buy depth in seconds, and you pay only for the depth you ask for.

What slows an analysis down the most?

The slowest part of any call is whatever it waits on. Four usual suspects. A JavaScript render, when signals appear only after the client boots, adds the cost of driving a browser instead of reading static HTML. A slow or throttled origin server sets the floor for everything, because the crawl cannot finish until the page answers. An external probe, the Wayback history call in deep, waits on a third party you do not control. And fully server-side or proxied components hide behind a CDN or an API you never see from outside. That last one is a hard limit. The static crawl plus an optional render can miss backend pieces, and the dossier flags the gap rather than guessing. So watch tail latency, not the average. Most calls land in their expected range. The slow ones waited on a host or an archive.

Does the latency matter inside an agent conversation?

Less than the per-call number suggests. An agent that wants tech stack, infrastructure, firmographics, AI readiness, and security from single-purpose tools fires five calls, waits on the slowest, then correlates the payloads itself. Bassethound folds that into one request. You wait once, not five times, and Bassethound already did the correlation. For an interactive turn, the fast profile at 1 to 3 seconds sits inside a normal tool-call budget, so the user rarely feels it. For a background sweep, you run fast across the list and reserve deep for the domains that clear your bar. The endpoint is stateless and read-only, so nothing warms up and no state carries between calls. Every request stands on its own. The latency you pay is the latency of the work, with no overhead you carry forward.

Bassethound perspective

A narrow single-purpose MCP looks fast on paper. One tool, one job, low latency per call. That comparison hides the real cost. To assemble a full picture from single-layer tools, an agent fires five calls, waits on the slowest, then does the correlation work itself. Five fast calls in sequence beat one fused call at nothing. They lose on wall-clock, they lose on token budget, and they hand you five disconnected payloads to reconcile. Bassethound spends its time once. The fast profile returns in seconds because it reads DNS, TLS, headers, and the tech stack from a single crawl. Standard and deep cost more because they earn more: AI-stack depth and history that no homepage scan produces. The honest limit holds throughout. A static crawl plus an optional render can miss fully server-side or proxied components, and the dossier says so instead of guessing. Digby sniffs one trail per request and reports what he could not reach. You trade a few seconds of latency for correlation you would otherwise build by hand.

Sources

• Model Context Protocol specification: https://modelcontextprotocol.io
• llms.txt standard: https://llmstxt.org
• MDN Web Docs, HTTP headers: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers
• Mozilla SSL Configuration Generator: https://ssl-config.mozilla.org