Technical SEO

Screaming Frog MCP Comparison: Official vs Mine

May 20, 2026 9 min read 13 views
Official MCP vs Custom MCP comparison illustration.

Screaming Frog MCP Comparison: Official vs Mine

Screaming Frog shipped their official MCP server with SEO Spider 24.0 on May 19, 2026. I've been building one for months on top of my Python library for the .dbseospider format. I was a few days from launching mine when theirs landed.

Lol of course.

Shipping mine anyway because I already built it and they're actually solving different problems. Here's the breakdown for anyone trying to figure out which to use.

TL;DR

  • Official MCP: best when you want to control the Screaming Frog desktop app from an LLM. First-party lifecycle, visible UI mode, native reports, and native bulk exports.
  • Mine: best when you want agents to interrogate crawl data with structured outputs. Typed queries over pages, links, and tabs, plus section audits, diff workflows, graph helpers, prompts, and resources.

They complement each other more than they compete.

Architecture comparison: the official MCP lives inside Screaming Frog SEO Spider, while screaming-frog-mcp sits on top of the Python library and reads the .dbseospider file directly.

The systems

Official Screaming Frog MCP

Shipped May 19, 2026 with SEO Spider 24.0. It's built into the product itself. It runs inside the SEO Spider boundary, not orchestrating it from outside.

What that gets you:

  • Native crawl execution lifecycle, including pause and resume
  • Native reports and bulk exports
  • Screenshots and embeddings
  • Both STDIO and Streamable HTTP modes
  • Visible UI mode while MCP is connected
  • First-party file and script capabilities

If you want "Screaming Frog as a controllable application from an MCP client," this is the right pick. It's the most legitimate baseline and the one most users will reach for first. The visible UI mode in particular is a big deal. Being able to watch the app work while an LLM drives it is genuinely useful.

My MCP (screaming-frog-mcp)

Built on top of my Python library that reverse-engineers the .dbseospider format, which is basically a ZIP-wrapped Apache Derby database. The MCP exposes the native crawl objects through typed query primitives instead of just running the desktop app.

What you get:

  • 70 tools, 13 resources, 9 prompts
  • Stable crawl_id sessions for multi-step analysis
  • Typed queries for pages, links, tabs, and diffs
  • Pagination cursors and structured row flows
  • Read-only SQL access to the raw crawl tables
  • Section-specific audits and analysis
  • Internal link graph helpers
  • Migration and diff workflows between crawls
  • Saved queries you can reuse
  • Background jobs
  • Native CLI parity for crawl launch and exports
  • Safer defaults: managed output roots, allowed paths, explicit escape hatches for unrestricted access

It started as analysis-only. The latest version also covers a meaningful chunk of crawl launch and export parity, so it's no longer "you still need the desktop app to actually run crawls."

A representative flow looks like this: load a crawl once, keep the crawl_id, then query it across multiple steps.

crawl = mcp.call("load_crawl", {"path": "./crawl.dbseospider"})
result = mcp.call("query_pages", {
    "crawl_id": crawl["crawl_id"],
    "limit": 50
})

And because the server is built around structured responses and cursor pagination, the result comes back more like this than a flat export dump:

{
  "rows": [
    {
      "Address": "https://example.com/old-promo",
      "Status Code": 404
    },
    {
      "Address": "https://example.com/expired-event",
      "Status Code": 404
    }
  ],
  "has_more": true,
  "next_cursor": "eyJvZmZzZXQiOjUwfQ=="
}

The official MCP gets you the same crawl data, but the ergonomics are different. For one-off pulls that's fine. For an agent doing multiple steps over the same crawl, typed rows with a stable crawl_id and cursor flow are a different experience.

Comparison by theme

Crawl launch and lifecycle

Official: strongest first-party story. Pause, resume, visible UI mode while connected. It lives inside the product, so it stays aligned with the product's lifecycle behavior automatically.

Mine: covers the basics well, including launch, background jobs, load crawls by DB ID, and crawl listing. But pause and resume aren't really possible from outside the product boundary because the Screaming Frog CLI doesn't expose those commands. This is the gap I can't close from where I sit.

Verdict: if lifecycle control matters, official. If launch plus analysis is enough, mine works.

Analysis quality

Official: capable, but not obviously optimized for the kind of typed, multi-step analysis flows that agents actually need.

Mine: this is where I focused. Typed outputs, stable sessions, reusable prompts and resources, section analysis, graph helpers. Designed from the start for an LLM to interrogate a crawl across multiple turns, not just fire off a single query.

Honestly, this is the main reason I'm shipping mine anyway. The official MCP wins on app control, but if your goal is "let an agent reason about a crawl," structured analysis ergonomics matter a lot.

Exports and reports

Official: native reports and bulk exports directly from the product. Hard to beat.

Mine: now close to parity with CLI-backed export tabs, bulk exports, and report saves. Still external orchestration around the CLI rather than first-party.

If you care primarily about getting exports out to clients, official is cleaner. If you care about querying the data before exporting, mine is more useful.

Workflow breadth

Official: focused on product-native MCP usage. Does its job well within that scope.

