io.github.jrpoolPublished by GitHub account jrpoolv64.0.0Updated Nov 8, 2026
Ensemble testing of web pages for accessibility, usability, and web standards
Kilotest tests web pages for accessibility, usability and web standards with an ensemble of rule engines, and lets an assistant browse and request test reports.
Web executable via Streamable HTTP. Remote servers run from the web runtime once configured in a workspace.
Paste this prompt into Claude Code, Codex, Cursor or another agent — or into SourceWeft chat. The agent reads this server's install guide, shows you its publisher, endpoint and sign-in, and adds it to your client once you agree. Keys never go into a command.
Read https://sourceweft.com/mcp/io.github.jrpool%2Fkilotest/install.md and connect the MCP server it describes to my client. Before changing any config, show me its publisher, endpoint and sign-in method and wait for my OK. Never put an API key in a command or in a file I would commit; ask me where it should come from.Add this to your client's mcpServers config.
{
"mcpServers": {
"kilotest": {
"type": "http",
"url": "https://kilotest.com/mcp"
}
}
}[npm version] [license] [MCP Registry] [GitHub stars] [Indexed on TensorBlock MCP Index] [mcptry] [SealKeeper Service SEAL]
An ensemble testing and reporting service for front-end web quality
This application uses an ensemble of 12 rule engines to test web pages for front-end quality (i.e. accessibility, usability, and web standards, including HTML, CSS, ARIA, and WCAG).
The testing paradigm employed by Kilotest is discussed in these papers:
Kilotest acts as a web server for human users, an MCP server (streamable HTTP, no authentication) for AI platforms, and an API for programmatic access.
Testing for Kilotest is performed by one or more workers (testing agents) that obtain jobs from Kilotest, perform them, and send reports of the results back to Kilotest. Those agents are instances of the Testaro package. Thus, the pages that Kilotest tests need not be on the public Internet. They need only be reachable by the Testaro workers that do the testing for Kilotest. So, one or more Testaro workers running inside a private intranet can test internal pages, as well as any external ones reachable from inside the intranet.
An active production instance of Kilotest may require multiple Testaro workers to handle the load, because testing one web page typically takes 2 to 4 minutes and workers test only one page at a time.
In the steps below, hosts T and K may be the same host or two different hosts. Host T can be a Debian stable, Ubuntu LTS, Windows, or macOS host. Host K can be any server host that can run the latest LTS version of Node.js. If hosts T and K differ, then they must be open to https traffic and host K must permit https requests from host T.
T.npm install.npm run deps.K.npm install.env.testaro file from the kilotest directory to .env in the testaro directory and replace the __placeholder__ values in .env with actual values.env.example file in the kilotest directory to a new .env file in the same directory and replace the __placeholder__ values in .env with actual values. TESTARO_WORKERS is a JSON object mapping each Testaro worker's ID to an object with its secret and its name; the ID and secret for a worker must match the NETWATCH_URL_WORKER_ID and NETWATCH_URL_AUTH values in that worker's .env. A worker authenticates each request with an HTTP Basic Authorization header (id:secret, base64-encoded); as of this writing that header is not yet sent by the published Testaro package, so this scheme requires a matching update to Testaro's netWatch.js request code (only to send the header; no change to Testaro's handling of jobs or reports is needed). The ID is a credential and is never published; the name is written by Kilotest into a job's and report's sources.worker property, which Testaro does not read or alter, so it is a distinct property from sources.agent (Testaro's own, untrusted, self-reported label, which Kilotest ignores). Choose a name that is safe to appear in every report Kilotest serves. ALLOW_INTERNAL_TARGETS controls whether this deployment can be induced to test pages at private, loopback, or link-local addresses; see SERVICE.md before changing it from its default.testaro directory, make Testaro start listening for jobs: node call netWatch true nn true, where nn is the number of seconds to wait between checks for new jobs. Note that Kilotest promises nearly immediate review and, on approval, immediate execution of “orders” for tests and retests, with typical total elapsed time 2 to 4 minutes. That promise implies a promise to keep nn small. A reasonable value is between 10 and 20.kilotest directory, start the Kilotest service: node index.Contributions are welcome! You can use GitHub issues to initiate discussions and propose changes. If you want to contribute code, please fork the repository and create a pull request.
See the SERVICE.md file for instructions on how to make Kilotest a service.
Kilotest is not only a web application but also an API and an MCP server. AI platforms and models can use Kilotest via those interfaces.
The public URL for models using the MCP server at kilotest.com is https://kilotest.com/mcp. The MCP server is registered at several registries. See AI-TOOLS.md for details.
There is additional documentation at:
These are the routine steps for maintaining Kilotest as currently deployed.
When you make a change in a feature branch without any API or tool contract change:
npm run prePR -- <level> (major, minor, or patch).main and delete the feature branch on GitHub.npm run postPR (with interactive browser authentication).npmjs.com has processed the publication.git pull, npm ci, and pm2 restart kilotest (but not npm audit fix) to deploy the revised main branch on the public server.When you make an API or tool contract change in a feature branch:
llms.txt: Update entries in the “API” section as needed. The initial pagagraph is generated, so do not edit it.llms-full.txt: Update descriptions as needed.capability.md and README.md: Update their prose to describe the changed behavior.npm run prePR -- <level> (major, minor, or patch).main and delete the feature branch on GitHub.npm run postPR (with interactive browser authentication).npmjs.com has processed the publication.git pull, npm ci, and pm2 restart kilotest (but not npm audit fix) to deploy the revised main branch on the public server.Hub Listing → Definitions → CI/CD → Import OpenAPI by uploading the regenerated openapi-3.0.yaml.If any step fails, see the details in docs/AI-TOOLS.md for troubleshooting instructions.
Source: README.md at commit 407bdfb
Explain Kilotest and its tools
Explains what Kilotest is, what its tools do, and how its results are structured. Use this before any other tool when the available tools or workflow are unclear; it is unnecessary once you know which tool you need. Returns a prose overview of the Kilotest domain, the tool workflow, and links to further documentation. Kilotest tests web pages for front-end quality with an ensemble of rule engines.
Takes no parameters.
List tested pages
Lists all pages Kilotest has tested. Use this first to discover whether a page already has any reports before requesting a test. Returns, for each tested page, its description, URL, and the identifier of its latest available report. Entries are sorted by page description and are not paginated.
Takes no parameters.
List issues in a report
Lists the issues reported in one report, along with the history of all reports about the same page. Use this after listPages to switch to an earlier or later report or to begin examining this report. The reportID is the latest report’s identifier from listPages or an earlier identifier from the history this tool returns. Returns the history and the basics about this report’s issues, sorted by summary and not paginated; an unknown or malformed reportID produces an error. The returned issue identifiers are inputs to the listViolators tool. Use getReport instead when the entire report is needed in one call.
reportIDrequiredList elements exhibiting an issue
Lists the elements of a tested page that were reported as exhibiting one issue in one report. Use this after listIssues to drill down from an issue to the elements violating rules belonging to that issue; the issueID must be one of the issue identifiers listIssues returned for the same reportID; call listIssues first if you do not have an issueID. Returns basics about each violating element, sorted by catalog index and not paginated; an unknown issueID or reportID produces an error.
issueIDrequiredreportIDrequiredList diagnoses of a violation
Lists the diagnoses that rule engines gave for how one element exhibited one issue in one report. Use this after listViolators to get details about the element as a violator of the issue; the catalogIndex is the element’s identifier in the listViolators output for that issue and report. Use getReport instead when all diagnoses in the report are needed at once. Returns, for each rule engine that reported a violation by the element of a rule belonging to the issue, the diagnosis given by the rule engine; an unknown report, issue, or element produces an error.
issueIDrequiredreportIDrequiredcatalogIndexrequiredQuestion a diagnosis
Questions or contests a diagnosis shown by the listDiagnoses tool; queued for review by management. Use this after listDiagnoses when you believe a rule violation was incorrectly diagnosed or classified into an issue, providing the issueID, reportID, catalogIndex, engineID, and ruleID shown in the diagnosis and your reason. No authorization is required; a nonexistent report, element, or diagnosis produces an error. Returns a confirmation with disposition details.
reasonrequiredruleIDrequiredissueIDrequiredengineIDrequiredreportIDrequiredcatalogIndexrequiredGet a full report
Retrieves one entire report as JSON, with all of its issues, violators, and diagnoses. Use this instead of drilling down through listIssues, listViolators, and listDiagnoses when the full report is needed in one call; for only part of a report, drill down with those tools instead. The reportID comes from listPages or from the report history that listIssues returns, and an unknown or malformed one produces an error. The report can exceed 1 MB; its exact size is disclosed by the listIssues tool.
reportIDrequiredRequest testing of a new page
Submits a request to test a page that has no report yet. Set reviewImmediately to true for immediate review with immediate approval or rejection and immediate enqueueing if approved (testing then typically takes 2 to 4 minutes); set it to false to queue the request for review by management, which typically takes 1 hour to 1 day. The description uniquely names the page in later listPages output and the reason is what the reviewer evaluates. A refusal, such as an existing report, a duplicate request, or a full queue, is reported in the disposition. Returns a confirmation with disposition details, including, on immediate approval, a report identifier and a question about whether to wait for completion with the awaitTest tool.
URLrequiredreasonrequireddescriptionrequiredreviewImmediatelyRequest a retest
Submits a request to retest a page whose existing report is considered obsolete. Set reviewImmediately to true for immediate review with immediate approval or rejection and immediate enqueueing if approved (testing then typically takes 2 to 4 minutes); set it to false to queue the request for review by management, which typically takes 1 hour to 1 day. The reportID must belong to the page’s latest report and the reason is what the reviewer evaluates. A refusal, such as a superseded report, a duplicate request, or a full queue, is reported in the disposition. Returns a confirmation with disposition details, including, on immediate approval, a report identifier and a question about whether to wait for completion with the awaitTest tool.
reasonrequiredreportIDrequiredreviewImmediatelyRequest a feature
Submits a request to add a new feature or improve an existing one; queued for review by management. Use questionDiagnosis instead to question a specific diagnosis shown by listDiagnoses. The feature text describes the proposed feature or improvement. A request identical to one awaiting review is refused, and otherwise the disposition confirms the request was logged and the manager notified. Returns a request confirmation with disposition details.
featurerequiredWait for an ordered job to finish
Waits for a job that a requestNewTest or requestRetest call with reviewImmediately set to true ordered, using the report identifier that call returned. Use this instead of polling listIssues when an immediate answer is preferred. The reportID identifies a pending or in-progress job and remains the finished report’s identifier for listIssues and getReport. Blocks until the report is ready, the job fails, or a maximum wait time elapses (5 minutes by default), sending no interim notices; returns the finished job’s status and, if ready, its report identifier.
reportIDrequired100% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.