AI assistants and MCP

An ordered, ranked list of concrete next actions, each naming the tool or panel page that does it, why it sits where it does, and whether anything below it is blocked until it is done. The order is by what BLOCKS, not by impact: a widget that has never reported in outranks a failed payment, which outranks a blocked or failed scan, which outranks reading findings, which outranks upgrading a plan. A step that needs a higher plan is listed with the plan named rather than dropped, so the list never quietly turns into a description of the current plan. It performs none of the steps itself — nothing is scanned, changed or installed — and it names no individual violation; list_violations and the other finding tools own those. Composed from site_overview, so it costs about what that call costs.

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.

Two facts that are commonly mistaken for one, kept separate: whether widget serving is enabled in the Inclusify account — a switch that defaults to on for every account before anything has been pasted, and proves nothing by itself — and whether anything has EVER actually arrived from the site, which is the only real evidence that the embed is there. When nothing has ever reported in, it returns the exact script tag to paste before the closing </body> tag, or, on a Shopify store, explains that the widget is a theme app embed switched on from Online Store > Themes > Customize > App embeds in the Shopify admin, a step no assistant can do. It does not fetch or check the site itself, so a just-installed embed nobody has visited yet looks identical to one that was never added.

Every plan's price, monthly visitor allowance, audited-page allowance and feature list, read live from Inclusify's own configuration rather than recalled — so an assistant is never left guessing a number about somebody's bill — alongside where the current plan's allowances actually stand today. "Should we upgrade" is not answerable from a price list alone: a site using a fraction of what it already pays for usually should not, and that comparison is in the answer rather than left for the reader to work out. Respects who owns billing: an invoice-managed website has no self-serve upgrade at all, and this says so instead of handing over a link that would not work for it. It changes nothing and returns no URL — billing_link is the tool that hands over the link.

The correct billing page for this website's billing owner: Shopify's managed-pricing page inside the merchant's own Shopify admin for a Shopify-billed store, the website's page in the Inclusify panel for one billed through Inclusify directly, or, for an invoice-managed website, no link at all and who to email instead. This composes a URL from data already on hand and never calls the checkout endpoint itself — nothing here creates a checkout session, touches a card or changes a plan. Completing a change needs a human, signed in, in their own browser, and the response says so rather than implying the upgrade has been arranged.

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. At most three crawls per website can be started in a day.

Sets whether the widget bundle served to this site renders the widget or does nothing, purging the edge cache as part of the change so it takes effect within about a minute. The two directions are not treated the same. Turning it ON is immediate and needs no confirmation — the worst case is a widget on a site that did not want one, visible at once and one click to switch off. Turning it OFF removes a live accessibility feature from that site's real visitors, so it REQUIRES CONFIRMATION: call once without "confirm" to get a preview and a single-use token, show the preview to the user, and only call again with that token once they have agreed. On top of the confirmation, the account owner is emailed a record of the change with a link to revert it — so somebody with account access cannot switch it off unnoticed by whoever owns the account. Idempotent: asking for the state it is already in writes nothing, purges no cache and sends no email. Never touches the site's code or theme — on a Shopify store, turning this off does not remove the app embed, it only stops the embed from having anything to render.

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.

Adds a domain as a website in the account on the free plan, and starts nothing: no scan runs, no widget is installed, nothing is charged and no plan changes. Unlike every other tool here it takes no "website" argument, because the point is that the website does not exist in Inclusify yet. REQUIRES CONFIRMATION — call once without "confirm" to see the exact domain that would be registered, then call again with the token once that is confirmed — because a domain can belong to one Inclusify account only, and claiming it takes it from anyone else who might. Idempotent: a domain already in the account comes back as a no-op, not a second website and not an error. Refuses rather than guessing when the account holds more than one workspace, since a website lands in exactly one of them and picking wrong hides it from whoever added it. Capped at 50 websites added this way per account; the Inclusify panel has no such limit.

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.