MCP Server

Rocket Validator's MCP server lets a compatible AI client work with your validation data: reports, pages, issues, guides, schedules, mutings and devices. Connect it once, then ask your AI client questions in plain language.

What is MCP?

MCP (Model Context Protocol) is a standard that lets AI clients use tools from external services. When you connect Rocket Validator, your client can use its tools to look up the validation data your account can already access.

What can I ask?

Once connected, try questions such as:

• "Which report from the last week has the most serious issues?"
• "What is the highest-impact accessibility issue in my latest report? Show the affected pages and explain how to fix it."
• "Create a 50-page report for example.com with Axe and AccessLint checks."
• "Is example.com improving? Are there less issues over time?"
• "Which one of our managed websites needs more attention?"

Before you connect

You need a Rocket Validator subscription with MCP access. See the pricing page for current plans, and use an MCP client that supports Streamable HTTP, such as Claude, Codex or OpenCode.

Use this server endpoint in your client:

https://rocketvalidator.com/mcp/server

Your client opens a browser when it is time to connect. Sign in to Rocket Validator there and approve the access you want to grant.

Connect your AI client

Rocket Validator works with the major AI clients. Pick yours for setup instructions.

• Set up Claude
• Set up ChatGPT / Codex
• Set up OpenCode

Claude

You can connect the Rocket Validator MCP Server to Claude from the command line or from the desktop application.

Claude command line

Add Rocket Validator as a remote MCP server:

claude mcp add --transport http rocket-validator https://rocketvalidator.com/mcp/server

This adds the server to the current project. Add --scope user to make it available in all your projects.

Then sign in:

claude mcp login rocket-validator

When the browser opens, review the permissions and authorize access to your Rocket Validator account.

Check that Claude can see the server:

claude mcp list

In Claude Code you can also run /mcp to check the connection or sign in.

For additional options, see the official Claude Code MCP documentation.

Claude desktop application

1. In Claude, open Settings → Customize → Connectors.
2. Select Add custom connector.
3. Enter Rocket Validator as the name and https://rocketvalidator.com/mcp/server as the server URL, and click on Continue.

4. In the next screen, leave the Authentication option as "Sign in now", and OAuth client as "Register automatically". Click Add at the bottom.
5. The final screen will show the available tools, when you're done reviewing the permissions you can close this window and start a conversation.

ChatGPT / Codex

You can connect the Rocket Validator MCP Server to Codex from the command line or from the desktop application.

Codex command line

Add Rocket Validator as a remote MCP server:

codex mcp add rocket-validator --url https://rocketvalidator.com/mcp/server

Then sign in:

codex mcp login rocket-validator

When the browser opens, review the permissions and authorize access to your Rocket Validator account.

Check that Codex can see the server:

codex mcp list

For additional options, see the official OpenAI Codex MCP documentation.

ChatGPT / Codex desktop application

In the ChatGPT / Codex app, open Settings → Plugins → Add MCP Server. Enter Rocket Validator as the name, Streamable HTTP as the type, and https://rocketvalidator.com/mcp/server as the URL, then save it.

On the next screen, click on Authenticate and complete the browser sign-in flow.

OpenCode

You can connect the Rocket Validator MCP Server to OpenCode from the command line or by editing the configuration file.

OpenCode command line

Add Rocket Validator as a remote MCP server:

opencode mcp add rocket-validator --url https://rocketvalidator.com/mcp/server

This adds the server to the current project. Add --global to make it available in all your projects.

Then authenticate in your browser:

opencode mcp auth rocket-validator

Check that OpenCode can see the server:

opencode mcp list

OpenCode configuration

If you manage OpenCode with configuration files instead of the command line, add this server to your global or project opencode.json:

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "servers": {
      "rocket-validator": {
        "type": "remote",
        "url": "https://rocketvalidator.com/mcp/server"
      }
    }
  }
}

Then run opencode mcp auth rocket-validator to sign in.

See the OpenCode MCP documentation for more options.

