MCP Server

Connect AI agents to Digispot crawl data over the Model Context Protocol — the client list, the config each one expects, and what the server exposes.

The Digispot MCP server exposes crawl data to any MCP-compatible AI client. A connected agent queries findings, starts crawls, and drafts fixes without anything being copied between tools.

Configuration is generated for you. Open a project in Spider and use Connect AI agent, or Settings → MCP Server, then pick your client. The snippets below show the shape so you know what you are pasting.

Two server variants

	Desktop Spider	Cloud Platform
Transport	stdio (local process)	HTTP (remote)
Scope	One project, enforced	Cloud account
Tools	64	Varies by plan
Auth	`--project <id>` binding	API key from Settings
Requires	Spider running, Tracker or Leader	Cloud Starter or above

Use the Desktop Spider server when crawl data lives on your machine and must stay there. Use the Cloud server when crawls run on Digispot's servers or a team shares access.

Desktop Spider: local stdio server

The server is a native binary shipped inside the app. Its filename is architecture-specific (mcp-macos-arm64, mcp-macos-x64, mcp-win-x64.exe, mcp-linux-x64), and the app resolves the right one for the current machine.

Every server is bound to one project. The --project argument takes a project id and is mandatory — the server refuses to start unbound, and no tool accepts a project id as a parameter, so an agent cannot reach another project.

Clients

Each client reads a different file, and VS Code uses a different wrapper key.

Client	Where the config goes	Wrapper key
Claude Code	`claude mcp add` (no file to edit)	—
Cursor	`~/.cursor/mcp.json`	`mcpServers`
Windsurf	`~/.codeium/windsurf/mcp_config.json`	`mcpServers`
VS Code (Copilot)	`.vscode/mcp.json` in the repo	`servers`
Claude Desktop	`~/Library/Application Support/Claude/claude_desktop_config.json`	`mcpServers`

For the JSON clients the entry is the same shape. Only the wrapper key changes:

~/.cursor/mcp.json

{
  "mcpServers": {
    "digispot-spider": {
      "command": "/path/to/mcp-macos-arm64",
      "args": ["--project", "<projectId>"]
    }
  }
}

Claude Code registers stdio servers through the CLI instead of a pasted file:

claude mcp add digispot-spider --scope local -- /path/to/mcp-macos-arm64 --project <projectId>

The -- matters. It separates Claude's own flags from the binary's arguments; without it --project is parsed by claude and the command fails. Run it from inside the repo so local scope binds the server to that folder. Use --scope project to write a committed .mcp.json the team shares.

Claude Desktop has a single global config with no per-project scope, so a binding there applies to every Claude Desktop conversation. Prefer a repo-scoped client when you work across several projects.

The server exposes 64 tools covering crawls, pages, issues, Google data, prioritization, workflows, and the Knowledge base, plus 8 packaged SEO skills registered as MCP prompts. See Spider's MCP server for the full reference.

Cloud Platform: HTTP server

The cloud server is reached over HTTP with a key instead of a local binary. It queries cloud data: projects and remaining credits, audit results and top issues, keyword and backlink data, Google metrics, and content opportunities.

Create and revoke keys under API access in the Cloud Platform, which also shows the connection details for your account. See Keys & connections.

A cloud key reaches your whole account. Keep it in an environment variable or a secrets manager, never in version control.

Why connect an agent instead of auditing with one

A language model reading raw HTML cannot run an instrumented audit. Spider applies 313 checks across 25 categories to every page inside a real Chromium browser. Much of that is measurement, not reading.

Rendered-DOM checks need JavaScript to execute first. Fetched source shows the pre-hydration markup, which is a different document.
Core Web Vitals are timings. LCP, CLS, and TBT come from instrumenting a live page load, and no amount of markup inspection produces them.
Device parity means rendering the same URL at mobile, tablet, and desktop viewports and comparing the results.
Site-level checks compare pages against each other — duplicate titles, canonical conflicts, orphan pages, crawl depth. They need the whole graph, not one page at a time.

An agent pointed at a site fetches pages one at a time and re-derives what it can on every run. A mid-sized site exhausts the context window before the analysis starts, and results drift between runs because each samples a different subset of pages.

Spider does that work first and hands over the finished report. The crawler renders every page, runs the checks, and stores the results, so the agent starts from a complete and settled dataset rather than assembling one.

That leaves the model doing what it is actually good at:

Findings arrive as structured data — severity, affected URLs, and Google metrics are fields to reason over, not HTML to parse.
One call replaces a crawl — a single tool returns what would otherwise take hundreds of page fetches.
Results are deterministic — the checks are identical on every run, so an agent's conclusions are reproducible.

The division of labour is the point. Spider measures; the model interprets. It decides what to fix first, explains why a cluster of pages fails together, and writes the fix.

What to ask an agent

With a project bound, the agent works against real crawl data:

"What are the top 10 issues by severity?"
"Which pages fail Core Web Vitals on mobile?"
"Show pages missing a meta description and draft one for each."
"Start a crawl and tell me when it finishes."
"Which pages get the most traffic but fail structured-data checks?"

The last one is where MCP earns its place. The agent pulls traffic data, cross-references failing checks, and returns a prioritized plan in one response. Answering it without MCP would mean exporting two reports and joining them by hand.