Auditing a website from inside Cursor

Cursor can run a website audit and fix what it finds without leaving the editor. There are two ways to set that up, they cost different amounts, and they suit different work.

Both paths end with the agent holding a list of findings mapped to rules, and your codebase already open next to it.

The two paths

The CLI path puts the squirrel binary in Cursor's terminal. The agent runs it, reads the output, and goes to work. Signed out, it is free and needs no account. Each crawl is capped at 10,000 pages.

The MCP path adds the hosted squirrelscan server to Cursor's config. The agent gets the audit engine as native tools: it starts a cloud audit, polls it, and pulls the report without parsing terminal text. Cloud audits render pages in a real browser and spend credits.

Neither replaces the other. The CLI is the default. The MCP server is what you add when you need rendering or a persistent issue tracker.

Path one: the CLI in Cursor's terminal

Install it in Cursor's built-in terminal:

curl -fsSL https://install.squirrelscan.com | bash

Then ask the agent to audit a URL. The flag that matters is the output format:

squirrel audit https://example.com --format llm

--format llm writes a compact, structured report built for a model to read rather than a person. The agent parses it straight out of the terminal, so nothing needs summarising in between.

The audit runs 300+ rules across 21 categories. SEO and content cover the familiar ground: titles, meta descriptions, headings, canonicals, structured data, thin and duplicated pages. Performance covers Core Web Vitals and the page weight behind them. Security covers headers, mixed content and cookie flags. Accessibility covers the machine-checkable part of WCAG. Agent experience (AX) is the newer set: AI crawler access per named bot, llms.txt, agents.md, how much of a page is markup rather than content, and whether an LLM can parse the page cleanly.

There is a shortcut worth knowing. The squirrelscan skills install in one command:

squirrel skills install

squirrel setup offers the same install on the first run, and the CLI's auto-update keeps the skills current.

That adds an /audit-website command you invoke by typing / in the agent chat, which runs the audit and then works the findings as a loop rather than a one-shot report. The skills install guide covers what each skill does and which clients load them from where.

Path two: the hosted MCP server

The fastest route is the one-click install at squirrelscan.com/add/cursor. Cursor opens, shows an approval dialog, and writes the server into your mcp.json.

The manual equivalent is a .cursor/mcp.json in your project, or ~/.cursor/mcp.json to make it available everywhere. The schema is identical, so the entry copies between them:

{
  "mcpServers": {
    "squirrelscan": {
      "url": "https://mcp.squirrelscan.com/mcp"
    }
  }
}

One thing trips people up. Do not add a "type" field to a remote url entry. Cursor uses that field for stdio servers and distinguishes a remote server by the presence of url instead of command.

Then authenticate, which local audits never need but cloud audits do. Open Settings, then Customize, labelled Tools & Integrations in some builds, find squirrelscan, and click Needs login to run the browser flow, as the setup guide describes. From the Cursor CLI it is one command:

agent mcp login squirrelscan

On a Cursor Business or Enterprise plan an admin MCP allowlist can block https://mcp.squirrelscan.com/mcp until someone adds it centrally, per the client setup page. If the server never appears in settings, that is the first thing to check. The same page has the API-key variant for CI and headless use.

What the agent does

Once the server is connected, an instruction as plain as "audit example.com and fix what you can" turns into a sequence of tool calls.

1. run_audit with the URL. If the estimate is over your organisation's auto-run threshold, the call starts nothing and returns status: "confirmation_required" with the estimate and your balance, and the agent is expected to show you that before spending. An estimate at or under the threshold starts straight away.
2. You approve. The agent calls run_audit again with confirm: true, and gets back a run_id. An agent that already has your approval can pass confirm: true on the first call and skip the round trip.
3. get_audit_status polls that run every 15 to 30 seconds. While it runs, the response carries a progress field with the phase and the page and link counts.
4. get_report pulls the result. summary returns scores and top issues grouped by rule with the fix text deduplicated. llm returns compact text for the agent's context. markdown returns the full report.

From there list_issues reads the per-website issue tracker, sorted by severity and filterable by status and category, and get_rule explains any rule the agent wants to reason about.

Whether the rail fires at all depends on the estimate, and the estimate climbs with the crawl size, because rendering is charged per page on top of the flat base. A max_credits argument acts as a hard guard regardless, and the audit refuses to start if the estimate exceeds it.

One number to avoid misreading. The issue count from list_issues is not the issue count in the report. The tracker folds a rule that fails on 600 pages into a single issue and keeps it open until a later audit re-checks it, so it is legitimately much smaller and moves on its own schedule.

What a session looks like

The instructions that work are ordinary ones. Three that cover most of it:

"Audit example.com and tell me the three worst things." The agent runs the audit, reads the report, and answers in prose. No file changes. This is the one to start with, because it tells you whether the findings match what you already suspect.

