Our step-by-step guides cover Claude and ChatGPT, because those are the clients we've walked through end to end against real Sitebulb accounts. But the Sitebulb MCP is built on an open standard, which means most AI clients that can add a remote MCP connector should be able to connect using exactly the same ingredients. This page is the client-agnostic recipe: no menu screenshots, just the raw values and the shape of the flow, so you can map it onto whatever tool you're using.
Supported vs should work. Claude and ChatGPT are tutorial-proven - every step in their guides has been tested against a real account. Any other MCP client (Perplexity, Cursor, Claude Code, Codex, and the rest) should work as a standard remote connector, but we haven't verified each one's menus and can't document them all. If another client won't connect, try the same account in Claude or ChatGPT first: if that works, the Sitebulb side is fine and the issue is in the client.
What your client needs to support
Two things, and both are standard parts of the MCP spec:
Remote MCP servers. A connector you add by URL, with nothing installed or run locally. If your client only supports local (stdio-style) MCP servers that it launches as a process on your machine, it can't reach Sitebulb this way.
OAuth sign-in. An authentication type shown as OAuth or "sign in", where the client opens a browser for you to approve access. There is no API-key path for the Sitebulb MCP, so a client that only offers a manual key field can't connect today.
The connection ingredients
Field | Value |
Server URL (Sitebulb Cloud) |
|
Server URL (Sitebulb Desktop) |
|
Authentication type | OAuth (sign in and approve) |
Permission requested | Read-only access to your Sitebulb data |
Client ID / client secret fields | Leave blank - handled automatically |
Those two mcp.sitebulb.com addresses are the only connection URLs Sitebulb supports. Never use a tenant subdomain or a machine-specific address, even if you know one - the shared address is what routes correctly and carries the sign-in flow. The URL you pick is also what selects Cloud versus Desktop; there's no separate scope or setting to choose between them.
The generic steps
Find your client's screen for adding a remote MCP server - usually called connectors, integrations, tools, or MCP servers.
Name it (Sitebulb Cloud or Sitebulb Desktop) and paste the matching server URL from the table above.
Leave any optional OAuth client ID or secret fields blank. Sitebulb supports automatic discovery and registration, so a compliant client fills these in itself.
Start the connection. Your client should open a browser window at
https://auth.sitebulb.com- sign in with your Sitebulb credentials.Choose the 'target': your Cloud workspace, or the Desktop machine to read from. A Desktop machine only appears if Sitebulb Desktop is installed, signed in, running, on an active licence, and online on that computer.
Review the approval screen - the one permission requested is read-only access to your Sitebulb data - and hit Allow.
Test it: "Using Sitebulb, list my projects." Real project names back means you're connected.
Check the address first. Only ever sign in at https://auth.sitebulb.com. And don't paste OAuth codes, tokens, or one-time codes into the chat - nothing legitimate will ask you to.
Terminal and config-file clients
Command-line and editor-based clients such as Claude Code, Codex, and Cursor use the same ingredients; only the packaging differs. The exact flag or configuration entry varies by client, so check its own documentation for adding a remote HTTP MCP server with OAuth - the values you'll be asked for are the server URL and the authentication type from the table above, nothing more. When the client first connects, it should open (or point you to) a browser for the sign-in step, then carry on in the terminal. We haven't walked each CLI client through individually, so treat this as the pattern rather than a promise about any specific tool.
Don't build your own tunnel to Sitebulb Desktop
Technically minded readers sometimes assume that reading from a desktop app must mean exposing that computer to the internet. It doesn't. Every client reaches Sitebulb Desktop through the same shared address, https://mcp.sitebulb.com/desktop, and Sitebulb routes each request through to the machine you authorised while it's running and online. So there's no need for ngrok or similar tunnels, no router port-forwarding, no reverse proxy in front of the app, and no pointing a client at a local-network address - none of it is necessary, and none of it is a supported path. The connection is read-only either way, so a tunnel wouldn't get an assistant anything it can't already read; it would just be an exposure you didn't need.
What to expect once you're connected
Exactly what Claude and ChatGPT users get: the same 15 read-only tools, working from finished crawls only, with URL lists returned as samples of up to 50 per hint. What the Sitebulb MCP can and can't do covers the boundaries, Getting Started and the prompt library will get you asking useful questions, and if something misbehaves, the Sitebulb MCP: troubleshooting and FAQ applies to any client, not just the two we document in detail.