What is a hosted MCP server?

Best move: point your agent at the vendor’s URL and let the vendor run the server, instead of installing and maintaining one yourself.

Why it works: MCP is a client-server protocol over a transport. When the server lives at a network endpoint the vendor operates, the client needs the URL and (sometimes) a token. Nothing else.

Key takeaways

• A hosted MCP server runs on the vendor’s infrastructure. Your agent reaches it over the network by URL rather than installing or running it locally.
• “Hosted” describes who operates the server. “Remote” describes the transport (network rather than stdio). A hosted server is a remote server the vendor runs.
• Connecting takes a URL in your agent host’s MCP config plus optional auth (keyless or OAuth), and nothing else on your machine.
• Because the vendor owns the deployment, it can ship the crawl, corpus, or credentials the tool needs, so you do not bring your own key.
• Bassethound is a hosted MCP server at mcp.bassethound.ai/mcp: one keyless call returns a five-layer domain dossier.

What is the difference between a hosted and a local MCP server?

A local MCP server runs on your machine. The client launches it as a subprocess and talks to it over stdin and stdout (the stdio transport). You install the package, provide its runtime, keep it updated, and store any secrets it needs in your own environment. A hosted server inverts that. The vendor runs the process on their infrastructure, exposes it at an HTTPS endpoint, and your client connects over the network using Streamable HTTP or SSE.

The tradeoff cuts both ways. A local server can read your filesystem, shell out to local tools, and run with no network dependency, which is what you want for a server that operates on files you already have. A hosted server gives you zero install, one place for the vendor to ship fixes, and access to server-side resources you could not run yourself: a large crawl, a proprietary corpus, or a pool of API credentials. Bassethound is the second kind. The value is the crawl and the correlation, not code you want on your laptop.

How does an agent connect to a hosted MCP server?

You add the endpoint to your host’s MCP configuration. In Claude, Cursor, or ChatGPT that means naming the server and giving it a URL like https://mcp.bassethound.ai/mcp. The client opens the remote transport, runs the MCP initialize handshake to negotiate protocol version and capabilities, then calls tools/list to learn what the server exposes. From there the model calls tools by name with typed arguments, and the server returns structured results.

Two transports carry this today: SSE (an HTTP connection the server streams events over) and the newer Streamable HTTP, which folds request and response streaming into one endpoint. A well-built hosted server supports the current transport and stays backward compatible where hosts lag. You manage none of it. The URL is the whole integration surface. Adding a hosted server is closer to pasting a link than installing software.

How does authentication work on a hosted MCP server?

Two models, and hosted servers often offer both. The first is keyless. You bring no credential of your own, and the operator meters the endpoint itself. This works when the vendor owns everything the tool needs, so there is no third-party key to pass through. Bassethound’s free tier is keyless for that reason: the crawl is ours, so a call is self-contained. You still sign in, which is what the daily allowance counts against.

The second is OAuth. For higher depth or volume, the client runs an OAuth 2.1 authorization flow, receives a bearer token, and sends it on each request. The MCP authorization spec builds on OAuth 2.1 and standard discovery, so hosts implement the flow once and reuse it across servers. Casual use needs no key, and heavier use upgrades to an authenticated tier without changing the endpoint. Contrast this with a bring-your-own-key model, where every user pastes a third-party API key into their config. That is a worse experience and a worse security posture, and hosting the right resource removes the need for it.

Hosted, remote, stateless: are these the same thing?

These are three separate axes. Remote is about transport: the client reaches the server over a network connection instead of a local pipe. Hosted is about operation: the vendor runs the deployment, not you. Stateless is about memory: the server holds nothing between calls, so every request stands alone.

A server can sit at any point across these axes. You could self-host a remote server on your own VPS (remote, not vendor-hosted). A hosted server could keep per-user session state (hosted, not stateless). Bassethound is all three at once: remote (you connect by URL), hosted (we run it), and stateless (each sniff_domain call is self-contained and read-only, nothing carried from one request to the next). Because it is stateless, the service scales horizontally. Because it is hosted, the crawl can be keyless. Remote is where the wire goes. Hosted is whose machine answers.

What do you give up by using a hosted MCP server?

You take a network dependency. If the endpoint is down or slow, your call fails, and there is no local fallback. You give up direct access to your own filesystem and processes, because the server runs somewhere else. And you send your request data to the vendor, so their handling and retention policy is now part of your threat model. A stateless, read-only server shrinks that surface (Bassethound carries nothing from one call to the next), but trust in the operator never goes away.

You also inherit the vendor’s limits. Rate caps on the free tier, the coverage of their crawl, and the freshness of their data are theirs to set, not yours to tune. For Bassethound, a static crawl plus optional JS render can miss fully server-side or proxied components, and the dossier reports those gaps rather than hiding them. The trade is deliberate: you accept a dependency and a boundary in exchange for zero install and access to a crawl you could not run yourself.

Bassethound perspective

Most “hosted MCP” pitches sell convenience: no install, we run it, done. Convenience is real. The structural win is elsewhere: hosting the right resource makes keyless possible. A local MCP server that wraps BuiltWith or a WHOIS API still needs your key, because the corpus lives behind someone else’s paywall. You have moved the key, not removed it. Because Bassethound owns the crawl, the fingerprinting, and the correlation, a call carries everything it needs. No key to paste, no per-user quota to manage, no third-party account to create.

That is why hosted, keyless, and stateless are one design, not three features bolted on. We host it so the crawl can be ours. The crawl is ours so the call can be keyless. The call is stateless so hosting scales flat. A competitor selling a bring-your-own-key MCP wrapper cannot match that without owning a crawl, and owning the crawl is the expensive part. Hosting is how you deliver it.

Sources

• Model Context Protocol, transports: https://modelcontextprotocol.io/docs/concepts/transports
• Model Context Protocol, specification and authorization: https://modelcontextprotocol.io/specification
• OAuth 2.1 Authorization Framework (IETF draft): https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1
• MDN, Server-sent events: https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events