"Fix every missing meta description." This is where running it inside the editor pays. The report names the URLs. Cursor has the templates open, so it can trace a URL back to the component that renders its head, add the field to the data source, and change one template rather than thirty pages.

"Re-audit and show me what changed." Over the MCP server this is compare_audits, which diffs two completed runs of a website into seven kinds, new, resolved, worsened, improved, unchanged, still open and not crawled, alongside the per-category score movement. A page the newer audit did not visit comes back as not crawled rather than resolved, which matters when a crawl gets truncated and you would otherwise read silence as success.

The second instruction is the one that fails on a generic chat tool. An agent without your repository can tell you a meta description is missing. It cannot tell you which of your layouts is responsible.

What it costs

Signed out, local CLI audits are free and need no account, with each crawl capped at 10,000 pages. One caveat on cost and privacy: once you are signed in, a run spends credits like any cloud audit, defaults to cloud rendering and can publish its report, because logging in is treated as consent to all three. squirrel audit https://example.com --offline skips cloud features, publishing and telemetry, keeps the run free, and is the flag to use when the crawl has to stay on your machine.

Signed-in audits, from the CLI or through the MCP server, cost 50 credits for the run plus 2 credits per audited page. Every account gets 500 free credits a month with no card, which covers several small audits. A run that fails terminally is refunded automatically, so a crawl that dies halfway does not bill you for the attempt.

Pro is $19 a month and includes 3,000 cloud credits a month.

Gating a deploy on the result

The useful end state is not a person reading a report. It is a build step that fails when the site regresses. --fail-on takes conditions and exits 2 when one trips:

squirrel audit https://example.com --fail-on "score<90,errors>0"

Conditions can be repeated or comma-separated, and they cover an overall score, a per-category score like score:perf<80, a severity floor, or raw error and warning counts. Quote each one: a bare < or > is a shell redirect.

The exit codes are deliberately distinct, so a pipeline can tell a regression from a broken run. 0 means every threshold passed, 2 means one tripped, and 1 means the audit itself failed on bad flags or a network error.

On GitHub Actions there is a published action, so the step is four lines:

- uses: squirrelscan/audit-action@v1
  with:
    url: https://staging.example.com
    fail-on: "score<90,severity>=error"

A deterministic audit needs no login at all. An API key is only required for the cloud features, browser rendering among them, and it goes in as a secret. The CI guide has the GitLab and generic-runner versions.

Cursor can write that step into your workflow file in the same session it fixed the issues, which is the part that keeps the fixes from coming back next month.

When the connection does not work

Five failures cover almost everything.

The server never appears in settings. On a Cursor Business or Enterprise plan an admin MCP allowlist can block https://mcp.squirrelscan.com/mcp until someone adds it centrally. Nothing on your side will fix that.

You added a "type" field. Remove it. A remote entry is identified by url, and type belongs to stdio servers.

The server is listed but every tool fails. It is not authenticated. Open Settings, find squirrelscan and click Needs login, or run agent mcp login squirrelscan from the Cursor CLI.

The audit stops at an estimate instead of running. That is the confirm rail doing its job, not a bug. An estimate over the auto-run threshold comes back as confirmation_required with a cost, and the agent is meant to show it to you before spending. Approve it and the agent calls again with confirm: true.

The audit reads thinner than the page looks. The page assembles its main content in the browser and the run did not render it. Browser rendering is a cloud feature that spends credits, so a signed-out or --offline local audit sees the raw HTML only.

Where this works less well

The audit reads a live URL. It cannot audit a page that only exists on a branch you have not deployed, so pair it with a preview deployment if you want pre-merge feedback.

Rendering is a cloud feature. A signed-out or --offline local audit fetches raw HTML, so the rule that compares raw against rendered content skips without credits. On a site that assembles its main content in the browser, a local-only audit will read thinner than the page looks.

The per-website issue tracker is a cloud feature too. A local run gives you one report at a time. Findings persist across audits only once they land in the tracker, which is what list_issues reads.

And the agent is still an agent. It is good at the mechanical fixes, a missing meta description, an unlabelled image, a security header absent from the config. Decisions about what a page should say are yours, and so is the judgment about which findings are worth the change.

Getting started

If you have Cursor open now, the shortest useful path is the CLI, because it needs no account:

curl -fsSL https://install.squirrelscan.com | bash
squirrel audit https://example.com --format llm

Ask the agent to fix the top three findings and re-run it. Add the MCP server when you want browser rendering and the issue tracker.

For the wider picture, what an SEO MCP server does covers how this fits next to the keyword and backlink platforms, fixing audit issues with an AI agent covers the fix loop itself, and SEO for vibe-coded sites is the one to read if the site was generated rather than written.