Snapvisor Docs

MCP server

Connect Claude, Codex, Cursor, VS Code, Gemini, Kiro, Antigravity, or any MCP client to Snapvisor's remote MCP server at mcp.snapvisor.io to create builds, upload screenshots, run visual diffs, and approve changes — no CI pipeline required.

Snapvisor runs a remote Model Context Protocol (MCP) server so AI agents can do visual testing end-to-end. Connect once and your agent can create builds, upload screenshots, run diffs, approve or reject changes, and comment — all through the same public API, with no CI pipeline required.

Endpoint

The Snapvisor MCP server is a stateless, streamable HTTP endpoint:

https://mcp.snapvisor.io

Opening the endpoint in a browser redirects here, to this guide. Programmatic MCP clients connect over HTTP and sign in with OAuth or a personal access token (see Authentication).

Plan requirements

The no-CI build loop is included on the Free plan: getMe, createProject, listProjects, getProject, createBuildForProject, updateBuildForProject, finalizeProjectBuilds, findBaselineForProject, getBuild, listBuilds and listBuildDiffs. Reviewing and approving changes, comments, team and billing tools need a paid plan; on Free they reply with an upgrade message. This applies to OAuth and personal access tokens alike. The walkthrough is in Visual testing without CI. Calling the REST API directly with a personal access token is not affected. See Pricing.

Fastest: Add to Claude

On claude.ai, Claude Desktop, or Claude Code signed in with a Claude account, Add to Claude opens Snapvisor's listing in Claude's connector directory: click Connect, then approve the Snapvisor consent screen. Reviewing and approving changes over MCP needs a paid plan (see Plan requirements).

Connect from any MCP client

Snapvisor's MCP server is a hosted Streamable HTTP endpoint with OAuth 2.1 sign-in. There is nothing to install or run: point the client at the endpoint above and sign in to Snapvisor when the browser opens. The first request without a token returns a 401 that triggers the OAuth flow: your browser opens a Snapvisor consent screen, you approve the connection, and the agent is issued a scoped access token. No secrets are pasted into the client. Any client that supports remote MCP servers with OAuth works; the ones below are the common coding agents.

Claude Code

claude mcp add --transport http snapvisor https://mcp.snapvisor.io

Then run /mcp inside Claude Code and follow the browser steps to sign in (or claude mcp login snapvisor from the shell). See the Claude Code MCP docs.

Codex

Add the server with the Codex CLI, then sign in:

codex mcp add snapvisor --url https://mcp.snapvisor.io
codex mcp login snapvisor

Or add it to ~/.codex/config.toml (or .codex/config.toml in a trusted project) and run the same codex mcp login snapvisor:

[mcp_servers.snapvisor]
url = "https://mcp.snapvisor.io"

Cursor

In .cursor/mcp.json (project) or ~/.cursor/mcp.json (global):

{
  "mcpServers": {
    "snapvisor": {
      "url": "https://mcp.snapvisor.io"
    }
  }
}

VS Code and GitHub Copilot

