Claude and other AI assistants

Inclusify runs an MCP server, so an AI assistant can read your scans and run accessibility checks against your own pages while you talk to it. Ask whether your checkout works with a keyboard, or what a screen reader makes of a product page, and get an answer about your site rather than a general explanation of WCAG.

What you can ask

  • “Where do we stand on example.com, and is anything stopping the scans from running?”
  • “Is the checkout on example.com usable with a keyboard only?”
  • “Read me the product page the way a screen reader would, and tell me what is confusing.”
  • “What breaks on our homepage at 400% zoom?”
  • “Which images on example.com have alt text that says nothing, and what should they say?”
  • “Give me the fix list for example.com, and tell me which of our templates to search for each one.”
  • “Here is the markup I am about to deploy for that contrast failure. Does it actually fix it?”
  • “Has the score on our category page moved since last month, and which scan did it move on?”

Before you start

  • The website has to be in your Inclusify account. The assistant can only see websites in the workspace you sign in with, and every request names one.
  • Every tool needs the website it asks about to be on the Pro plan or above, and the three account-wide tools need Enterprise. Connecting works on any plan, and a call against a site that is not on Pro comes back saying which plan it needs rather than failing. One account can hold sites on different plans, so the same tool can work for one website and not another.
  • There is no API key to create or paste. You sign in with Inclusify once, in the browser, and the assistant holds the authorization from then on.

Claude

1

Open your connector settings

In Claude, go to Settings, then Connectors, and choose to add a custom connector.

2

Paste the server URL

BASH
https://app.inclusifyapp.com/api/mcp/customer
3

Approve the sign-in

A window opens asking you to sign in to Inclusify and approve access. After that the tools appear in your assistant and you can start asking.

Claude Code

Run this in your project, then approve the sign-in in the browser window it opens.

BASH
claude mcp add --transport http inclusify https://app.inclusifyapp.com/api/mcp/customer

Other MCP clients

Any client that speaks MCP over HTTP with OAuth works. Point it at the same URL and it discovers where to sign in on its own — nothing to register by hand. The server is stateless and holds no session, so a client may reconnect whenever it likes.

BASH
https://app.inclusifyapp.com/api/mcp/customer

What the assistant can do

22 tools: 19 answer about one website, and 3 answer across every website in the account. Twenty read only; the two that write are named as such below. You do not pick between them. Ask the question and the assistant chooses.

Understand where you stand

Broad questions, answered from what is already on record. None of these loads a page.

The whole current position for one website site_overview

Plan, the headline score and when it was measured, how many pages are checked automatically against how many the plan includes, this month's visitor count against the allowance, whether an accessibility statement is published, whether the widget is switched on, and whether anything is currently stopping scans from running. It reports counts, never individual issues, so start here and then ask for detail. A site that has never been scanned comes back with no score rather than a good one.

The evidence Inclusify holds for a website compliance_status

The accessibility statement — which of the three shapes it is, what compliance status it claims and who attested to it, the standards it names, how the site was assessed, the non-accessible content it lists in its three separate categories, when it was last reviewed and whether that is overdue, where it is published, and the contact details on it — plus the scanning record behind it and an explicit list of the gaps in that record. It answers “what could we show if we were asked”. It reports what is on record and what is missing, and it does not tell you whether a site is legally compliant.

Recorded use of the accessibility widget widget_usage

How many times each widget feature was switched on over a window of days, on how many separate days, and this month's visitor count for context. A zero is reported together with its cause, which matters here: the widget build currently served to sites reports visitors only and does not report which features were switched on, so on most sites a zero means the measurement does not exist rather than that visitors were offered the tools and declined them.

The score day by day score_history

One point per day from the scheduled monitoring scans, with the direction of travel and the change across the window worked out. Pass a URL to follow a single page instead of the site. Full-site crawls are left out, because a crawl is a dated snapshot rather than a series. It knows nothing newer than the last monitoring scan, so it cannot confirm a fix you deployed minutes ago.

Find and fix

The fix loop. Reading findings and checking your markup both cost no browser run, so iterating here is cheap.

The fix list for a website, with what to search for list_violations