Mine: narrower than the broader experimental SEO toolboxes that exist out there. Deeper than the official MCP on structured crawl analysis specifically. The trade-off was deliberate. I'd rather have a focused thing that does analysis well than a broad thing that does everything okay.

Safety and operational model

Official: first-party, which is its own kind of safety. But also pretty broad in power, since it includes script and file capabilities.

Mine: explicit safety posture. Read-only SQL by default. Managed output roots. Safe default allowed paths. An optional escape hatch for unrestricted paths, but you have to opt in. Designed around the idea that agents should be able to do useful work without being able to write arbitrary files or run arbitrary code.

This matters more or less depending on how much you trust the LLM you're running.

At a glance

Dimension Official MCP screaming-frog-mcp (mine)
Lives Inside SEO Spider 24.0 On top of the Python library
Crawl launch Native Yes, via CLI parity
Pause/resume Yes No
Visible UI mode Yes, in Streamable HTTP mode No
Native reports Yes Via CLI exports
Native bulk exports Yes Via CLI exports
Tools Product-native 70
MCP resources Not publicly documented as a separate resource layer 13
MCP prompts Not publicly documented as a separate prompt layer 9
Typed queries (pages/links/tabs) Not the main interaction model Yes
Read-only SQL No Yes
Section audits No Yes
Diff workflows No Yes
Graph helpers No Yes
Safety defaults Product-level Managed output roots, allowed paths
Best for Driving the app Agents reasoning about a crawl

Where each one wins

Use the official MCP when:

  • You want the most legitimate first-party option
  • You want visible UI mode while connected
  • You want native lifecycle control: pause, resume, app integration
  • You want the experience most users will understand immediately
  • You're outputting to clients and the export shape matters

Use mine when:

  • You want predictable typed outputs for agents
  • You want reusable workflows through prompts and resources
  • You want diff, graph, and section analysis built in
  • You want safer defaults around file and SQL access
  • Your goal is "agent reasons about a crawl" more than "agent runs the app"

You can also stack them. Run a crawl with the official MCP, then interrogate it with mine. They don't conflict.

The biggest remaining gap

I want to be honest about this. True pause and resume plus in-product lifecycle is something I can't replicate from outside the product. The CLI doesn't expose those commands. So if you need to programmatically pause a 200k URL crawl, restart from a checkpoint, or any of that, the official MCP is going to handle it better.

I also haven't pushed mine through a 100k+ URL audit yet. The underlying Python library is battle-tested on real audits, but the MCP layer on top is newer. So treat the architectural advantages I'm describing as architecture, not proven scale.

How to choose

If you just want a clean, first-party way to drive Screaming Frog from an LLM, install the official MCP. It's the right default. It's better than mine for app control and it's never going to drift from the product because it ships with the product.

If you're building agents that need to reason about crawl data, try mine. That covers comparing multiple crawls, running section-specific audits, doing migration diffs, and generating reports from typed queries. The analysis ergonomics are why it exists.

If you're me, install both.

How to install

Both can be used from MCP clients, but the official setup in Claude Desktop differs by mode.

Official, in Claude Desktop:

  • STDIO mode: install Screaming Frog's official SEO Spider MCP Extension (spider-mcp.mcpb) from their docs.
  • Streamable HTTP mode: add this config to Claude Desktop, then start the MCP server inside SEO Spider via File > Settings > MCP Server > Start MCP Server.
{
  "mcpServers": {
    "seospider": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "http://localhost:11435/mcp"
      ]
    }
  }
}

See the official SEO Spider MCP configuration docs for the extension download, Streamable HTTP setup, and the visible UI mode details.

Mine, after installing from GitHub:

pipx install git+https://github.com/Amaculus/screaming-frog-mcp.git

Then point your MCP client at the installed command path. For example, in Claude Desktop:

{
  "mcpServers": {
    "screaming-frog-seo": {
      "command": "/full/path/to/screaming-frog-mcp"
    }
  }
}

You can install both at the same time. They don't conflict.

What's next

A few things on my roadmap:

  1. Scale testing. I need to push the MCP through a 100k+ URL audit to confirm the architecture holds at scale. If you have a big crawl and want to try it on yours, hit me up.

  2. Pairing workflows with the official MCP. The two are complementary by design. I want to publish a few example workflows that show running them together: official for lifecycle and exports, mine for the analysis layer on top.

  3. More analysis templates. The reusable prompts and resources are where most of the long-term value lives. I want to add more migration and replatform workflows specifically, since that's where I've seen the biggest leverage on real client work.

  4. Whatever you're missing. Honestly the biggest input I want right now is from people actually using it. If there's a workflow you'd build that the current tools don't support, tell me. I'd rather build what's useful than what I think is clever.

Further reading

Nicolas Billia wrote a great parallel piece this week pairing the official MCP with my underlying Python library. He has a decision tree, 20 combined-use ideas, a GSC + GA4 pipeline example, and SQL workarounds from real audits. Highly recommend: Screaming Frog MCP vs API Python (Spanish).

If you're playing with either MCP and building workflows on top, let me know what you're stitching together. I want to see what people do with this.

Stay in the loop

Want more SEO writing like this?

Follow on LinkedIn for new posts, or browse the rest of the blog.

All posts LinkedIn