AI assistants and MCP

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 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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.