Why do most enrichment MCPs require an API key?

Best move: check whether the MCP owns its data source or relays someone else’s. If it relays, it needs your key.

Why it works: an API key is the upstream vendor’s meter. A server that proxies a paid corpus bills against that meter, so it makes you bring the key. A server that runs its own fetch has no meter to pass through.

Key takeaways

• Most enrichment MCPs are thin proxies over a commercial data API (Clearbit, Apollo, BuiltWith, Censys), and that upstream vendor requires the key.
• The key requirement is inherited, not chosen. The MCP passes the vendor’s metering and billing straight down to you.
• Bring-your-own-key is a licensing and cost constraint, not a security one. You pay the vendor, not the MCP author, and the author never touches the bill.
• A server that owns its crawl, fetching the target itself, has no upstream key to pass through, so it runs keyless.
• Bassethound fetches the domain live and returns five correlated layers keyless, rate-limited on the free tier.

What is the API key paying for?

The key authenticates you to an upstream data vendor, not to the MCP server. Enrichment MCPs for firmographics wrap Clearbit, Apollo, or ZoomInfo. Tech-stack MCPs wrap BuiltWith, Wappalyzer, or TheirStack. Infra and OSINT MCPs wrap Censys, Shodan, WhoisXML, or IPinfo. In each case the MCP is a translation layer. It turns a tool call into an HTTP request against a metered commercial endpoint. The vendor issues the key, counts the calls, and sends the bill.

So the key is the meter. Its job is to attribute every lookup to a paying account and enforce a quota. Configure that key in your MCP client and you hand the server your vendor credentials, so it spends against your quota. The tool call itself needs no key. The corpus behind it does. That distinction tells you the key guards the vendor’s revenue, not the server. The MCP is the pipe it flows through.

Why can’t the MCP just absorb the cost?

Economics and contracts. A proxy over a metered corpus pays per call. Absorbing that means the author eats a variable bill that scales with usage from strangers, an unbounded liability for a tool marketed as free. Bring-your-own-key moves the meter onto you. Your key, your quota, your invoice.

It also sidesteps the vendor’s terms. Most commercial data licenses forbid reselling access or pooling many users under one account. An MCP author who ran everyone through a single shared key would breach those terms, and would go broke at scale doing it. So BYOK is part cost, part compliance. The author cannot pool users under one credential, and could not afford it if the license allowed it.

The result is the pattern you keep hitting: an enrichment MCP that does nothing until you paste in a paid credential. That is the honest shape of a tool that resells a corpus it does not own. The key is the seam where the proxy meets the vendor.

When does bring-your-own-key make sense?

Sometimes it is the right call. Some data cannot be re-derived from a single live fetch. Apollo and ZoomInfo maintain contact graphs assembled over years. Censys and Shodan run continuous internet-wide scans. BuiltWith holds historical tech snapshots stretching back years. WhoisXML tracks registration history across the DNS.

If your question needs that corpus (who works at this company, what ports were open last quarter, when did they first adopt a framework), then pay the vendor that owns it. The key buys history and breadth you cannot fetch yourself. A keyless live crawl reads the present. It cannot hand you a longitudinal dataset it never collected.

So the split is corpus depth versus live fusion, not good versus bad. Need a private archive? Bring the key that unlocks it. Need a correlated read on a domain as it stands right now? A keyless crawl gets you there without the account, the quota, or the bill.

How does owning the crawl remove the key?

Bassethound does not proxy a vendor. Call sniff_domain and the server fetches the domain itself over HTTP, then renders JavaScript when the signals call for it. No upstream account, no per-call meter, no invoice to attribute. With no meter in the path, nothing passes through, so there is no key to ask you for.

Abuse control moves to a different mechanism. The free tier has a daily limit. The paid tier uses OAuth for higher depth and volume, and that authorizes your plan. It does not unlock a third party’s dataset. Every call is stateless and read-only, so no call depends on the one before it.

This is the structural difference. A BYOK enrichment MCP is keyed because it relays a corpus it rents. A keyless MCP produces the data on demand from the public web. Owning the crawl collapses five separate keyed lookups into one correlated dossier. Cheaper is a side effect. The point is that no upstream key exists to require.

What can’t a keyless crawl see?

A live fetch reads what the domain serves you. A static crawl plus optional JS render can miss components that run server-side only or sit behind a reverse proxy, and it can miss backend calls that never reach the browser. The dossier reports those gaps instead of guessing at them, so you know where the read is confident and where it is blind.

Keyless also means reading the domain rather than a hoard. Bassethound reads the domain itself, not a scan-history timeline or a corpus-scale archive. The deep profile adds Wayback first-seen dates for a rough adoption history, but that draws on a public source, not a private dataset. If you need years of contact enrichment or port-scan history, that is a corpus vendor’s job, and their key is the honest price of it. Knowing which questions a crawl answers well, and which it cannot, is the difference between a tool you trust and one you overtrust.

Bassethound perspective

The industry treats the API key as a fact of nature. It is a tell. A key means the tool in front of you is a cash register for a corpus someone else owns, and it hands you the bill. That model made sense when enrichment meant querying a private dataset. It makes less sense for domain intelligence, where the data sits on the public web, one fetch away.

Our conviction: keyless beats bring-your-own-key structurally, not as a pricing gimmick. We own the crawl, so there is no upstream meter, so there is no key. Competitors with real corpora will dispute this, and on their turf they are right. You cannot re-derive a five-year contact graph from a live request. But for reading a domain’s stack, infrastructure, firmographics, AI-readiness, and security as they stand today, fetching beats renting. The BYOK tax buys you fan-out across five keyed proxies. It does not buy you correlation. One keyless call does.

Sources

• Model Context Protocol authorization specification: https://modelcontextprotocol.io/specification
• IETF RFC 6749, The OAuth 2.0 Authorization Framework: https://datatracker.ietf.org/doc/html/rfc6749
• MDN, HTTP 429 Too Many Requests: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/429