# MCP Server > Canonical HTML version: https://rocketvalidator.com/docs/mcp > Attribution: Rocket Validator (https://rocketvalidator.com) > License: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) 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](https://rocketvalidator.com/pricing) 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. ### 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: ```sh 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: ```sh 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: ```sh 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](https://code.claude.com/docs/en/mcp). #### 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**. ![Claude Setttings for new MCP connector. Form with "name" and "url" inputs](https://rocketvalidator.com/images/docs/mcp/setup-claude-01.png) 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: ```sh codex mcp add rocket-validator --url https://rocketvalidator.com/mcp/server ``` Then sign in: ```sh 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: ```sh codex mcp list ``` For additional options, see the [official OpenAI Codex MCP documentation](https://learn.chatgpt.com/docs/extend/mcp). #### 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. ![Codex Setttings for new MCP connector. Form with "name", "type" and "url" inputs](https://rocketvalidator.com/images/docs/mcp/setup-codex-01.png) 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: ```sh 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: ```sh opencode mcp auth rocket-validator ``` Check that OpenCode can see the server: ```sh 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`: ```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](https://opencode.ai/v2/docs/mcp-servers/) 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](https://rocketvalidator.com/claude_mcp). ## 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. | Tool | What it does | Main actions | |------|--------------|--------------| | `reports` | Query and create site validation reports | `list`, `get`, `create` (write) | | `web_pages` | Browse and re-check pages inside a report | `list`, `get`, `recheck` (write) | | `common_w3c_validator_issues` | HTML issues aggregated across a whole report | `list`, `get`, `web_pages` | | `common_axe_issues` | Axe accessibility issues aggregated across a whole report | `list`, `get`, `web_pages` | | `common_axe_manual_reviews` | Axe checks needing manual review, aggregated across a report | `list`, `get`, `web_pages` | | `common_accesslint_issues` | AccessLint issues aggregated across a whole report | `list`, `get`, `web_pages` | | `w3c_validator_issues` | HTML errors/warnings on a single page | `list`, `get` | | `axe_issues` | Axe accessibility violations on a single page | `list`, `get` | | `axe_manual_reviews` | Axe checks needing manual review on a single page | `list`, `get` | | `accesslint_issues` | AccessLint issues on a single page | `list`, `get` | | `w3c_validator_guides` | W3C HTML validation guides (why it matters, how to fix it) | `list`, `search`, `get` | | `axe_guides` | Axe Core accessibility guides and WCAG references | `list`, `search`, `get` | | `accesslint_guides` | AccessLint Core guides, keyed by rule ID | `list`, `search`, `get` | | `schedules` | Scheduled reports and the reports they generated | `list`, `get`, `list_reports`, `create` (write) | | `mutings` | Rules that suppress known issues | `list`, `get`, `report`, `create` (write) | | `devices` | Viewport / user-agent configurations for validation | `list`, `get` | | `info` | Rocket Validator engines, plans and pricing | query | ### 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](https://rocketvalidator.com/html-validation), [Axe accessibility validation](https://rocketvalidator.com/accessibility-validation/axe) and [AccessLint validation](https://rocketvalidator.com/accessibility-validation/accesslint). * `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](https://rocketvalidator.com/docs/scheduling): 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](https://rocketvalidator.com/docs/muting), 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](https://rocketvalidator.com/docs/device-viewport-emulation) (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](https://rocketvalidator.com/docs/api/index). * 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](https://rocketvalidator.com/mcp#faq), verify your Rocket Validator subscription is active, and try removing and re-adding the connector to start a fresh authorization.