Scan a site from Claude with the AIScan MCP connector

You can run an AIScan audit without leaving a chat. Add https://aiscan.site/mcp as a remote MCP connector in Claude (or in any client that accepts a remote MCP URL), sign in with your AIScan account once, then ask the assistant to scan a site. It calls scan_website, get_fixes or get_grade and answers from the real report. The connector adds nothing the CLI lacks; it saves the copy and paste between a scan and the conversation where you decide what to fix.

TL;DR

Checks involved: check:P2 (MCP server card, which is how a client learns the endpoint exists) and check:C2 (/llms.txt, which the scan reads first).

What the connector does

The server speaks Streamable HTTP and publishes a card at /.well-known/mcp/server-card.json that names the endpoint, the protocol version (2025-06-18) and OAuth 2.1 with dynamic client registration. Your client registers itself, you approve it in the browser, and it refreshes the token on its own. No key is pasted anywhere.

Eight tools matter for audits. Three work without an account: scan_website (the full report), get_fixes (only failing and partial checks) and get_grade (score, grade, level). Two explain the rubric without scanning: list_checks and get_check_guidance. Signed in, you also get whoami, list_my_scans, get_report, get_domain_history and the monitoring tools. scan_page (one URL, content-weighted) needs a Pro plan.

Path 1: Claude, with the connector directory

1. Open the AIScan page in the Claude connector directory (the Add to Claude button on the AIScan MCP docs goes there).
2. Choose to add it, then sign in with your AIScan account when the browser asks.
3. Start a chat and write: "Run get_grade on https://example.com, then get_fixes if it is under 100."
4. Approve the tool call when Claude asks. The scan takes roughly 15 seconds.

If your plan is Team or Enterprise, an organisation owner has to add a custom connector before members can connect to it, according to Anthropic's custom connector guide. A free Claude plan is limited to one custom connector.

Path 2: Claude Code or any client that takes a URL

1. Claude Code: run claude mcp add --transport http aiscan https://aiscan.site/mcp. The syntax comes from the Claude Code MCP documentation.
2. Inside a session, open the /mcp panel and authenticate the aiscan server when it asks.
3. For Cursor, Windsurf and similar clients, put the JSON from the table in the client's MCP config file and restart it.
4. For automation where a browser sign-in is impossible, use the legacy endpoint https://aiscan.site/api/mcp with an Authorization: Bearer ask_... header and an API key from your profile.

The Model Context Protocol is an open standard, and its specification lets a server require authorisation on its transport, and the 2025-06-18 spec is the version our card declares. I did not test ChatGPT: whether it can add a remote MCP server depends on its plan and release, so read its own documentation first.

What we ran, on 4 November 2026

Connected through OAuth from a Claude Code session, on a free AIScan account. whoami returned the plan free, unlimited scans and page scans enabled. Then one tool per site:

One sample, one day, our own four sites, so treat it as a demonstration and not a benchmark. The useful part is the shape of the exchange: get_grade costs one short answer, and get_fixes returns only the lines you need to act on. A 91 and a 98 both land in Level 5, so the letter grade alone hides the one failing check on the 91; ask for fixes whenever the score is below 100.

Prompts that give a useful answer

The assistant picks the tool from your wording, so name it when you care which one runs.

• "Run get_grade on example.com." One short answer. Use it for a quick look or before a release.
• "Run get_fixes on example.com and list the fixes in the order I should do them." The server returns ordered fix steps per check, so the assistant has real instructions to quote and nothing to invent.
• "Run get_check_guidance for P4 on Astro." No scan runs. You get platform-specific steps for one check, which is the right call when you already know what failed.
• "Compare my last two scans of example.com with get_domain_history." Needs a signed-in account. The tool flags when part of a score change comes from a rubric-version change and not from your site, which matters because the rubric moves (this session's scans used rubric 2026.08.2).

Two habits help. First, ask for the reportUrl every time, so the claim in the chat can be checked against the stored report. Second, keep the fix and the re-scan in the same conversation: after you change the file, ask for get_fixes again and confirm the failing check is gone. A model that says "that should be fixed now" has not scanned anything.

Which route to pick

Use the connector when the decision happens in a chat: you are triaging a client site, writing a ticket, or asking what to fix first. Use the CLI when a script or a CI job needs an exit code. Use the web page when you are sending a result to someone who has no AI client. All three call the same scanner, so a score from one will match the others for the same URL and rubric version.

What the connector cannot do

• It scans public pages. A page behind a login is invisible to it, so a logged-in dashboard scores as its login wall.
• AIScan asks clients to keep to about five scans a minute per URL. A chat that loops over fifty URLs should pause between them.
• Without an account the three scan tools still work, but scans are not saved and list_my_scans and get_domain_history refuse. Sign in if you want history.
• scan_page is Pro only.
• The assistant narrates the report. If its summary and the JSON disagree, the JSON wins; open the reportUrl it returns.

If you would rather check by hand

The connector is a convenience, not a gate. These give the same answer:

1. Run npx aiscan-cli yoursite.com, or paste the URL at aiscan.site. Free, no account.
2. Fetch the card yourself: curl -s https://yoursite.com/.well-known/mcp/server-card.json should return JSON with an endpoint field if you run an MCP server.
3. For the CI version of the same gate, see the GitHub Actions guide; for terminal probes, the terminal audit.

Next action

Connect once, run get_fixes on your own site, and fix the first failing check. Then put the site on monitoring so the next regression reaches you before it reaches a crawler. The per-check pages are in /docs/checks, the developer overview is at /developers, and the full reading list is /guides.