AI and agents

Drive Inclusify from any assistant

Three steps, four endpoints, every one of them a plain HTTP GET. No connector, no OAuth, no install, no form. Claude's web fetch, ChatGPT browsing and Gemini browsing can all make these today, which means an assistant can take somebody from "which accessibility tool should I use" to a live account without them touching a browser.

GET https://inclusifyapp.com/api/agent/scan?domain=&email=      → starts the scan, emails the report
GET https://inclusifyapp.com/api/public/scan?domain=            → poll until "status" is "scanned"
GET https://inclusifyapp.com/api/agent/register?domain=&email=  → creates the account, emails the credential
GET https://inclusifyapp.com/api/agent/login?email=             → an account that exists, a fresh credential

The last two lines are two calls each rather than one. The first emails a 6-digit code and creates nothing at all: no account, no domain claim. Only the second, carrying that code back, does anything. The domain can be left out of both calls to register, for somebody who wants an account before they have a site to put in it, and login takes no domain at all: signing in is about the account, and it creates nothing at any point. Register refuses an address that already has an account, login refuses one that does not, and each names the other, so guessing wrong costs a round trip rather than anybody's data.

The scan report and the account credentials are emailed, never returned in a response body. That is the consent anchor: an assistant acting on somebody else's behalf cannot end up holding a secret, and a link previewer that trips one of these URLs achieves nothing but one email to an address it does not control.

Full reference, including what each endpoint refuses and why: Agent API. Machine-readable summary for an assistant to read directly: llms.txt.

Connect an MCP client

If the user already runs an MCP client, Inclusify is a remote MCP server with the full tool set: stored findings, live keyboard and screen-reader checks, fix validation before you deploy, and a pass or fail gate for CI.

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

Sign-in is OAuth in the browser, and CI uses a service credential instead so a pipeline does not break the day somebody's session lapses. The same tools are reachable over plain HTTP if a connector is not an option:

curl "https://app.inclusifyapp.com/api/v1/site_overview?website=example.com" \
  -H "Authorization: Bearer inc_mcp_..."

Setup for Claude, Claude Code, Cursor, Codex, VS Code, Devin Desktop and Antigravity, plus what every tool does: AI assistants and MCP.

Ask in Slack

The Slack app answers questions about your own sites in the channel. Some answers come straight from stored scans and cost nothing; others load the page in a real browser to answer the things a stored scan cannot, like whether a keyboard can get through your checkout.

It also posts monitoring alerts, so a regression turns up where the team already is rather than in an inbox nobody reads. Slack setup.

AI inside the product

No agent required for any of these. They run as part of a scan and show up in the panel. All four need the PRO plan: the AI pass over a scan is what PRO buys, and a site below it is scanned without one.

• Alt text suggestions. Images with missing or meaningless alt text get a proposed description written from what is actually in the image and the page around it. On Shopify this runs across the product catalogue too, and a merchant who approves a suggestion there can have it written back into the catalogue.
• Content clarity. A score for whether the writing on a page can be understood, which is a WCAG concern no rule scanner tests: headings that do not describe their section, link text that says nothing out of context, and prose that is harder than it needs to be. How it is scored.
• Fix suggestions on findings. A finding comes with a proposed change rather than only a rule name, and the occurrences are collapsed into causes so the estimate is honest. Four hundred contrast failures are usually one colour token.
• Findings into Jira. Export findings as issues so the work lands in the tracker your team already plans in, which is also where an autonomous coding agent will pick it up.

If you already run axe or pa11y

Keep running them. For a quick look at one page they are the right tool, and we use axe-core ourselves, so the rule violations you get back are broadly the same ones.

What a local run structurally cannot produce:

• The checks that need a driven browser rather than a rule pass: whether the keyboard reaches everything and gets back out, what order a screen reader reads in, what survives Windows High Contrast, what reflows at 400% zoom. This is where real complaints come from, and no static scan sees it.
• Occurrences collapsed into causes, so the estimate is edits and not symptoms.
• The same pages re-checked on a schedule, so a regression is caught when it ships rather than at the next audit.
• A dated record of what was failing and when it was fixed, which is what an accessibility complaint actually asks for.

What AI is never allowed to do

Letting an agent act on your account is only reasonable if the boundaries are real ones rather than instructions in a prompt. These are enforced server side.

• It never touches your website. No tool an agent can call writes to your site, your catalogue or your theme. Everything an agent can change is Inclusify's own configuration. The Shopify alt-text write-back above is not an exception: that is a merchant approving a suggestion in the Shopify app, and no agent can do it for them.
• It never takes payment. Upgrading returns a checkout URL for a person to open. Nothing charges a card.
• It never deletes. Removal stays in the panel, behind a human. The one change an agent can make that a real visitor would notice is switching the accessibility widget off, and that alone needs a confirmation round trip and emails the account owner a link to undo it.
• It cannot exceed your plan. Every tool is gated by the same plan rules the panel uses, so an agent can never reach something you have not paid for.
• It cannot overstate compliance. Accessibility statements run through a guardrail that refuses unsupported claims: "fully compliant" needs an attestation recorded against a name and a date.
• Every call is logged. Which tool, which credential, which website, and whether it was allowed or refused. Credentials are revocable from the panel at any time.

One honest limit worth stating plainly: a score is not compliance, and an agent reporting a good score has not established that your site works for disabled people. The checks that load a page are how you find that out. Compliance and standards.