How do you find companies shipping MCP endpoints?

Best move: stop searching directories and probe domains for a live MCP endpoint, then correlate it with the rest of the AI stack.

Why it works: a shipped endpoint is a running server at a known path, not a claim. It answers an initialize handshake, carries OAuth metadata, and lines up with the model provider and SDKs already in the stack.

Key takeaways

• An MCP endpoint is a live remote server, usually on an mcp. subdomain or a /mcp path over Streamable HTTP, not a page that mentions MCP.
• The MCP registry is voluntary and partial, so a directory lookup alone misses most shipped endpoints. Probing domains finds them.
• A live MCP endpoint is the strongest AI-readiness signal there is, because the company exposes agent-callable tooling to the outside world.
• Keyless probing confirms an endpoint exists (a handshake, a 401, a 406, or OAuth metadata), but the tool list often sits behind OAuth.
• Bassethound scores the MCP endpoint inside the same five-layer dossier as the model provider, the SDKs, and the vector store, so one call tells you shipping versus talking.

Where does a shipped MCP endpoint reveal itself?

Four places. First, the hostname. Remote servers cluster on an mcp. subdomain, the same pattern mcp.bassethound.ai uses. Second, the path. A single HTTP endpoint at /mcp is the Streamable HTTP convention, and it answers a JSON-RPC initialize call with a session response rather than an HTML page. Third, the content negotiation. A live server speaks application/json and text/event-stream, so a probe that asks for the wrong Accept type gets a 406 instead of a 404, which is itself a tell. Fourth, the auth trail. MCP authorization builds on OAuth 2.0, so a protected server advertises .well-known/oauth-protected-resource metadata (RFC 9728) and returns a 401 with a WWW-Authenticate header pointing at its authorization server. Any one of these is a lead. The handshake plus the OAuth metadata together is a confident match. Bassethound sends the probe, reads the response, and records which signal fired and how, so the detection is evidence, not a guess. A page that only writes about MCP returns none of these responses, which is why the copy never scores.

Why is a live MCP endpoint the strongest AI-readiness signal?

Because it is the one signal a company cannot ship by accident or by press release. The AI-readiness layer sorts a domain into shipping, experimenting, or none. An llms.txt file is cheap, a homepage that name-drops a model provider is cheaper, and both can go up in an afternoon. Exposing an MCP endpoint is different. It means the company built a server, wired it to real tools or data, stood it up behind auth, and pointed it at the open agent ecosystem so Claude, Cursor, or ChatGPT can call it. That is engineering spend with an external contract attached. When you are hunting for companies that have moved past the demo, the endpoint is the cleanest cut you can make. It also correlates. A domain that ships MCP almost always carries a model provider and an SDK in the same stack, and Bassethound returns all of them together, so you see the endpoint and the backend it fronts in one dossier. The verdict counts how many distinct signal groups fired. An MCP endpoint is one of the heaviest.

Can you find these companies from the MCP registry alone?

No, and betting on the registry will hand you a short, stale list. The Model Context Protocol has an official registry, and it is useful, but listing there is opt-in. A team ships an endpoint for its own agents, its customers, or a partner integration, and never files a server.json anywhere public. Plenty of production endpoints sit on subdomains that appear in no directory, documented only inside a customer’s setup guide. So the registry is a floor, not a census. To find the companies that ship, you invert the search. Instead of reading a list of who registered, you take a set of candidate domains, the ones from a vertical, a funding list, a conference roster, and you probe each one for the endpoint signals. That flips discovery from “who told a directory” to “who answers a handshake,” and the second set is larger and more honest. Bassethound answers the second question. You feed it a domain, it probes, and it reports whether a live MCP endpoint responded, independent of whether that server was ever registered anywhere.

How do you build the list at scale?

Start with a candidate set, not the whole internet. Pull domains from a segment you care about (a category, an accelerator batch, a list of vector-database users) and run each through sniff_domain. Filter the results on the MCP signal in the AI-readiness layer, then rank the survivors by their correlated stack. A domain that returns an MCP endpoint plus an Anthropic or OpenAI SDK plus a vector store is a hard shipping signal. A domain with only a marketing mention drops out. Because every call is stateless and self-contained, you can run a list against the endpoint without managing sessions or keys, on the free tier rate-limited. The standard profile adds the AI stack and firmographics, so each hit comes back with the company name and vertical attached. You score and enrich in one pass, not in a second run against Apollo or Clearbit. Use the deep profile on the finalists when you want the security grade and the Wayback first-seen date, which tells you how long the endpoint has been live. The output is a ranked list of companies that ship agent-accessible tooling, with the evidence for each attached.

What does a keyless crawl miss here?

Be honest about the walls. First, auth. Most production MCP servers gate the tool list behind OAuth, so a keyless probe confirms the endpoint exists but cannot enumerate what it does. You learn that a company ships, not the full surface it ships. Second, location. An endpoint that lives on an internal or undocumented subdomain, never linked from the apex domain, will not surface from probing the marketing host alone. You detect what you can reach. Third, proxying. A server that sits fully behind an API gateway or a reverse proxy can hide its transport signatures, and a static crawl plus optional JS render will not always tease it out. The dossier reports these gaps instead of papering over them. When Bassethound sees a 401 with OAuth metadata, it records “endpoint present, tool list gated,” not a false-confident tool count. When it cannot reach a component, it says so. That honesty is the point. A list of companies shipping MCP is only useful if you trust the misses as much as the hits, and a detector that hides its blind spots is a detector you cannot build a pipeline on.

Bassethound perspective

Everyone selling AI-readiness scores it from the homepage and llms.txt, the two cheapest signals a company can fake, and then stops. The MCP endpoint is the unclaimed axis, and it is unclaimed because it is not a corpus problem. Apollo, ZoomInfo, and Clearbit cannot carry it, because a live endpoint is not a firmographic you buy once and resell. It is infrastructure you have to probe, per domain, at the moment you ask. BuiltWith and Wappalyzer read the front end and never look for a server that answers a JSON-RPC handshake behind OAuth. Our conviction is that finding companies shipping MCP is a probe-and-correlate problem, not a lookup, and that fusion is the moat. An agent could stitch five separate MCP tools together, one for tech stack, one for DNS, one for firmographics, one for AI signals, one for security, and still not get the correlation for free. It would have to join them itself, per domain, on every call. Bassethound returns the endpoint, the provider, the SDK, and the company name already joined, in one keyless call, because we own the crawl. That is the difference between a list of who registered and a list of who ships.

Sources

• Model Context Protocol documentation: https://modelcontextprotocol.io
• OAuth 2.0 Protected Resource Metadata (RFC 9728): https://datatracker.ietf.org/doc/html/rfc9728
• Well-Known URIs (RFC 8615): https://datatracker.ietf.org/doc/html/rfc8615
• llms.txt specification: https://llmstxt.org