Run MCP: Add Server from the Command Palette, choose HTTP, paste the URL, then pick where to save the server (for example, the workspace's .vscode/mcp.json). To write the file by hand:

{
  "servers": {
    "snapvisor": {
      "type": "http",
      "url": "https://mcp.snapvisor.io"
    }
  }
}

Gemini CLI

Since June 18, 2026, Google AI Pro/Ultra and free Gemini Code Assist accounts no longer work with Gemini CLI; it remains available with Gemini Code Assist Standard or Enterprise licenses and paid API keys. Otherwise use Antigravity.

Add the server to ~/.gemini/settings.json (httpUrl selects the Streamable HTTP transport), then run /mcp auth snapvisor to sign in:

{
  "mcpServers": {
    "snapvisor": {
      "httpUrl": "https://mcp.snapvisor.io"
    }
  }
}

Kiro

In .kiro/settings/mcp.json (workspace) or ~/.kiro/settings/mcp.json (user):

{
  "mcpServers": {
    "snapvisor": {
      "url": "https://mcp.snapvisor.io"
    }
  }
}

Google Antigravity

Antigravity and Antigravity CLI share the same config files. Both require the serverUrl key for remote servers (url and httpUrl are not supported). In ~/.gemini/config/mcp_config.json (global) or .agents/mcp_config.json (workspace):

{
  "mcpServers": {
    "snapvisor": {
      "serverUrl": "https://mcp.snapvisor.io"
    }
  }
}

Other clients

Any other MCP client that speaks streamable HTTP can connect: add a remote (HTTP) server with the endpoint above and approve the OAuth sign-in on first use.

Authentication

The server accepts two credentials:

  • OAuth 2.1 — the default browser-consent flow above. Tokens are issued per client and can be revoked at any time under Settings → Applications in the app.
  • Personal access token — mint one under Settings → Tokens and pass it as a bearer header. Useful for headless or CI agents:
# Use a personal access token instead of the OAuth browser flow
claude mcp add --transport http snapvisor https://mcp.snapvisor.io \
  --header "Authorization: Bearer <your personal access token>"

The MCP server accepts personal access tokens and OAuth access tokens only; project (CI) tokens are rejected with a 401. Project tokens keep working on the legacy SDK routes. To create, upload to and finalize builds, the token's user needs at least reviewer access to the project. See Access tokens.

What agents can do

The tool surface is derived automatically from Snapvisor's public REST API, so it always matches what the product can do. The tools fall into five groups:

  • Build creation — create builds, upload screenshots, and finalize builds entirely over MCP. No CI pipeline needed.
  • Builds and projects — list and inspect builds, projects, and their status across your organization.
  • Screenshot diffs — read the visual changes in any build: baseline, current, and the computed diff.
  • Reviews and approvals — create reviews to approve or reject visual changes without leaving the agent.
  • Comments — read and post build comments so humans and agents stay on the same thread.

Agent workflow

An agent can run a full visual test cycle without any CI integration:

getMe → listProjects → findBaselineForProject → createBuildForProject → upload files →
updateBuildForProject (final: true) → poll getBuild → listBuildDiffs → createReview
  1. Discover — call getMe to find your account slug, then listProjects to find the project name.
  2. Pick a baseline — if the project has no connected Git repository, call findBaselineForProject with commits, your ancestor commit SHAs, closest first. It answers { baseline }, where baseline is null when none of them has an eligible build. Pass baseline.head.sha as referenceCommit (and baseline.head.branch as referenceBranch) in the next step. A build that sends no referenceCommit and whose parentCommits match nothing is compared against the latest approved build on its referenceBranch (the default base branch when unset), else the latest completed one. Only the new build itself is excluded, so a build on the default branch is compared against the previous build on that branch. With no build on that branch it is compared against nothing, so every screenshot then shows as added. A referenceCommit with no eligible build (finished, passed, not rejected, approved) is never replaced by another one: that build is compared against nothing too. The very first build has no baseline and needs no approval: it is stored as the one later builds compare against. See how the baseline is chosen.
  3. Create — call createBuildForProject with a commit SHA and branch. The response includes signed upload URLs for each screenshot the server doesn't already have.
  4. Upload — this step is not a tool call. Send each screenshot file as a multipart/form-data POST to its postUrl, with every entry of fields as a form field and the file itself last, as file. The agent needs to be able to make HTTP requests and read the screenshot files, as coding agents (Claude Code, Codex, Cursor) can from their shell. A chat app that cannot (claude.ai, ChatGPT) can still review, approve and comment on builds, but cannot create one.
  5. Finalize — call updateBuildForProject with final: true to start diff processing.
  6. Poll — call getBuild while status is pending or progress. It then settles on no-changes (nothing to review), changes-detected (review needed), or error, aborted or expired.
  7. Review — call listBuildDiffs to inspect the changes, then createReview with event: "APPROVE" or "REJECT". The build's status becomes accepted or rejected.

How the tools are exposed

The server keeps your agent's context small: instead of listing every operation as its own tool, it exposes two.

  • search_tools returns the operations that match a query, as TypeScript declarations such as external_getMe or external_listBuilds.
  • execute_typescript runs a short program that calls those functions, so several calls cost one round trip.

Every call enforces the same authentication, scopes and plan rules as a direct call. To check a connection, run return await external_getMe({}); through execute_typescript: it answers with the signed-in user and the accounts the connection can reach.

More on connecting agents

The MCP server overview on snapvisor.io covers what the server is for and its discovery documents, and the agent setup pages give a copy-paste prompt for Claude Code, Codex, Cursor and OpenCode.

On this page