Connect Claude over MCP

Snabbsite exposes the owner's own business capabilities to AI clients over the Model Context Protocol. This page is the walkthrough. The scope table, the full tool catalogue, rate limits and the error shape live in MCP tools & scopes.

One endpoint, three ways in:

The endpoint is always https://snabbsite.com/api/mcp. Connections are created by the site owner only.

Path A - claude.ai or Claude Desktop (OAuth)

Add https://snabbsite.com/api/mcp as a custom connector. Clerk is the authorization server: discovery runs over RFC 9728 protected-resource metadata and dynamic client registration is enabled, so there is no key to create in Snabbsite first and nothing to paste. You sign in as the Snabbsite owner and approve the connection.

A five-minute signed delegation binds the verified OAuth client audience to one exact Snabbsite connection. The server never accepts a caller-supplied profile id and never guesses from the owner's newest connection - so an OAuth client cannot end up talking to a site you did not authorize it for.

Path B - Claude Code, Cursor or Codex (API token)

1. Open Settings → Advanced → Developers on the site you want to connect.
2. Create a connection. Choose its reach - this website (the default) or the whole workspace - and tick the scopes.
3. Copy the sajt_live_… token. It is shown once; only a SHA-256 hash and a display prefix are stored. Lost token means new connection.

claude mcp add --transport http snabbsite https://snabbsite.com/api/mcp \
  --header "Authorization: Bearer sajt_live_…"

Any client that can send a header works the same way.

Path C - the CLI (device-code pairing)

snabbsajt pairs itself: POST /v1/cli/pair/start with the scopes it wants, the terminal shows a user code, the owner approves at /dashboard/connect, and /v1/cli/pair/poll returns the token once. Two things worth knowing: the approval screen lists every requested scope and lets the owner untick any of them, so the grant can only ever be narrower than the request; and it mints an ordinary connection, so a paired terminal authenticates through this same surface with no second authorization path.

This is distinct from snabbsajt connect, which mints a read-only delivery token for fetching published content and cannot write. See Headless delivery.

An account with no website yet can still be paired. The approval then covers the whole company, the poll returns websiteId: null, and the connected agent creates the first website itself with create_site (needs workspace:write). Only the company owner may approve that, and only while the company really is empty: one website and the approval screen goes back to asking which one. This is the shape to use when an agent is doing the whole setup, because the alternative was that the owner had to build a website by hand before an assistant could help with anything.

snabbsajt admin pair is the one client that still needs a website, because The admin project file records the site later commands act on. It refuses a company-wide approval and says so.

Discovery: /auth.md

An agent that has never seen Snabbsite can read /auth.md and learn all of the above on its own: the ceremony, the two endpoints, every scope with a one-line description, and what we deliberately do not implement. It follows the auth.md open spec, and the scope table is generated from lib/mcp/scopes.ts, so it cannot drift from the gate.

Two limits stated in the file, because an agent that assumes otherwise waits forever: there is no pre-claim token (nothing is minted until a human has confirmed the code), and no account is ever created for a human. If they do not have one, send them to sign up first.

Choose scopes deliberately

site:read is always on and content:write is on by default. Everything else is off, including publish. Leave it that way unless the agent has a job that needs it - the safe default is an agent that can read the site and edit the draft, and cannot put anything in front of the public.

Two scopes deserve a pause before you tick them: ai:generate spends credits unattended, and crm:read reads personal data about the business's customers.

Scopes are a ceiling, not a grant. Every tool re-checks the connection owner's live website role on each call, so a token can never exceed the permissions of the person who created it, and revoking that person's access neuters the token.

Verify the connection

Ask the agent for list_sites, then get_site_overview for the site you meant to connect. If list_sites returns a site you did not expect, the connection is workspace-scoped rather than pinned to one website.

Edit and publish safely

The intended shape of an agent session is: orient with the read tools, edit the draft with content:write tools, verify, then hand the publish decision back to a human. Publishing is a reviewed action even when publish is granted - prepare_publish creates a short-lived plan and only confirm_pending_action after an owner approval carries it out. The same rail covers unpublishing, publishing a product, granting access and sending a document.

The packaged manage-snabbsajt-site skill encodes exactly this loop. See Agent skills.

When a tool is denied

A denial is not always a bug. Three ordinary causes, in the order worth checking:

• The scope is off. Re-create the connection with it ticked, or leave it off deliberately.
• The owner's own access changed. The token inherits it live.
• The agency switched the area off for this client. A workspace owner can withhold whole product areas from the client's account, and that limit reaches MCP too - the tools authenticate by connection token rather than a JWT, so they carry their own equivalent check. A client whose invoicing is withheld cannot read or send those documents through an agent either. See Hand off to the client.

Advanced draft writes (get_section_json, replace_section_content, set_section_layout) additionally require the workspace's invite-only advanced-editor grant and fail closed without it.