What is a remote MCP server?

Best move: point your agent host at the server’s URL and let the operator run the tool, instead of installing and spawning it locally.

Why it works: MCP defines a network transport (Streamable HTTP), so a server reachable at a URL is a first-class citizen. The operator owns the runtime, so every caller gets the current version with nothing to install.

Key takeaways

• A remote MCP server is an MCP server reached over the network at a URL, not a subprocess spawned on your machine over stdio.
• MCP’s Streamable HTTP transport is what makes remote servers first-class. The client speaks the same protocol either way.
• The operator owns the runtime: updates, crawl, rate limits, and secrets live server-side, so callers install nothing.
• Remote servers can authenticate with OAuth 2.1, which is how a paid tier gates higher depth without a client-managed API key.
• Bassethound is a remote MCP server at mcp.bassethound.ai/mcp: keyless, stateless, one tool that returns a five-layer domain dossier.

How is a remote MCP server different from a local one?

Two axes: where the code runs, and how the client talks to it. A local MCP server runs as a subprocess on your machine. Your host spawns it (npx, uvx, a binary), and the two talk over stdio. A remote MCP server runs on someone else’s infrastructure and answers at a URL over HTTP. The protocol above the wire is the same. The client sends JSON-RPC, lists tools, calls them. What changes is everything around the call.

Installation: a local server is a package you fetch and update; the operator updates a remote one, and you get the new version on your next call. Trust: a local server inherits your filesystem, your environment, and your secrets, while a remote one sees only what you put in the request. Credentials: locally you supply API keys through env vars, but the operator of a remote server can own the keys, so the caller brings none. Failure modes: a local server dies when its subprocess crashes; a remote one dies when the network or host goes down, and every call pays round-trip latency.

Neither is better in the abstract. Local wins for tools that need your machine (files, local ports). Remote wins for tools that need infrastructure you should not run yourself.

How does an agent connect to a remote MCP server?

Through the Streamable HTTP transport. Your agent host reads a config entry that names the server URL instead of a command and args. It opens a session, POSTs JSON-RPC requests, and reads responses over HTTP. When a call streams (long-running work, incremental output), the server pushes chunks back with Server-Sent Events on the same connection.

Discovery follows the connect. The host calls tools/list, the server returns its tool schemas, and the agent can now call them by name with typed arguments. For Bassethound that list has one entry: sniff_domain(domain, profile).

Auth is where remote servers diverge. The MCP spec adopts OAuth 2.1 for remote authorization, and your host runs that flow on every tier. Bassethound has one connection and two limits: a free daily allowance, and paid plans that raise depth and volume.

The practical upshot: connecting is a URL and, sometimes, a login. There is nothing to install, no dependency tree to resolve, no version to pin. The host speaks MCP, the server speaks MCP, and the transport carries it.

Why run a tool as a remote MCP server instead of local?

Because some tools carry infrastructure the caller should not run. A crawler is the clean example. To fingerprint a domain’s stack, you fetch pages, render JavaScript, resolve DNS, pull TLS certs, and stay inside polite rate limits from stable outbound IPs. Ship that as a local server and every agent that uses it drags a headless browser, a DNS resolver, and an IP-rotation problem onto the user’s machine. Ship it remote and one fleet does the work for everyone.

Remote also centralizes the parts that change. Detections improve weekly. A local install goes stale until the user updates. A remote server ships the new fingerprints on the next call, and every caller is current. The same holds for rate limits, caching, and credentials: they live in one place the operator controls.

Then there is the keyless payoff. When the operator owns the crawl and the outbound credentials, the caller needs no API key. That is structurally impossible for a local tool that has to authenticate to third-party services from the user’s machine.

Bassethound is a crawl tool. Keeping the crawl remote is what lets it be keyless, current, and correlated in one call. Local would surrender all three.

What do stateless and keyless mean for a remote MCP server?

Stateless means each call carries everything it needs and nothing carries from one call into the next. No session to resume, no per-user state to corrupt. It scales sideways: any instance can answer any call, and the same input gives the same dossier. For a read-only tool, stateless is the honest shape: you are asking a question, not opening an account.

Keyless means the caller brings no credential. The operator owns the crawl and the outbound API keys, so authentication happens server-side, out of your view. The free tier has a daily limit instead of a key you have to source, store, and rotate. When you need more depth or volume, OAuth upgrades you without moving the crawl credentials to your side.

The two reinforce each other. Because the server is stateless, nothing carries from one call into the next. Because it is keyless, there is no secret for a stateless call to mishandle. Bassethound leans on both: mcp.bassethound.ai/mcp answers a self-contained sniff_domain call, keyless and read-only, and carries nothing from that call into the next. Contrast a bring-your-own-key tool, where the key is the state.

What are the limits of a remote MCP server?

Remote is not free of tradeoffs, and pretending otherwise would be selling.

You depend on the network and the operator. If the host is down or slow, your call is down or slow, and every call pays round-trip latency a local subprocess would not. You also trust the operator with whatever you send. A remote server sees your queries, so read its privacy posture before you route sensitive input through it. Free tiers rate-limit, so high-volume work needs the paid path.

There are limits specific to what the tool does, too. Bassethound reads a domain from the outside. A static crawl plus optional JavaScript render can miss components that run fully server-side or sit behind a proxy, because there is no client-side signature to catch. The dossier says so: it reports what it could not reach instead of guessing.

None of this argues against remote. It argues for knowing the shape. Pick remote when the tool needs infrastructure you should not run, accept the network dependency, and read the gaps the dossier hands back.

Bassethound perspective

Remote MCP gets sold as convenience: nothing to install. That undersells it. Remote is what makes keyless possible. When the operator owns the crawl and the outbound credentials, the caller needs no API key, and the server can meter by request instead of by seat. A bring-your-own-key tool cannot do that, because the caller still has to source and rotate the key.

Remote is also what makes fusion cheap. An agent could wire up five separate MCP servers (tech stack, DNS, TLS, firmographics, AI signals) and correlate the results itself. That is five connections, five auth dances, five failure modes, and the correlation is still the agent’s problem. One remote server that runs the five probes together and returns them correlated is a different product.

Bassethound is that server. One call to mcp.bassethound.ai/mcp returns a five-layer dossier, keyless, stateless, read-only. The moat is not that it is hosted. The moat is what hosting lets us own: the crawl, the correlation, and the free tier.

Sources

• Model Context Protocol documentation: https://modelcontextprotocol.io
• Server-Sent Events, MDN: https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events
• The OAuth 2.0 Authorization Framework, RFC 6749: https://datatracker.ietf.org/doc/html/rfc6749
• An overview of HTTP, MDN: https://developer.mozilla.org/en-US/docs/Web/HTTP/Overview