Manage access

Choose the access scope when your client asks you to approve the connection:

• mcp:read (default): list and inspect reports, pages, issues, guides, schedules, mutings and devices.
• mcp:write: everything in mcp:read, plus create validation reports and schedules, re-check pages after fixing them, and create muting rules.

Start with read-only access unless you want your client to create or change something. Use your client's mcp list command to confirm that the server is connected. You can revoke a connection at any time from Connected apps.

Available tools

The server exposes 17 tools. Every tool takes an action parameter (list, get, search, create, ...) plus filters, sorting and pagination. List actions default to 25 results per page (max 100) with page and page_size parameters.

Reports

List, filter, search and create validation reports. Find reports by URL, tag, date or issue count.

• list: filter by url (partial match), tag, and created_by (all, me, guests — the latter requires Guest Accounts). Sort by url, num_web_pages, w3c_validator_issues, w3c_validator_errors, w3c_validator_warnings, axe_issues, axe_errors, axe_warnings, accesslint_issues, accesslint_errors, accesslint_warnings, manual_reviews or last_checked_at. Reports without checked pages sort last on issue-count sorts.
• get: retrieve a single report by its ID.
• create (requires mcp:write): start a new report from a starting_url, with options like max_pages, deep_crawl, dynamic_crawler, tags, exclusions, rate_limit, device_id, perform_w3c_validator_checks, perform_axe_checks, perform_accesslint_checks, store_raw_w3c_validator_checks, store_raw_axe_checks, store_raw_accesslint_checks, store_incomplete_checks and store_screenshot. Ask the user which engines they want before creating: only W3C Validator checks run by default. Only publicly accessible sites can be validated through MCP; sites behind login or basic auth must be validated from the web UI.

Example prompts: "Show me all reports from the last week", "Which reports have the most accessibility errors?", "Create a new report for https://example.com with 50 pages and AccessLint checks".

Web pages

Browse and inspect individual pages inside a report, and re-check them after fixing issues.

• list: filter by url, w3c_validator_issue_id, axe_issue_id, accesslint_issue_id or axe_manual_review_id (an Axe rule ID; only for reports created with manual review enabled). Sort by url, w3c_validator_issues, axe_issues, accesslint_issues or date.
• get: full detail of one page.
• recheck (requires mcp:write): re-validate one or more pages by ID. Consumes credits like a manual re-check.

Example prompts: "Show me the pages with the most HTML errors in my latest report", "Recheck the pricing page".

Common issues (aggregated per report)

Aggregated views showing which problems affect the most pages, so you can prioritize fixes with the biggest impact. There is one tool per engine, plus one for Axe manual reviews:

• common_w3c_validator_issues: filter by message or tag (for example error).
• common_axe_issues: filter by help or WCAG tag (for example wcag2aa).
• common_accesslint_issues: filter by message or rule ID, impact (critical, serious, moderate, minor), sorted by impact or count.
• common_axe_manual_reviews: aggregated Axe incomplete checks that need a person to review them. Only collected for reports created with manual review enabled.

Each tool supports get (detail of one aggregated issue by its sample ID) and web_pages (pages affected by it).

Example prompts: "What's the most common HTML error across all pages?", "Which WCAG 2.1 Level AA violations affect the most pages?", "Which critical AccessLint issues affect the most pages?"

Page-level issues

Issue-level detail on a single page: exact code snippets, line numbers, severity, affected elements and tags. Needs both report_id and web_page_id.

• w3c_validator_issues: markup and inline CSS errors/warnings. Filter by message or tag.
• axe_issues: Axe Core violations with severity (critical, serious, moderate, minor). Filter by help or WCAG tag.
• accesslint_issues: AccessLint Core violations grouped by exact message. Filter by message or rule ID, or by impact.
• axe_manual_reviews: Axe incomplete checks on the page — findings the engine could not decide on its own. Only available for reports created with manual review enabled.

