What is a zero-setup MCP tool?

Best move: connect your agent to a remote MCP endpoint by URL and call the tool. No install, no key, no config file.

Why it works: the server runs the crawl and holds the credentials on its side. Your host only speaks MCP over HTTP, so the one thing you manage is a URL.

Key takeaways

• A zero-setup MCP tool is a remote server you reach by URL. There is nothing to install and no local runtime to keep alive.
• Keyless means no bring-your-own-key step. The server owns the crawl and the credentials, so there is nothing for you to store or rotate.
• The MCP protocol is the same over HTTP as over stdio, so Claude, Cursor, and ChatGPT connect to one endpoint with a config line.
• Stateless is part of the design. Each call is self-contained and nothing carries from one call into the next, so there is no session state to manage or tear down.
• Bassethound is a zero-setup tool. Connect to mcp.bassethound.ai/mcp and call sniff_domain for a five-layer dossier in one call.

What makes an MCP tool “zero-setup”?

Three things have to be true. There is no install step. There is no key to provision. There is no config beyond an endpoint URL. A local MCP server fails all three. You clone or install it, you export credentials into its environment, and you point a stdio launcher at the binary that matches your OS. A zero-setup tool moves that burden to the server. The host opens an HTTP connection to the endpoint, the MCP handshake runs, and the tool list comes back ready to call. You never touched a package manager or a secret store. The work that used to live on your machine (fetching, rendering, correlating) now lives behind the URL. That is the whole trade. You give up local control of the runtime, and you get back a tool that works the moment you paste one line into your agent config. For a domain dossier, that means you register the endpoint once and call sniff_domain with a domain and a profile. The barrier to first call drops from “set up an environment” to “know a URL,” which is the difference an agent feels when it needs the tool mid-task.

How is this different from a local MCP server?

A local server is a process you own. You install it, you feed it environment variables, and your host launches it over stdio with a command, arguments, and a working directory. That gives you control. You can pin the version, patch the code, and run it air-gapped. It also gives you work. Every host that wants the tool needs its own launcher, and the runtime has to match the machine it runs on. A remote MCP tool collapses that into a string. The server is already running. Your host connects over HTTP, and the tool surface appears. There is no binary to match, no environment to prepare, and no process to babysit. The two models trade the same axis in opposite directions. Local buys control and charges setup. Remote buys speed and charges control. For enrichment work, where you want a fact about a domain right now and do not need to modify the crawler, remote wins on time-to-first-call. Bassethound is remote by design. The crawl and render pipeline runs on our infrastructure, so the client side stays a URL and a tool name. You point at it, you call it, you read the dossier.

Why does keyless make it truly zero-setup?

A tool can be remote and still not be zero-setup. If it asks you to bring your own API key, you go create an account somewhere, generate a token, and paste it into your host config, then rotate it when it expires. That is setup you own forever. Bassethound holds the credentials for the fetch and render pipeline, so you provision nothing and rotate nothing. The reason is structural, not generous. Because we run the crawl on our own infrastructure, we control the cost, so we can meter by request instead of by your key. A bring-your-own-key tool cannot do that. It is a passthrough to a corpus someone else charges for, so it has to make you authenticate to that corpus. Keyless is not a discount. It is a different architecture, and it is the property that lets an agent call the tool cold, in the same turn, with no prior state. The paid tier layers OAuth on top for higher depth and volume. The entry point stays keyless, which is what keeps the setup cost at zero.

How do you connect Claude, Cursor, or ChatGPT to it?

Every major host speaks remote MCP over HTTP. In Claude you add the endpoint as a connector. In Cursor you drop it into the MCP config with a url field. In ChatGPT you register it as a connector. The UI differs across the three, but the payload is the same. You give it the URL mcp.bassethound.ai/mcp and, for the paid tier, complete an OAuth flow. No command, no args, no local process to keep alive. Once connected, the host lists the tools the server exposes. Here that is one tool, sniff_domain, with a domain argument and a profile argument (fast, standard, or deep). The agent calls it like any other tool in the session. Because the connection is HTTP, the same endpoint works across all three hosts without a per-host binary or a per-OS build. Contrast that with a stdio server, where each host needs its own command line, working directory, and a runtime that matches your machine. Remote MCP turns that whole matrix into one string you can share. That portability is the point. You write the URL down once, and any agent that speaks MCP can pick it up.

Where does zero-setup hit its limits?

Zero-setup buys convenience and costs you two things. First, control of the runtime. You cannot patch the crawler or pin its version, because it runs on our side. If a call misses a fully server-side or proxied component, you take the result the server returns. Bassethound reports those gaps in the dossier rather than hiding them, but you cannot reach in and change the probe. Second, rate limits. The free tier has a daily limit, so a burst of calls will throttle. High volume and deeper probes move to the OAuth paid tier. There is also a trust boundary to name. A remote tool sees the domains you ask about. The call is read-only, but the request itself crosses the network to us. For most enrichment that is fine, and it is the same shape as any hosted API. If you need air-gapped detection, or you want to own the crawl and modify it, a local tool is the right pick. Zero-setup is the default for agents that value time-to-first-call over runtime control, which describes most enrichment work.

Bassethound perspective

The enrichment tools that call themselves MCP-ready mostly hand you a wrapper and a homework assignment: go get a key, paste it here, keep it fresh. That is not zero-setup. It is setup with the bill moved to a signup form. The reason most of them work that way is that they do not own the crawl. They proxy a corpus someone else charges for, so they have to make you authenticate to that corpus. Bassethound runs its own fetch and render, which is why the free tier needs no key from you at all. That is not a pricing gimmick. Signing in is one browser click your client drives for you; provisioning a key is a task you own forever, and the difference is the whole point. The honest test of zero-setup is what you are left holding. A key you provisioned is a task that outlives the call. A sign-in your client drives is not. One URL, one call, five correlated layers back. That is the bar we hold ourselves to, and it is the bar we think the category should be measured against.

Sources

• Model Context Protocol documentation: https://modelcontextprotocol.io
• Anthropic MCP connector documentation: https://docs.anthropic.com
• OpenAI platform documentation: https://platform.openai.com