One entry per rule rather than per page, worst impact first, each with the impact, the rule id, the WCAG criterion, the help text and its documentation, the failing HTML from one named example page, the computed foreground, background and ratio for a contrast failure, and every page the rule fails on. Each entry also carries the strings taken from the failing elements across all those pages (ids, distinctive classes, visible text, image filenames) that are likely to appear verbatim in your own source, so the assistant can find the template. CSS selectors describe the rendered page and will not appear in any source file.

Check a fix before you deploy it validate_fix

Send the markup you are about to ship, with the rule it targets, and get back resolved, not resolved, masked, or not decidable from markup. “masked” is the answer worth having: deleting the element, adding aria-hidden, hiding it with display:none, dropping the visible text or turning a button into a div all make a scanner go quiet while leaving the barrier in place. It reads markup only, so anything that depends on how the page renders (contrast, focus indicators, forced colours, reduced motion, tap-target size, reflow at zoom, keyboard traps and reading order) comes back not decidable from markup and names the tool that can answer it.

One page's scans over time page_history

Every recorded monitoring scan of a single URL, newest first: score, violations by impact, and how many issue types were fixed and newly introduced since that page's previous scan. This is the tool for “did my fix work” and “when did this page break”, because it names the scan where the score fell. Counts are rule-level, so fixing forty instances of one rule reads as one fixed issue type.

The alt-text findings already on record list_alt_findings

Images with missing, filename-like, vague or inaccurate alt text from the most recent scan, each with the element, the current value, why it was flagged, a suggested replacement and a confidence score.

Unclear wording and structure in your own content list_content_findings

Problems in the text of a Shopify store's own content, meaning product descriptions, pages, articles and collections: link text that does not say where it goes, controls with no label, headings that do not describe what follows, and tables used for layout. Each finding carries the item it is in, the current text, why it was flagged, a suggested replacement where there is one, and an admin link to the exact place to edit. Only Shopify-connected stores have this data, and an empty result says whether a content review has ever run, because “never reviewed” and “reviewed and clean” are different answers.

Check a live page

These load the page in a real browser, so they see the current state of the site and count against the check allowance below.

What a screen reader announces, in order screen_reader_transcript

The linear reading order, plus the headings, landmarks, links and form-control lists a screen-reader user actually navigates by. Also reports structural problems: reading order that contradicts the visual order, controls whose accessible name does not match their visible label, unlabelled graphics and repeated link names. It is a model of screen-reader output derived from the browser's accessibility tree, not NVDA or VoiceOver output.

Tab through a page and report what breaks keyboard_walk

Focus traps, focus that disappears, missing focus indicators, focus hidden behind sticky headers, tab order that disagrees with the visual or DOM order, interactive elements no keyboard can reach, and custom controls that ignore Enter and Space. Focus indicators are judged by comparing rendered pixels rather than CSS, because an indicator can come from an outline, a shadow, a border or a background. Pierces shadow roots.

Render under a disabling condition simulate_condition

Windows High Contrast (forced colours), 400% zoom at a 320px viewport, reduced motion and phone-sized tap targets. Reports computed failures, such as elements that vanish, text that overflows and animation that keeps running, rather than screenshots to interpret. A condition that could not be applied is reported as skipped rather than passing quietly.

Check the alt text on a page check_page_alt_text

A missing alt attribute (not the same as an empty one), a filename used as alt, a redundant “image of” opener, alt too long to hear in one breath, alt that merely repeats the caption, and an image that is the only content of a link and leaves it with no name. Images correctly marked decorative are counted and deliberately not reported. It can draft replacement text for the images that have none, which is off unless you ask for it because it costs a vision call per image against the site's AI budget.

Collect a check that was still running get_job

Browser-driven checks run on a worker. If one is still going when the call returns, it hands back a job id to collect the result with. Collecting a result costs nothing, because the check itself was already counted.

Coverage

How much of the site is actually being looked at, which is what an empty finding list usually turns out to mean.

The most recent full-site crawl crawl_summary

Status, the URL it started from, how many pages it found against how many it scanned, the average score, totals by impact, when it ran, and the worst-scoring pages. Read found against scanned before quoting the average: a crawl audits at most the plan's page allowance, so on a large site the average describes a sample and the tool says so. It returns the most recent crawl whatever its state, including a failed or still-running one, so the numbers can be partial.

Which pages are watched, and whether watching is working list_monitored_pages