Note that Axe and AccessLint count different things: Axe splits findings into definite violations (axe_issues) and needs-review items (axe_manual_reviews), while every AccessLint check is reported as an issue. A report can therefore show fewer Axe issues than AccessLint issues while also carrying a large manual-review count.

Example prompts: "Show me all critical accessibility issues on the checkout page", "List all color contrast issues on the homepage", "What needs manual review on the pricing page?"

Guides

Searchable knowledge base with explanations, why each issue matters, and step-by-step fixing guidance. These are the same guides published at HTML validation, Axe accessibility validation and AccessLint validation.

• w3c_validator_guides: list (optionally filtered by tag), search by keywords, get by slug.
• axe_guides: list (optionally filtered by tag or ruleset), search by keywords, get by slug.
• accesslint_guides: list (filtered by category, WCAG criterion, level, fixability or tag), search by keywords, get by rule ID (for example distinguishable/color-contrast). The rule_id reported on an AccessLint issue is exactly the key the get action takes, so you can go straight from an issue to its fixing guide.

Example prompts: "Explain what duplicate ID means and how to fix it", "Explain the landmark-one-main accessibility rule", "How do I fix distinguishable/color-contrast?"

Schedules

Manage your scheduled reports: configuration, last run, and the reports each schedule generated via list_reports.

• list, get and list_reports work with read access.
• create (requires mcp:write): starting_url is the only required parameter. It accepts the same crawl and check options as reports create, plus the cadence: every (day, week, month or deploy), weekday, monthday, months and active. Ask the user which engines they want: W3C Validator checks are on by default; Axe Core, AccessLint Core and manual review are off.

Example prompts: "Show me all my scheduled reports", "When did my production schedule last run?", "Create a weekly schedule for https://example.com with Axe and AccessLint checks".

Mutings

View muting rules, see which ones apply to a report, and create new ones.

• list, get, report (mutings active in a given report) work with read access.
• create (requires mcp:write): needs a url_match (min. 5 characters) and a message pattern (min. 3 characters); be as specific as possible and add a comment explaining why.

Example prompts: "Show me all my muting rules", "Create a muting rule for legacy pages with heading-order issues".

Devices

Read-only list of viewport configurations (desktop, mobile, tablet) usable when creating reports. Use the device_id from a report to look up the device it was validated with.

Example prompts: "Show me all available mobile devices", "What device was used for this report?"

Info

General information: validation engines (W3C Validator Nu for HTML, Axe Core and AccessLint Core for accessibility, plus the dynamic crawler), current volume plans (1K, 5K, 10K and 50K, each weekly, monthly or yearly) and legacy plans, plan attributes and limits, and how combining plans stacks credits and guest accounts.

Example prompts: "What validation engines does Rocket Validator use?", "What's included in the 10K Monthly plan?"

Typical workflows

• Weekly review: "Show me how our accessibility scores changed across all client sites this week. Which sites improved the most?"
• Prioritization: "What's the most urgent issue on our site? Show me affected pages, example code and how to fix it."
• Quick wins: "What's the simplest HTML issue to fix? Give me a detailed guide for our junior developer."
• Competitive check: "Run accessibility reports on our top 3 competitors and compare them to our site."
• Responsive QA: "Create two reports for our site, one with desktop and one with iPhone, and compare the accessibility differences."
• Verify a fix: "Recheck the homepage now that I've fixed those alt text issues."

Notes and limits

• Report creation via MCP only supports publicly accessible sites. For staging behind authentication, create the report in the web UI and then explore it through your MCP client.
• Creating reports and re-checking pages consumes credits exactly like the equivalent actions in the web UI or the JSON API.
• Manual-review checks are only collected for reports and schedules created with manual review enabled (store_incomplete_checks); older reports predate the feature and report no manual reviews.
• If you work with a team, use the created_by filter on reports (all, me, guests) to switch between your own reports and guest reports.
• Having trouble? Check the FAQs on the MCP landing page, verify your Rocket Validator subscription is active, and try removing and re-adding the connector to start a fresh authorization.