Can you score inbound leads automatically?

Best move: score the lead the moment it lands by passing its email domain to one MCP call.

Why it works: an inbound form already hands you a domain, and a domain is enough to pull a correlated dossier. The dossier’s icp_signal is the score, computed the same way on every lead.

Key takeaways

• Automatic inbound scoring starts from one field you already capture: the lead’s email domain.
• sniff_domain returns an icp_signal (hot, warm, cold) that fuses tech stack, infrastructure, firmographics, AI-readiness, and security into a single grade.
• Because the endpoint is a remote MCP server, your intake agent scores inside one request, keyless and stateless.
• A shipping AI stack is one of the strongest ICP tells, and shallow tools miss it because they read the homepage, not the backend.
• Free-inbox and parked domains carry no firmographic weight, and the dossier flags the gap instead of inventing a number.

What signal turns an inbound lead hot?

The icp_signal is not a single reading. It is what falls out when the five layers agree. A domain running a real AI stack (an Anthropic or OpenAI SDK, a vector store like Pinecone or Qdrant, an orchestration layer), sitting in a vertical that matches your ICP, on infrastructure with a clean security grade, reads hot. The layers reinforce each other. Cold is the inverse: a parked domain, a free inbox, or a stack that contradicts who you sell to. Warm is the middle, where some signals fire and some stay quiet.

The reason a single-layer tool cannot produce this is correlation. A tech-stack scan tells you a site loads a chat widget. It does not tell you the widget is backed by a live model provider, hosted on a CDN that matches an enterprise footprint, on a company whose firmographics fit your book. Bassethound returns all five layers from one crawl, already lined up, so the score reflects every layer at once, not one in isolation.

How do you wire scoring into your intake flow?

The endpoint lives at mcp.bassethound.ai/mcp, and any agent host (Claude, Cursor, ChatGPT) connects to it. On form submit, your intake agent calls sniff_domain(domain, profile) and reads icp_signal, ai_readiness, primary_stack, and security_grade off the response. You route on those fields: hot goes to a rep or a fast lane, warm goes to nurture, cold goes to a low-touch sequence.

The free tier is keyless, rate-limited, so a first-pass gate on every lead needs no key management. The paid tier runs over OAuth when you need higher depth or volume. Because the call is stateless and read-only, the enrichment sits inside the call your agent already makes, and the lead record itself lives in your CRM. The whole score is one round trip, which means the investigation happens inside the request your agent already makes, not across a batch job you run later.

Which profile should the scorer use?

Three profiles, three latency and depth tradeoffs. Fast is deterministic and keyless, returning in roughly one to three seconds. Run it on every inbound lead as a first-pass gate, because it costs almost nothing and still returns an icp_signal. Standard is the default: it adds the AI stack and firmographics, which is the depth you want for real qualification. Deep adds follow-on probes, the security header grade, and Wayback first-seen history, so you learn how long a company has existed and how it hardens its edge.

A sensible funnel uses fast on all inbound to reject the obvious noise, standard on anything that clears the gate, and deep on high-intent events like a demo request or an enterprise-domain signup. You pay for depth only where a lead earns it. The profile is a per-call argument, so the same endpoint serves the cheap gate and the expensive dossier without any extra wiring.

What happens with a free-inbox or thin domain?

Be honest here, because this is where automatic scoring quietly goes wrong. A gmail.com or outlook.com address gives you a person, not a company, so the firmographic and AI layers have nothing to read. A brand-new or parked domain returns thin infrastructure and no AI signal. In both cases the truthful answer is “not enough evidence,” and that is what the dossier reports.

Bassethound does not paper over the gap with a confident-looking score. It flags the free inbox, marks the layers it could not populate, and lets your intake logic decide. The right move is usually to route thin leads to a human or to a follow-up enrichment step, not to auto-reject them, because a real buyer sometimes fills a form from a personal address. A static crawl plus optional JS render can also miss fully server-side or proxied components, and the response says so. A score you can audit beats a score that hides its blind spots.

How is this different from an enrichment API?

Clearbit, Apollo, and ZoomInfo return a company card from a corpus: name, size, industry, headcount, sometimes a contact. That answers who a company is on paper. It does not answer what the company is building right now. Their scores come from data refreshed on a lag, so a startup that shipped an AI product last month looks the same as it did last year.

Bassethound reads the live site instead of a stored record. It fingerprints the stack across five layers and fuses them into one signal. The AI-readiness axis is the one the incumbents do not measure, because deep backend fingerprinting (model providers, SDKs, orchestration, vector stores, LLM observability) is not something a firmographic corpus tracks. And the fusion is the moat: an agent could call five separate MCPs, but it would not cheaply reconstruct the correlation between them. One call returns the layers already lined up, which is what a score needs.

Bassethound perspective

Lead scoring built on firmographics alone is scoring the past. Size and industry tell you who a company was when the corpus was last refreshed. They do not tell you what it is doing this quarter, and in 2026 the sharpest inbound signal is whether a company ships AI. The incumbents cannot see it, because their scores come from a stored record, not a live crawl, and because their AI-readiness (where they claim one) is a homepage-and-llms.txt check. That is the shallow end. It rewards marketing over engineering.

We take the opposite bet. Read the backend, not the brochure. A vector store, an orchestration layer, and a real model provider are expensive to build and pointless to fake, which makes them a better tell than any headline. Fan-out across five separate tools will not close the gap either, because the value is the correlation, and correlation is what you lose the moment you split the call. One request, five layers, one signal. A competitor who sells you a corpus will dispute this. Let them.

Sources

• Model Context Protocol: https://modelcontextprotocol.io
• llms.txt specification: https://llmstxt.org
• Anthropic documentation: https://docs.anthropic.com
• Pinecone documentation: https://docs.pinecone.io