Connecting an AI assistant to your crawl data is a decision about trust, and you (or your security team) should know exactly what you're agreeing to before you hit Allow. This page is the straight answer: what the connection can do, how sign-in works, where your data goes, and how to switch it all off.
The short version: the Sitebulb MCP is read-only, it connects through your own sign-in, data only moves when you ask a question, it only goes to the AI assistant you chose to connect, and you can remove the connection at any time.
Read-only, by design
The Sitebulb MCP exposes 15 tools, and every one of them reads. There is no tool that can start, pause, stop, or delete a crawl, and none that can change a setting or write anything back into Sitebulb. This isn't a restriction we'll loosen quietly later; it's how the connector is designed, so that connecting an AI assistant never hands it (or anyone prompting it) a way to change your account. Nothing you or the assistant can type through this connection alters your Sitebulb data.
For the full list of what those tools can and can't do in practice, see What the Sitebulb MCP can and can't do.
How signing in works
You connect by adding Sitebulb as a connector in your AI client, then completing a sign-in and approval screen - the same kind you'd see connecting any two apps together. A few details worth knowing:
The sign-in happens in your browser at
https://auth.sitebulb.com- Sitebulb's own sign-in page, not the AI client's. Your Sitebulb password is never shared with the AI client.You choose exactly what the connection reads from: your Cloud workspace, or a specific Desktop machine. It can't reach anything you didn't pick.
The approval screen asks for one permission: read-only access to your Sitebulb data. That's the only permission the Sitebulb MCP ever requests.
The connection is tied to you individually. Teammates who want access sign in and approve for themselves, with their own Sitebulb logins - which also means one person's access can be removed without touching anyone else's. Never share a Sitebulb login so someone can approve a connection as you.
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.
What it can see, and what it can't
A connection reads through your sign-in, so it can only ever see what your own Sitebulb account can see, within the workspace or Desktop machine you authorised. One customer's connection cannot reach another customer's data, and your connection can't reach a workspace or machine you didn't sign into. There's no side door: if you couldn't open it in the Sitebulb app yourself, your assistant can't read it either.
Where your data actually goes
Nothing syncs in the background. Data moves only when you (or your assistant, acting on your instruction in a chat) ask a question that needs it - and what moves is just the data that question needs, whether that's a list of project names or the contents of one report.
Note that this is slightly different for Sitebulb Cloud and Desktop.
Sitebulb Cloud
Your assistant's request goes to https://mcp.sitebulb.com/cloud, which reads the answer from your Cloud workspace and returns it into your chat. No local app is involved; the workspace itself holds the data.
Sitebulb Desktop
Your assistant's request goes to https://mcp.sitebulb.com/desktop, which reaches the specific Desktop machine you authorised. Your crawl data lives on that computer and stays there until a question reads it - and the hop only works while Sitebulb Desktop is installed, signed in, running, on an active licence, and online. If the app is closed, no data flows; your assistant is told the connection is unavailable rather than being shown stale or invented data.
Either way, what comes back is the same data you'd see opening the equivalent screen in Sitebulb yourself. The MCP doesn't expose anything that isn't already visible to you in the product.
The part Sitebulb doesn't control
Once a result lands in your chat, it's inside your AI assistant - and from that point it's handled by that assistant's provider (Anthropic for Claude, OpenAI for ChatGPT) under your agreement and settings with them, not Sitebulb's.
That includes the question people ask most: whether your data is used to train AI models. The controls for that live in your Claude or ChatGPT account settings, and depend on the plan and choices you've made there; Sitebulb has no say in it either way.
Put simply: your assistant treats a Sitebulb answer the same way it treats anything else you paste into a chat. If your organisation has rules about what can go into AI tools, those rules apply to Sitebulb data from the moment it enters the conversation.
Turning it off
Removing the Sitebulb connector from inside your AI client immediately stops that client calling any Sitebulb tool - no support ticket needed, and it works even if Sitebulb Desktop is closed at the time. The full steps, including team-plan variations and an offboarding checklist, are in Disconnecting and revoking Sitebulb MCP access.
One honest caveat: revoking stops future reads, but it can't reach back into conversations that already happened. Anything an assistant fetched before you revoked stays in those chats, under the AI client's own data controls.
For IT and security reviewers
The details a review usually needs are as follows:
Endpoints. These are the three endpoints used:
https://auth.sitebulb.com(sign-in and approval)https://mcp.sitebulb.com/cloud(cloud connection address)https://mcp.sitebulb.com/desktop(desktop connection address)
All traffic to them uses standard HTTPS/TLS, with no unencrypted fallback. Sitebulb does not use tenant subdomains or per-machine addresses for MCP connections.
Authentication. OAuth 2.0, with a single scope:
mcp:read, read-only access to Sitebulb data. Client registration and discovery are handled automatically inside the AI client's own connect flow. Every connection is per-user and individually revocable.No API keys. The sign-in flow is the only way to connect. There is no long-lived secret key for users to generate, store, or accidentally leak.
Blast radius. Worst case, a connected assistant can read what the connecting user's Sitebulb account can read. It cannot modify, delete, or crawl anything, on any account.
Certification. Sitebulb does not currently hold a compliance certification such as SOC 2 or ISO 27001.
Using the answers responsibly
The connection itself is locked down; the remaining risk is ordinary human workflow. Three habits keep it tidy:
Review before you send. An assistant turns crawl data into fluent prose very quickly, and fluency can read as more certainty than the data supports. Skim any client-bound summary against the source numbers first - especially since URL lists come back as samples of up to 50, not complete exports.
Check surprising claims at the source. If an answer contradicts what you know about the site, ask the assistant which audit it used and confirm the number in Sitebulb before acting. A surprising claim is far more often a stale audit or an imprecise prompt than a real finding.
Treat shared output like any other export. Once you paste an AI-generated summary into a document or a Slack channel, it's client data out in the world. Revoking the connection later won't unsend it.
Questions this page didn't answer? Try the Sitebulb MCP troubleshooting and FAQ, or start from Sitebulb MCP: Start Here if you've not connected yet.