Model Context Protocol

Customer support, served over MCP

SiteGPT runs a remote MCP server with browser-based OAuth. Paste one URL into Claude or any MCP-aware assistant and it can build, train, and manage your support chatbots. Nothing to install, no token to paste.

Listed in the Claude connectors directory
All agent surfaces →
claude, connected to SiteGPT
> List my SiteGPT chatbots, then show this  week’s unresolved conversations for Support Bot   search("list chatbots")  execute_read(GET /api/v2/chatbots)  → 3 chatbots  execute_read(GET /api/v2/conversations?status=open)  ✓ 7 open conversations, 2 waiting on a human

Agents read this page too

Three tools, the whole platform

Three tools, not a hundred stubs

Most MCP servers dump one tool per endpoint into your context window. SiteGPT ships a compact trio over the full API v2 catalog, reads and writes cleanly separated, so the assistant composes anything the dashboard can do without drowning in definitions.

search

Find the right operation

Searches the SiteGPT API v2 catalog and returns the matching operations with their parameters, so the assistant discovers capabilities instead of hallucinating endpoints.

execute_read

Read data, without friction

Runs GET calls through an authenticated bridge. Marked read-only, so assistants can list chatbots and pull conversations without stopping to ask permission at every step.

execute_write

Change things, with consent

Creates, updates and deletes live in their own tool, marked destructive, so assistants confirm before running it. Every call is bounded by your OAuth grant: your role, your token scopes, your chatbot restrictions.

Machine-readable details live in the MCP server card and the MCP docs.

Judging any server

What separates the best MCP servers from the rest

Every list of best MCP servers eventually converges on the same criteria, because assistants make the differences painfully visible. Authentication first: a server that asks you to paste an API key into a config file has already failed the test a browser OAuth approval passes, because a pasted key is unscoped, unrevocable in practice, and sitting in plaintext.

Tool design second. Servers that generate one tool per API endpoint flood the assistant’s context window with definitions before you type a word; servers with honest read/write annotations let the assistant’s permission model work as designed, so lookups flow and changes ask. And scope discipline third: the grant should be a subset of the human who approved it, never a service account with keys to everything.

Those three criteria are the design of this server: OAuth in the browser, three compact tools over a searchable catalog, grants bounded by your role. If you are evaluating MCP servers for a business workflow, apply the same three questions to every one of them, ours included.

Connect in two minutes

Every MCP client, one endpoint

Remote clients connect straight to the endpoint and approve access in the browser. Local clients can run the same server over stdio via the CLI.

Claude (web & desktop)

SiteGPT is listed in the Claude connectors directory at claude.ai/directory/connectors/sitegpt: open it and click Connect, or find it under Settings → Connectors. Or add it as a custom connector with the server URL. Either way, approval happens in the browser. No install, no API key.

Settings → Connectors → Add custom connector
https://sitegpt.ai/mcp

Claude Code

One command adds the remote server; the OAuth approval opens in your browser. Prefer running locally? The stdio variant works too.

add the remote MCP server
claude mcp add --transport http sitegpt https://sitegpt.ai/mcp

Cursor

Point Cursor at the remote server, or run it locally via the CLI.

.cursor/mcp.json
{
  "mcpServers": {
    "sitegpt": {
      "url": "https://sitegpt.ai/mcp"
    }
  }
}

Codex & other stdio clients

Any MCP client that launches stdio servers can run the SiteGPT server through the CLI.

~/.codex/config.toml
[mcp_servers.sitegpt]
command = "npx"
args = ["-y", "@sitegpt/cli", "mcp"]

Building on a runtime we cover? Claude Code, Cursor, Codex, OpenClaw, and Hermes each have a dedicated guide. New to the protocol? Start with MCP for customer support AI, the practical guide.

Safe to hand to an agent

The approval page is the contract

OAuth grant, not a pasted token

The approval page creates a scoped grant for the AI client. You never paste an API key into an assistant, and you can revoke the grant at any time.

Role-aware by construction

The client cannot receive permissions or chatbot access your dashboard user does not have. The grant is a subset of you, never a superset.

Chatbot-level scoping

Approval shows whether the client reaches all chatbots or only the ones you select, so an assistant for one project stays inside that project.

Discoverable, not guessable

The server advertises OAuth metadata automatically and publishes a server card under .well-known, so clients negotiate the connection without manual configuration.

MCP + SiteGPT, answered

What is an MCP server?
An MCP server is a program that exposes a product’s capabilities as tools an AI assistant can call, using the Model Context Protocol: an open standard adopted by Claude, ChatGPT, Cursor, and most agent runtimes. The assistant discovers the tools, asks for data, and requests approval for changes. A good server pairs that with real authentication, which is what SiteGPT’s does with browser OAuth.
What is the SiteGPT MCP server?
A remote Model Context Protocol server at https://sitegpt.ai/mcp. Any MCP-aware assistant, such as Claude, connects to it, asks you to approve access in the browser via OAuth, and can then create and manage SiteGPT chatbots on your behalf.
How do I connect Claude to SiteGPT?
SiteGPT is listed in the Claude connectors directory: open Claude’s connectors settings, find SiteGPT, and click Connect. Claude opens SiteGPT’s OAuth approval page; review the permissions and chatbot access, click Connect, and the SiteGPT tools appear in Claude. Adding https://sitegpt.ai/mcp as a custom connector works too.
Why does the server expose only three tools?
By design. Instead of one tool per endpoint, the server ships a compact trio: search finds the right SiteGPT API v2 operation from the catalog, execute_read fetches data with GET calls, and execute_write creates, updates or deletes resources. Reads are marked read-only so assistants can look things up without interrupting you; writes are marked destructive so they always ask first. Your context window is never flooded with a hundred tool definitions.
Do I paste an API token into the assistant?
No. The approval page creates an OAuth grant for the AI client. During approval SiteGPT shows the app requesting access, the permissions, and whether it can reach all chatbots or only selected ones. The grant never exceeds what your dashboard role allows, and you can revoke it.
How does the OAuth flow actually work?
The server advertises its OAuth metadata under .well-known, so MCP clients discover the authorization endpoint automatically and register via Dynamic Client Registration. Connecting opens a browser approval page showing the requesting app, the permissions, and the chatbot scope; approving mints a grant bound to your role. Tokens refresh silently, and revoking the grant, from either side, ends access immediately.
Can I run the MCP server locally instead?
Yes. npx -y @sitegpt/cli mcp runs the same server over stdio for clients that launch local processes, such as Claude Code, Cursor, and Codex. Remote and local reach the same account.
Does it work without a SiteGPT account?
Chatbot management over MCP uses your account via OAuth. To try SiteGPT with no account at all, agent-first onboarding (documented at sitegpt.ai/auth.md) lets an agent build and train a chatbot from a URL and hand back a preview-and-claim link.

The same platform trusted with real support traffic

SOC 2 Type IIGDPR CompliantHIPAA Compliant
SiteGPT — #1 Product of the Day on Product Hunt

Hand your assistant the keys

One URL, one browser approval, and your AI assistant runs your support platform.