The Sitejar MCP server lets any AI assistant that speaks the Model Context Protocol, including Claude Code, Claude Desktop, Cursor, VS Code, Windsurf, and Codex, scan a web page for accessibility, security, privacy, deceptive design, technical quality, and SEO issues, and then fix what it finds, all without leaving the tool you are already working in. You connect it with a single line of configuration, sign in once through your normal Sitejar account, and from then on your agent can call five plain tools on its own: scan a page, fetch the result, list the issues, drill into one dimension, and pull source-level fix guidance. The whole point is that the page your AI just built gets checked for compliance before it ships, by the same AI, in the same session. This guide explains what the server is, how it works under the hood, exactly how to connect it to every major client step by step, what to type once it is connected, and how to troubleshoot the handful of problems people actually hit.
We built this for a specific moment that keeps repeating in modern development. An agent generates a page, a component, or an entire landing page in minutes, and it looks finished. Then a week later someone discovers the buttons are divs, the contrast fails, the cookie banner fires trackers before consent, and the security headers are missing. The Sitejar MCP server closes that gap by making the compliance check part of the build loop rather than a separate audit weeks later. It is written for four kinds of readers at once, so you will find plain-language explanations for people who have never heard of MCP, exact commands for developers, a "just tell the AI" workflow for vibe coders, and a multi-client, multi-site angle for agencies.
What is the Sitejar MCP server?
The Sitejar MCP server is a remote server, hosted at https://mcp.sitejar.app/mcp, that exposes Sitejar's compliance scanning to AI agents through the Model Context Protocol. Rather than logging into a dashboard, pasting a URL, and reading a report yourself, you let your AI assistant do the scanning and the reading, then act on the findings directly in your codebase.
In practical terms, once connected, you can say something like "scan the page I just built at localhost and tell me what fails accessibility" and your agent will run the scan, wait for it to finish, read the issues, pull the fix guidance, and start editing your files. Every scan covers all six of Sitejar's compliance dimensions: Accessibility, Security, Privacy, Deceptive Design Risk, Quality, and SEO. The scan is deliberately single-page, because it is designed for checking one page mid-build; whole-site crawls with history and exports live in the Sitejar dashboard.
Two design decisions define how it feels to use. First, the server never spends Sitejar's own AI budget: it returns deterministic, source-level fix guidance, and your own model, whichever one you are using, does the actual writing. That keeps it fast, predictable, and free of surprise costs on our side. Second, it takes authentication seriously in a way most MCP servers do not, using OAuth 2.1 with PKCE and issuing opaque, revocable tokens, so your existing Sitejar account, multi-factor authentication included, works as-is and access can be cut instantly if needed. We will come back to why that matters.
What is MCP, and why should you care?
If you already know MCP, skip ahead to the connection steps. If you do not, here is the two-minute version, because understanding it makes everything else obvious.
The Model Context Protocol is an open standard that lets AI applications connect to external tools and data in a consistent way. According to the official Model Context Protocol documentation, an MCP server is a program that provides tools an AI can invoke, resources it can read, and prompts it can use, and it can run locally on your machine or remotely over the network. Before MCP existed, every AI tool had to build its own custom adapter for every service it wanted to talk to, which is the integration nightmare Google Cloud describes as the "N times M" problem, where the number of connections explodes with every new model or tool. MCP fixes that the way USB-C fixed charging cables: one standard connector that everything understands.
The protocol was open-sourced by Anthropic in November 2024, and it became the closest thing the AI world has to a universal tool standard once OpenAI adopted it for its own agents in March 2025. That is why the same Sitejar server works in Claude, Cursor, VS Code, Windsurf, Codex, and more: they all speak the same language, so you connect once and it works everywhere. The current stable specification, revised July 28, 2026, made the remote transport stateless, which is a technical detail with a practical upside: any healthy server instance can handle any request, which makes remote servers like ours more reliable behind ordinary web infrastructure.
There are two ways an MCP server can talk to a client, and it matters for setup. Local servers use "stdio," a direct process connection on the same machine. Remote servers, like Sitejar's, use "Streamable HTTP," a network connection to a URL. Sitejar is a remote Streamable HTTP server, which is why most clients connect with just a URL and nothing to install, and why the one exception, older stdio-only clients, needs a small bridge, which we cover below.
How does the Sitejar MCP server work?
The workflow is three steps, and understanding the mechanics helps you use it well. First, connect: you add one line of configuration to your client and, on first use, your client opens a sign-in on sitejar.app where you approve access with your normal account. Second, scan: you ask your agent, in plain language, to scan a URL, and it calls the scan tool, which runs the page through all six dimensions. Third, fix: your agent reads the returned issues and the fix guidance, then writes the changes into your code.
Under the hood, the server exposes exactly five tools, and it is worth knowing them by name because you will see your agent call them, and because you can reference them directly in a prompt when you want precise control.
scan_website scans a single web page across all six compliance dimensions and returns an overall picture plus per-dimension detail. It is the entry point for everything. It is single-page by design, so if you ask for a whole site, the right move is the dashboard.
get_scan_result fetches the result of a scan you started, including its status while it is still running. This is what lets your agent start a scan, wait for it to complete, and then read the findings rather than reporting "still running" and giving up.
get_issues lists the issues found, with filters for dimension, severity, and count. This is how your agent focuses on what matters first instead of dumping everything at once; you can ask for only critical accessibility issues, for example.
get_category_result drills into a single dimension, whether accessibility, security, privacy, deceptive design, quality, or SEO, and returns that dimension's score and issues. Useful when you care about one area, such as a security review before launch.
get_fix_guidance returns deterministic, source-level fix guidance for a specific issue, which your own model then applies. This is the tool that turns findings into edits, and it is where the "your AI does the writing" design shows up: we hand over precise guidance, and your agent writes the code.
Because the agent chains these calls on its own, a single natural-language request typically triggers several tool calls in sequence: scan, poll the result, list issues, fetch guidance, edit. You do not have to orchestrate any of it. You just describe what you want.
How to connect the Sitejar MCP server to any AI client
The remote endpoint is identical everywhere: https://mcp.sitejar.app/mcp. What differs is where each client keeps its configuration and, occasionally, the exact field name it expects. Those small differences are the source of nearly every "it does not connect" complaint, so each section below gives the exact, copy-pasteable configuration for that client. On first connection, every client will open a browser window to sitejar.app for sign-in; approve it with your normal account and you are done. If you do not yet have an account, the Free plan includes MCP access with five single-page scans a month and no card required.
Connect to Claude Code
Claude Code is the fastest to set up because it takes the server as a single terminal command. Run this in your terminal:
claude mcp add --transport http sitejar https://mcp.sitejar.app/mcpThe --transport http flag tells Claude Code this is a remote Streamable HTTP server rather than a local process. The next time you start a Claude Code session and ask it to use Sitejar, it will open the sign-in in your browser. To confirm it is connected, run /mcp inside a Claude Code session and you should see sitejar listed with its five tools. If you want the server available only inside a specific project rather than globally, run the same command from that project's directory with the project scope flag, which keeps it out of your other repos.
Connect to Claude Desktop
Claude Desktop connects to remote servers through its Connectors settings, not through the config file. This trips people up, because the claude_desktop_config.json file that older tutorials mention only supports local stdio servers. For a remote server like Sitejar, do this instead: open Claude Desktop, go to Settings, then Connectors, click Add custom connector, set the name to sitejar and the remote MCP server URL to https://mcp.sitejar.app/mcp, and click Add. Claude Desktop will prompt you to authorize, which opens the sitejar.app sign-in. If you are on a Team or Enterprise plan, an organization owner may need to add the connector under the organization's connector settings first before members can enable it.
Connect to Cursor
Cursor reads MCP servers from a JSON file, and you can keep it either global or per-project. For a global setup that works in every project, create or edit ~/.cursor/mcp.json on macOS and Linux (or %USERPROFILE%\.cursor\mcp.json on Windows). For a project-only setup, create .cursor/mcp.json inside the project; project-level configuration takes precedence if the same server name appears in both. Add this:
{
"mcpServers": {
"sitejar": {
"url": "https://mcp.sitejar.app/mcp",
"type": "streamableHttp"
}
}
}Cursor supports OAuth for remote servers, so when you first use it, a browser sign-in to sitejar.app will appear and Cursor will store the credentials. One critical detail: Cursor only loads MCP servers at startup, so after editing the file you must completely quit and restart Cursor, not just reload the window. Once restarted, open Settings, then Tools & MCP, and you should see a green indicator next to sitejar. If you prefer not to touch JSON, that same Tools & MCP panel has a New MCP Server button that walks you through it.
Connect to VS Code
VS Code exposes MCP tools through GitHub Copilot, and it uses a slightly different JSON shape than Cursor, with a servers key instead of mcpServers. Create .vscode/mcp.json in your workspace, or open the command palette and choose MCP: Open User Configuration to edit your user-level file. Add this:
{
"servers": {
"sitejar": {
"type": "http",
"url": "https://mcp.sitejar.app/mcp"
}
}
}You can also add it from the terminal in one command:
code --add-mcp '{"name":"sitejar","type":"http","url":"https://mcp.sitejar.app/mcp"}'Two requirements are easy to miss. You need VS Code 1.99 or later with GitHub Copilot installed, and MCP tools only appear in Copilot's Agent Mode, not in inline suggestions or the standard chat. If you have added the server but do not see the tools, switch the chat to Agent Mode first, then use the Start action next to the server in the MCP view.
Connect to Windsurf
Windsurf is the client with the most common silent failure, and it is worth knowing why before you begin. Windsurf uses the field name serverUrl for remote servers, not url. If you copy a Cursor configuration and paste it into Windsurf, it will fail with no error message and no connection, which is confusing until you know the cause. The configuration file is global only, at ~/.codeium/windsurf/mcp_config.json (note the .codeium path, not .windsurf). Add this:
{
"mcpServers": {
"sitejar": {
"serverUrl": "https://mcp.sitejar.app/mcp"
}
}
}You can reach the same file through the interface by opening Windsurf Settings and navigating to Cascade, then MCP Servers. As with Cursor, restart Windsurf after saving so the server loads. Windsurf's Cascade agent will then be able to call the Sitejar tools.
Connect to Codex
OpenAI's Codex CLI adds remote servers with a command, and it handles OAuth automatically when you supply only the URL. Run:
codex mcp add sitejar --url https://mcp.sitejar.app/mcpThen authenticate:
codex mcp login sitejarThat opens the sitejar.app sign-in in your browser. To confirm, start codex and run /mcp to see your active servers. If codex mcp add --url is not recognized, your Codex CLI predates streamable HTTP support; upgrade it first with npm install -g @openai/codex. If you use the Codex extension inside VS Code instead of the CLI, open its MCP Settings, choose Add server, select Streamable HTTP, enter the URL, save, refresh, and click Authenticate. A known extension bug can occasionally hide a freshly added server; if that happens, refresh or restart the editor, or fall back to the CLI, which reads the same configuration.
Connect any other client (the stdio bridge)
Some clients, especially older ones, only support local stdio servers and cannot connect to a remote URL directly. For those, you route through mcp-remote, a small bridge that runs locally and forwards to the remote endpoint. Use this configuration, adapting the outer key to whatever your client expects (most use mcpServers):
{
"mcpServers": {
"sitejar": {
"command": "npx",
"args": ["-y", "mcp-remote", "https://mcp.sitejar.app/mcp"]
}
}
}The -y flag lets npx install the bridge without prompting. This same pattern works for Gemini CLI, Zed, Warp, and most other clients that have not yet added native remote support, though many of them now do: Gemini CLI, for example, accepts an httpUrl field in ~/.gemini/settings.json, and Zed uses a context_servers block with a url. When in doubt, check whether your client supports remote Streamable HTTP natively; if it does, use the URL directly, and if not, use the bridge.
What can you actually do once it is connected? Sample prompts
This is the part that turns a connection into a habit. You do not need to learn the tool names to use the server; you describe what you want and your agent chains the tools. But well-phrased prompts get dramatically better results, so here are the ones we use ourselves, grouped by who you are.
If you are a vibe coder building fast with an AI, the simplest habit is a single check before you call something done. Try: "Scan https://your-site.com/pricing with Sitejar and tell me what fails, then fix the accessibility issues in this codebase." The agent will scan, wait, list the issues, fetch guidance, and start editing. If you want it to stay focused, narrow it: "Scan the page and show me only the critical and serious issues." Or make it a gate: "Before we ship, scan the checkout page and confirm there are no critical issues in any dimension; if there are, fix them and rescan."
If you are a developer who wants precision, reference the tools and dimensions directly. Try: "Use scan_website on https://staging.example.com/signup, then call get_category_result for security and list every missing header with its fix guidance." Or a targeted review: "Run a scan and use get_issues filtered to accessibility with severity critical; for each, call get_fix_guidance and apply the change to the corresponding component." Or a comparison after a fix: "Rescan the page and diff the issue count against the previous scan so I can confirm the contrast fixes landed."
If you run an agency or manage several client sites, the server is a fast pre-flight check you can run per client without opening a dashboard for each. Try: "Scan the homepage of each of these three client URLs and give me a one-paragraph summary per site of the most severe issue in each dimension." Or for a client conversation: "Scan https://client-site.com and draft a plain-English summary of the privacy and deceptive-design findings that I can send to a non-technical client, without jargon." Because every scan is a plain tool call, you can fold this into whatever agent workflow you already run for client work.
If you are a non-technical user who just wants to know whether a page is in decent shape, plain English is enough: "Is this page accessible? Scan it and explain the biggest problems like I am not a developer." Or: "Scan my landing page and tell me if the cookie banner is doing anything wrong." The agent will translate the findings, and you can decide whether to hand the fixes to a developer.
A few prompt habits make every one of these work better. Give the full URL including https://, because the server scans exactly the page you name. Tell the agent to wait for the scan to finish when you want a complete result, since scans take a moment and a well-prompted agent will poll get_scan_result rather than reporting prematurely. And when you want fixes rather than a report, say so explicitly; "scan and fix" produces edits, while "scan" alone produces findings.
What are the six dimensions the scan covers?
Every scan checks all six, and knowing what each looks for helps you read the results. Accessibility checks the page against WCAG-aligned criteria: missing alt text, low contrast, missing form labels, invalid ARIA, heading structure, and the other machine-detectable barriers, mapped to the criterion each fails. Security examines the response headers and transport: Content Security Policy, HSTS, frame protections, mixed content, and related hardening, the same checks behind our free security headers tool. Privacy looks at consent and tracking: whether trackers fire before consent, whether the consent mechanism behaves honestly, and related cookie behavior. Deceptive Design Risk flags dark-pattern signals such as pre-checked consent, asymmetric button prominence, and misleading language. Quality covers technical hygiene that affects both users and machines. If speed is the problem, our guide to page weight and Core Web Vitals walks through the fixes. SEO checks the on-page fundamentals that determine how the page is understood and ranked.
Two honest notes about scope. First, an automated scan, ours included, catches the machine-detectable portion of issues; it cannot judge whether a heading makes sense to a screen reader user or whether a business legally "sells" data, which remain human calls. Treat the scan as a fast, thorough floor and keep human review for the judgment questions, which is exactly why the server hands your agent guidance rather than pretending to certify anything. Second, the scan is single-page. That is a feature for mid-build checking, but if you need to audit an entire site with history and exports, that is what the dashboard is for, and the two share the same monthly quota.
Why does the authentication matter, and how does Sitejar handle it?
This deserves its own section because it is the part of MCP that most servers get wrong, and it directly affects whether you should trust a server with access to your account. The concern is not theoretical. Security researchers who scanned the public internet in 2025 found nearly two thousand MCP servers exposed with no authentication at all, meaning anyone could list their tools and potentially pull data through them, and the pattern repeated across a second large sample with over-permissioning and full exposure on local networks.
The MCP specification addressed this by adopting OAuth 2.1 as the required authorization framework for remote servers, with servers acting as OAuth resource servers that validate tokens rather than handling passwords. Sitejar implements this the way it is meant to be implemented. Sign-in happens on sitejar.app, in your browser, with your existing account and your existing multi-factor authentication. Your client never sees your password, and the server never sees it either; the client only ever receives a token. That token is opaque and revocable, so if a machine is lost or a session is compromised, access can be cut immediately from your account. The server uses PKCE, the proof-of-possession extension that OAuth 2.1 mandates for exactly this kind of public client, so an intercepted authorization code cannot be reused. And the server never forwards your token anywhere else and never triggers our own AI on your behalf, which closes two of the most common ways MCP integrations leak or overreach.
For an agency, this is the difference between a tool you can put in front of a client's codebase and one you cannot. For a developer, it means connecting Sitejar does not require creating and pasting an API key into a config file, which is the pattern that leaks keys into git history. You authorize once, in the browser, and the credential stays managed. If you ever want to sever access, revoking it from your account ends it for every connected client at once.
Troubleshooting: why is the Sitejar MCP server not working?
Almost every connection problem falls into a short list, and each has a specific fix.
The tools do not appear after adding the server. In nearly every case this is because the client only loads MCP servers at startup. Fully quit and restart Cursor or Windsurf, not just reload the window. In VS Code, confirm you are in Copilot Agent Mode, since tools do not appear in inline or standard chat, and use the Start action next to the server. In Codex, run /mcp to confirm the server is registered; if it is missing from the extension, refresh, restart, or use the CLI.
The connection fails silently in Windsurf with no error. This is the serverUrl versus url mistake. Windsurf requires serverUrl. Correct the field name in ~/.codeium/windsurf/mcp_config.json and restart.
Claude Desktop cannot find the server. You are probably editing claude_desktop_config.json, which only supports local stdio servers. Use Settings, then Connectors, then Add custom connector with the URL instead.
Sign-in does not open, or authorization fails. Make sure your client actually supports OAuth for remote servers; modern versions of Claude Code, Claude Desktop, Cursor, and Codex do. If you are on an older stdio-only client, route through the mcp-remote bridge, which handles the OAuth handshake for you. If a browser window opened but nothing happened afterward, complete the approval on sitejar.app and return to your client; some clients need a moment to receive the token.
The scan says it is still running. That is expected for a moment; scans take a little time. A well-prompted agent polls get_scan_result until completion. If your agent reported "running" and stopped, ask it explicitly to wait for the scan to finish and then read the result.
You hit a quota limit. The Free plan includes five single-page scans a month with no card required. When you reach it, your plan's monthly quota, the same one your dashboard scans use, lifts the limit. Upgrading your plan raises the ceiling.
codex mcp add --url is not recognized. Your Codex CLI is too old for streamable HTTP. Upgrade with npm install -g @openai/codex and try again.
You want the server in one project but not others. Use project-level configuration: .cursor/mcp.json inside the project for Cursor, .vscode/mcp.json for VS Code, or the project-scope option in Claude Code. Note that Windsurf is global-only.
If none of that resolves it, the underlying checks are available without connecting anything at all. You can run the security headers checker and the cookie consent checker directly in your browser, no account needed, which is also a useful way to sanity-check a finding your agent reported.
How does the MCP server compare to the dashboard and the API?
The three ways to use Sitejar are built for different moments, and picking the right one saves time. The MCP server is for checking one page while you are building it, inside your AI tool, with the agent that wrote the page applying the fixes. It is the fastest feedback loop and needs no context-switching. The dashboard is for auditing a whole site: it crawls many pages, keeps history, shows trends, and exports reports, which is what you want for a full compliance review, a client deliverable, or ongoing monitoring. The API, documented for developers at our developer documentation, is for wiring scans into your own pipeline, such as a CI step that fails a build on critical issues.
A sensible setup for a serious team uses all three. Developers connect the MCP server so every page gets checked during the build. The API runs in CI so nothing regresses on merge. And the dashboard gives the compliance owner, or the agency account manager, the whole-site view and the exportable proof. Because the MCP scans draw on the same quota as dashboard scans, you manage one allowance rather than three.
Why does fixing at the source matter, and how does the MCP server fit?
It is worth being explicit about the philosophy behind the fix guidance, because it explains why the server works the way it does. Sitejar fixes issues at the source and never uses overlays. An overlay is a script that tries to patch accessibility at runtime in the visitor's browser, on top of broken markup; it leaves the underlying code broken, frequently interferes with assistive technology, and has not protected sites from litigation, a case we lay out in full on our page explaining why fixing the source beats an overlay. The MCP server is the opposite approach made practical: it hands your agent precise, source-level guidance, and your agent changes the actual code, so the fix is real, durable, and visible to anyone who inspects the markup.
This is also why the server is a natural fit for AI-generated code specifically. Agents ship enormous volumes of markup fast, and the same small defect in a shared component gets duplicated everywhere it is used, a dynamic we examined in our piece on the accessibility debt piling up in AI-generated code. Checking each page with the MCP server as it is built, and fixing at the component level, is how you stop that debt from compounding. And when you are ready to describe your site's real state publicly, the honest findings from a scan are exactly what a defensible statement should be built on, which is what our accessibility statement generator turns into a publishable document.
Frequently asked questions
Which AI clients work with the Sitejar MCP server?
Any MCP client that supports remote Streamable HTTP, which today includes Claude Code, Claude Desktop, Cursor, VS Code with GitHub Copilot, Windsurf, and Codex, among others. Clients that only support local stdio servers connect through the mcp-remote bridge, using the "Other (stdio bridge)" configuration in this guide.
Do I need an API key to connect?
No. Authentication is OAuth 2.1 through your browser, using your existing Sitejar account and MFA. There is no key to generate or paste into a config file, which also means no key can leak into your repository.
Is the Sitejar MCP server free?
Every plan, including Free, includes MCP access. The Free plan provides five single-page scans a month with no card required. Beyond that, your plan's monthly quota, shared with your dashboard scans, applies.
Can it scan my whole website?
The MCP server scans one page at a time by design, which is ideal for checking a page mid-build. For a full-site crawl with history and exports, use the Sitejar dashboard, which shares the same quota.
Does the server use AI, or spend my AI credits?
It never triggers Sitejar's own AI and never spends AI budget on our side. It returns deterministic, source-level fix guidance, and your own model, whichever one you are running, does the writing. Your usage of your AI tool is governed by that tool's own plan.
Where does my data go when I scan?
The server scans the URL you provide and returns the findings to your agent. It does not forward your token anywhere and does not run our AI fix engine on your content.
Why do the tools not show up after I add the server?
Most clients only load MCP servers at startup, so fully quit and restart the application. In VS Code, tools appear only in Copilot Agent Mode. In Windsurf, confirm you used serverUrl rather than url. In Claude Desktop, use the Connectors settings rather than the config file.
How is the MCP server different from a dashboard scan?
The MCP server checks a single page inside your AI tool, with the agent applying fixes, for a fast build-time loop. The dashboard crawls an entire site with history and exports for full audits and ongoing monitoring. They share one quota.
Can I use it in CI or automation?
For pipeline automation, use the API rather than the MCP server, since the API is built for programmatic calls such as failing a build on critical issues. The MCP server is optimized for interactive agent sessions.
Is it safe to connect a compliance scanner to my AI agent?
Sitejar was built by a compliance company, so the authentication is designed to be in the small share of MCP servers that get authorization right: OAuth 2.1 with PKCE, opaque revocable tokens, no password ever seen by the client or server, no token forwarding, and immediate revocation from your account.
The bottom line
The Sitejar MCP server puts a six-dimension compliance check directly inside the AI tool you already build with, so the page your agent just created gets scanned for accessibility, security, privacy, deceptive design, quality, and SEO before it ships, and fixed by that same agent from source-level guidance. Connecting takes one line: the remote endpoint is https://mcp.sitejar.app/mcp everywhere, and the only client-specific details are where each tool keeps its configuration and, in Windsurf's case, that it wants serverUrl instead of url. Sign in once through your normal account with MFA, then describe what you want in plain language and let the agent chain the five tools. Use it for the fast, per-page loop during a build, pair it with the dashboard for whole-site audits and the API for CI, and remember that an automated scan is a thorough floor rather than a certificate, so keep human judgment for the questions only a person can answer. Every plan, including Free, includes access, so the fastest way to see whether it fits your workflow is to add the line, scan the page you are working on right now, and watch your agent fix what it finds.
Sources
Model Context Protocol, Architecture Overview (official documentation)
Google Cloud, What is Model Context Protocol (MCP)?
Descope, Diving Into the MCP Authorization Specification
This guide is educational and reflects Sitejar's point of view. It is not legal advice. For your specific situation, consult a qualified professional.