Sift Docs

Sift exposes an MCP server so Claude, ChatGPT, Cursor, and any other MCP-compatible client can query your Sift data conversationally. Set up the connection once and your LLM can search actions, run analytics, read Sift's own skill playbooks, and manage saved searches and queues - all using your existing Sift permissions.

Connect at Settings → MCP Connections (/app/settings/mcp). The page shows a single, org-wide server URL - copy it into whichever client you're connecting (Claude Desktop, Claude Code, Cursor, Windsurf, ChatGPT, Codex CLI), following that client's own connector setup steps.

The MCP settings page with the connection URL — Settings → MCP Connections shows one server URL and per-client setup guides.

Security

The Sift MCP is mostly read-only, with one narrow write capability: the sift_config tool can create, rename, or delete a saved search or a queue on your behalf. Nothing else - no tool can send a reply, modify a user, or touch any other kind of data.

Tools

Tool	Type	What it does
`search`	Read	Full-text and DSL-filtered search across actions, messages, users, agents, queues, tags, and more. Uses the Advanced Search DSL.
`analytics`	Read	Returns analytics metrics (response rate, CSAT, sentiment, and source breakdowns) for a configurable time window and filter.
`sift_config`	Read + write	Reads or manages saved searches and queues: get, list, create, update, rename, or delete. Some writes ask for confirmation first, some don't - see below.
`execute_siftgpt_code`	Read	Runs sandboxed code that can chain many `search`/`analytics` calls together in one request. Cannot write back to Sift.
`list_skills`	Read	Lists Sift's own skill playbooks (name + when to use each).
`read_skill`	Read	Reads one skill playbook's full instructions by name.
`read_skill_file`	Read	Reads one reference file bundled with a skill.

Plus one MCP resource: siftgpt://org-context - a formatted summary of the current organization (used by clients that auto-load context on connect).

What `sift_config` can actually do

Creating a saved search previews first (sample matches + total count) unless you pass confirm: true, in which case it writes immediately.
Renaming a saved search (no criteria change) writes immediately, no confirmation needed.
Changing a saved search's criteria requires confirm: true, same as creating one.
Deleting a saved search or a queue happens immediately - there's no confirmation step for deletes.
Creating or updating a queue always writes immediately - queue changes are never previewed.

If you're giving an LLM access to this tool, treat it accordingly: it can permanently delete a saved search or a queue with no confirmation prompt.

Authentication

The MCP server uses Clerk OAuth (standard authorization-code flow with dynamic client registration, per the MCP spec), or a Sift API key as a bearer token. Specifically:

Scoping. OAuth tokens are issued per Sift user and grant access only to the org(s) and data that user can see in the web app. An API key used as a bearer token instead scopes to that key's org directly, with no associated Clerk user - functionally a service-account credential.
Storage. Access tokens are cached in Redis, keyed by an opaque token ID, validated by presence and expiry on every request. Clerk itself is only consulted once, at initial sign-in.
Expiry. Access tokens expire 90 days after issuance. Auth codes (used once during the OAuth handshake) expire in 5 minutes.
No refresh flow. Only the authorization_code grant is supported - there's no refresh_token grant. When a token expires, the client has to complete the OAuth flow again rather than silently refreshing.
Revocation. There's no way to revoke a single MCP token early - it's a self-contained credential valid until its 90-day expiry. Deleting the user from Sift removes their org access going forward, but any already-issued MCP token for that user keeps working (per the presence+expiry check above) until it naturally expires.

Treat MCP connection URLs and API keys used as MCP bearer tokens like passwords. Anyone with one can act as whoever created it, within that credential's existing permissions - including the sift_config delete capability above.

Connecting a client

Settings → MCP Connections shows one static server URL for your org (the same URL for every user). From there, follow your client's own steps to add a custom MCP connector and paste that URL in:

Claude Desktop: gear icon → Settings → Connectors → Add custom connector → paste the URL → sign in when prompted.
Claude Code: claude mcp add --transport http siftgpt <url>, then run /mcp and authenticate.
Cursor, Windsurf, ChatGPT, Codex CLI: each has its own MCP config screen - paste the same URL there. Sift follows the open MCP standard, so anything that supports MCP supports Sift.