The URLs under monitoring, which are paused, when each was last scanned, its last score, and which are failing, unreachable, throttled or overdue. Worth calling before trusting an empty score history: a page that fails every night, or a storefront behind a password, produces no data and reads exactly like a site with nothing wrong. Also reports how many of the plan's audited-page slots are in use.

Widen what is being checked

The only two tools that write, and both only add. They change your Inclusify settings, never your website, and neither removes, pauses or edits anything.

Put more pages on the daily rotation add_monitored_pages

Adds URLs to the set of pages scanned automatically, up to 20 in one call and all on your own domains. A page already on the list is reported back as such rather than added twice or treated as an error. It is all or nothing against the plan's page allowance: if the batch would not fit, nothing is added and the answer says what would. New pages are picked up by the scan queue rather than instantly, so for an answer now, use a crawl or one of the live checks. It never removes or pauses a page, which stays a decision a person makes in the panel.

Queue a full-site crawl start_crawl

Discovers pages from the website's own domain and audits up to the plan's page allowance. It returns straight away with a job id rather than waiting, so the assistant can carry on and collect the outcome later with crawl_summary, then read the findings with list_violations. Safe to ask for twice: if a crawl is already running it hands back the running one instead of starting a second. Asking for more pages than the plan allows is capped, and the answer says it was capped.

In a build pipeline

One call, one verdict, for CI. Enterprise plan.

Pass or fail a build on accessibility ci_gate

Turns the last recorded scan into a single pass or fail against your thresholds: a minimum score, a maximum number of critical issues, a maximum number of serious ones, in any combination. With none given it uses a minimum score of 80 and says so. A failure comes back as an ordinary answer rather than an error, so a pipeline reads the verdict instead of retrying. A website with no scan on record fails, because unmeasured is not the same as passing, and every verdict says how many pages the scan it judged actually covered. It reads the record only: nothing is scanned by asking.

Across every site in the account

No website argument, because these answer for the whole organisation. Enterprise plan.

Every website in the account list_websites

Each site with its plan, its last recorded score and when that scan ran. This is how the assistant finds out which domains exist before asking about one of them.

Scores and finding counts across the account org_rollup

The last recorded score for every website, the average across the ones that have been scanned, open violations by impact, which sites have never been scanned, and the worst sites first. One call instead of one per site.

The worst findings across every website org_findings

Findings from the last recorded scan of every website, worst impact first and grouped by the pattern behind them, so one template fault across forty pages reads as one problem rather than forty. For deciding what to fix once and have fixed everywhere.

Allowances

Two limits per website, both visible in the panel under Integrations.

  • Checks run today. Every check that loads a page counts, including repeats of the same page. Reads of findings already on record have their own, much larger, daily ceiling.
  • Pages checked this month. How many different pages an assistant may check, equal in size to the plan’s audited-page allowance and separate from it: a check here never uses up a monitoring slot. Re-checking a page already counted this month is free and unlimited, so verifying a fix always works even at the limit.

A page is counted once however you write its URL: a trailing slash, a fragment, a tracking parameter and a differently-cased host are all the same page. When a limit is reached the tool says so in plain words and names the website; it is a final answer for the period rather than an error to retry.

What it cannot do

Nothing here touches your website. No tool changes your pages, your product catalogue, your widget settings or your billing, and none can reach a website outside the workspace you signed in with. Alt text and rewritten copy the assistant drafts come back to you as suggestions; nothing is written to your store. Markup you send for checking is read and answered on, not deployed.

Twenty of the 22 tools only read. The two exceptions write to your Inclusify settings and are add-only: add_monitored_pages adds pages to the monitoring rotation and start_crawl queues a crawl. Neither removes, pauses or edits anything, and removing a monitored page stays in the panel where a person has to do it.

Two limits worth knowing about before you rely on an answer:

  • Checking a fix reads markup only. Anything that depends on how the page renders comes back as not decidable from markup, naming the live check that can answer it, so contrast, focus, forced colours, reduced motion, tap-target size, reflow at zoom, keyboard traps and reading order still need the page loaded after you deploy.
  • Widget usage cannot report which features visitors switched on. The widget build currently served to sites reports visitors only, so a zero there is a missing measurement and not evidence that the tools went unused.

Nothing here states that a website is compliant or certified. The tools report what is on record and what is missing from it, which is the input to that judgement rather than the judgement.

Next