Skills
Skills are reusable checks that return a verdict and a report. The built-in skills, and what they cannot do yet.
A skill is a packaged check. You give it inputs (usually a URL), it opens its own session, runs a fixed list of steps and returns a verdict, findings and an HTML report. Use a skill when you want the same check every time, with a clear pass or fail. Use a task when you want the agent to work toward an open goal.
Run a skill
From an MCP client, every skill is a tool named skill_<name>. It waits for the verdict and returns the raw run with a report link. See Tools. Two more tools work with skills: list_skills shows what you can run, and run_skill starts a run without waiting. To smoke test a page, use the smoke_test tool: it runs smoke-uat and returns a test report. get_report reads the report of any run.
A run ends with one of these statuses: passed, failed, error, cancelled or denied. While it works it is running. A finished run has counts (for example links checked, issues found), a summary and a result with each step.
Each skill declares permissions: network_capture, file_access or active_scan. A skill that sends active security probes needs active_scan. The MCP tool then asks for confirm: true, which the agent should set only after you agree to test that target.
Built-in skills
| Skill | What it checks |
|---|---|
smoke-uat | The page loads, the console is clean, same-origin links work, basic accessibility holds. Optional plain-language steps, then what must be true: expectText, expectUrl, expectNoText. And a file upload. See smoke-uat |
a11y-audit | WCAG 2.2 AA with axe-core and a keyboard walk, on one URL, a list of URLs or a whole site. Each problem is listed once with the pages it is on |
site-audit | Visits every page of a site in scope. Runs the smoke, accessibility and passive security checks on each. Reports broken links. Obeys robots.txt by default |
web-vitals | Core Web Vitals (LCP, CLS, INP, TTFB, FCP) and page weight against budgets. Median of several loads |
security-passive | Passive security review of one page: response headers, cookie flags, mixed content, TLS, exposed source maps, directory listings, insecure forms |
authenticated-scan | The same passive checks across a whole site with a crawl. See What skills cannot do yet |
api-exposure | What a page's own API calls give away: secrets, sensitive fields, stack traces, server errors, permissive CORS |
url-sandbox | Opens an untrusted URL in an isolated session. Reports the redirect chain, requests by host, downloads and a risk summary |
extract-paginated | Extracts a list or table across pages by following the Next control. Respects robots.txt and a delay |
ui-vs-design | Compares a page with a reference design image, overall and per component |
The built-in skills are passive: none of them sends active security probes. Call list_skills for the inputs, defaults and permissions of each skill in your project. A skill from this table that is missing from list_skills is not installed in your environment.
smoke-uat
smoke-uat is the skill behind smoke_test. Version 1.2.1 has these inputs:
| Input | Meaning |
|---|---|
url | The page to test. Required |
steps | Plain-language steps run in order after the page checks. The first failed step stops the flow. Step text is stored with the run: use a throwaway test account |
expectText | Text that must be on the page after the steps. Case-sensitive. The test waits up to 5 seconds for it, because pages often render after a sign-in |
expectUrl | Text the page address must contain after the steps, for example /dashboard |
expectNoText | Text that must not be on the page after the steps, for example an error message. Case-sensitive |
maxLinks | How many same-origin links on the start page to check. Default 50 |
strictLinks | A broken link fails the run. Default true. With false it is a finding only |
uploadFile | The name of a session file to attach to the first file input before the steps |
The order is: page checks, the flow, the console check, the expectations, then the link gate. So the flow always runs, even when a link on the start page is broken, and a broken link and a failed flow are both in the report. A failed step stops the rest of the flow, and the expectations are then reported as failed too, because the page is not where the flow should have left it.
Links and accessibility are checked on the start page only, not on pages the steps reach. The console check covers the whole run. The run fails on a high finding, a failed step or expectation, a response with an error status for the page, or a broken same-origin link (unless strictLinks is false).
Before 1.2.0 the link check ran before the steps, so one broken link failed the run before the flow ran. The expectUrl and expectNoText inputs are new in 1.2.0. Since 1.2.1 an expectation you did not set is listed as a skipped step and does not count as passed: a test with only expectText shows skipped for the expectUrl and expectNoText checks, and the summary says 14 of 16 steps passed.
Crawl skills and robots.txt
site-audit and authenticated-scan walk a site from a start page. They obey robots.txt by default and pause between requests. On a site you own, set respectRobots to false. A crawl that visits no page never passes: if robots.txt disallows the start URL, exclude removes it, or it does not load, the run fails and the reason says which.
What skills cannot do yet
A skill run cannot sign in. A run with the session options credentials, profileId, persistProfile, profileName or extensionIds is refused with invalid_input ("Signed-in skill runs are not available yet: remove session.…"), on the REST API and in MCP alike, and nothing starts. So a skill run cannot use the credential vault or a saved browser profile. This also means authenticated-scan cannot start signed in, whatever its name says. For a site behind a login, use create_session with credentials, then run_task on that session. See Signed-in sites.
A skill run can reach a private staging site through your own proxy: give options.session a proxyUrl and allowHosts. See Test a local app.
Reports
When a skill produces a report, the result has hasReport: true. The MCP tools add a reportUrl, a signed link that works without a key and expires after a few minutes. From the REST API, GET /v1/skill-runs/:id/report redirects to the report and needs your key. For a JSON report with one verdict, the steps, console errors and failed network calls, use GET /v1/skill-runs/:id/report.json or the get_report tool. See Reading results and Evidence.