scandiary
# scandiary
Check the accessibility of a site you built with Claude Code, Cursor, Lovable or by hand, then paste the result into your AI tool as a fix prompt.
```bash
npx scandiary https://your-site.com
npx scandiary localhost:3000
```
No signup and no API key. It uses the Chrome, Edge or Brave already on your machine.
## Get a fix prompt
```bash
npx scandiary https://your-site.com --prompt > fix-a11y.md
```
Paste that file into your coding tool. Each issue comes with real examples from your pages and a note on how to fix it properly. The prompt also tells your tool what not to do: no overlay scripts, no hiding elements just to pass, and no saying the work is done until a new scan confirms it.
## Use it from Claude Code
Install the skill once:
```bash
mkdir -p ~/.claude/skills/scandiary
curl -o ~/.claude/skills/scandiary/SKILL.md https://raw.githubusercontent.com/Yedigarli/scandiary-cli/master/skills/scandiary/SKILL.md
```
Then ask in plain words, for example *"check the accessibility of localhost:3000 and fix what you find"*. Claude runs the check, edits your code, and runs the check again before it reports the numbers. It lists any labels it had to guess so you can review them.
## Use it as an MCP server
For Cursor, Claude Desktop, Windsurf or any MCP client, add this to the client's MCP config:
```json
{
"mcpServers": {
"scandiary": {
"command": "npx",
"args": ["-y", "scandiary", "--mcp"]
}
}
}
```
It adds one tool, `check_accessibility`, which takes a `url` and an optional `pages` count and returns the fix prompt. In Claude Code: `claude mcp add scandiary -- npx -y scandiary --mcp`.
## Options
| Option | What it does |
|---|---|
| `--pages <n>` | Pages to check. Default 5, max 100 |
| `--prompt` | Print only the fix prompt |
| `--json` | Print the full result as JSON |
| `--strict` | Exit with code 1 when issues are found, for CI |
| `--mcp` | Run as an MCP server over stdio |
Exit codes: `0` finished, `1` issues found with `--strict`, `2` the check could not run.
## What this can and cannot tell you
Automated checks find roughly a third of accessibility problems, this one included. The rest needs a person using a keyboard and a screen reader.
A short list, or an empty one, does not mean your site is accessible. It does not say whether you meet any legal standard.
Rules come from [axe-core](https://github.com/dequelabs/axe-core): WCAG 2.0 and 2.1, levels A and AA.
Page content in the prompt is treated as untrusted data. It is flattened, shortened and marked so your AI tool should not follow anything written inside it. Review what your tool changes, as you would with any generated code.
## Privacy
The check runs on your machine. This tool sends no telemetry and has no analytics. Your browser opens the pages you asked it to check, along with whatever those pages load, as in a normal visit.
## Weekly checks
A one-off scan tells you where you stand today. [Scandiary](https://scandiary.com) runs the check every week and emails what changed, so you keep a dated history. The free plan covers 25 pages.
## License
MIT
TDQS
Scored across 1 tool
With only one tool there is nothing to confuse; its purpose (run an axe-core accessibility audit and return a fix prompt) is unambiguous. No overlap or boundary issues are possible in a single-tool surface.
check_accessibility follows a clear verb_noun snake_case convention that reads naturally and matches the action performed. Nothing else exists to break the pattern.
A single tool is defensible for a narrowly scoped accessibility-checking server, but it feels thin — there is no option to list rules, scan multiple URLs, or retrieve prior results. The surface is one monolithic operation with no supporting tools.
The core operation (scan a site, return issues plus fix guidance) is covered, and the description honestly notes that automated checks catch only about a third of problems. However, there are no tools or parameters for rule selection, WCAG level control, multi-page/batch scanning, or exported reports, leaving notable gaps for real audit workflows.