@jrpool/kilotest 59.1.0 → 59.1.2

package/.claude/settings.local.json

@@ -5,7 +5,6 @@
       "Bash(gh api *)",
       "WebFetch(domain:raw.githubusercontent.com)",
       "Bash(ls -la /Users/pool/Documents/Topics/repos/a11yTesting/kilotest/*.json)",
-      "Bash(grep -n \"^import\\\\|^export\" /Users/pool/Documents/Topics/repos/a11yTesting/qai/src/*.ts)",
       "Bash(find /Users/pool/Documents/Topics/repos/a11yTesting/kilotest -type f \\\\\\( -name \"*.test.js\" -o -name \"*.test.cjs\" -o -name \"test.js\" \\\\\\) ! -path \"*/node_modules/*\" -exec wc -l {} +)",
       "Bash(find /Users/pool/Documents/Topics/repos/a11yTesting/kilotest -type f \\\\\\( -name \"*.test.js\" -o -name \"*.test.cjs\" -o -name \"test.js\" \\\\\\) ! -path \"*/node_modules/*\" -exec grep -h \"^test\\(\" {} +)",
       "Bash(npm install:*)",

package/README.md

@@ -10,7 +10,7 @@ An ensemble testing and reporting service for front-end web quality
 
 ## Features
 
-This application uses an ensemble of 12 rule engines to test web pages for front-end quality (i.e. accessibility, usability, and web standards).
+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 (HTML, CSS, ARIA, WCAG)).
 
 The testing paradigm employed by Kilotest is discussed in these papers:
 
@@ -18,11 +18,11 @@ The testing paradigm employed by Kilotest is discussed in these papers:
 - [Testaro: Efficient Ensemble Testing for Web Accessibility](https://arxiv.org/abs/2309.10167)
 - [Accessibility Metatesting: Comparing Nine Testing Tools](https://arxiv.org/abs/2304.07591)
 
-Kilotest acts as a web server for human users, an MCP server for AI platforms, and an API for programmatic access.
+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](https://www.npmjs.com/package/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 about 3 minutes and workers test only one page at a time.
+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.
 
 ## Getting started locally with 1 worker
 
@@ -62,7 +62,7 @@ The URL for models using the MCP server is `https://kilotest.com/mcp`. The MCP s
 
 There is additional documentation at:
 
-- [QAI](https://kilotest.com/qai): a tutorial for allowing AI assistants to use Kilotest
+- [Tutorial: authorizing AI assistants to use Kilotest](https://kilotest.com/tutorialAI.html)
 - [AI-TOOLS.md](docs/AI-TOOLS.md): how Kilotest implements the MCP protocol
 - [Summary of Kilotest capabilities](https://kilotest.com/capability.md)
 - [llms.txt](llms.txt): basic documentation for LLMs

package/api/util.ts

@@ -51,7 +51,7 @@ export const getResponseMetadata = () => ({
 export const getToolsFacts = () => ({
   'name': 'Kilotest',
   'description': {
-    'what Kilotest does': 'Kilotest tools generate and make available findings about the front-end quality (i.e. accessibility, usability, and web standards) of web pages. A Kilotest job generates findings by using Testaro to test a page against about 1300 rules defined by an ensemble of twelve rule engines. Testaro produces a report of the job. The report describes violations of the rules. Kilotest uses Testilo to enhance the report with a classification of the rule violations into about 380 issues. Kilotest makes facts about the tested pages, the issues, and the violations retrievable at four levels of granularity.',
+    'what Kilotest does': 'Kilotest tools generate and make available findings about the front-end quality (i.e. accessibility, usability, and web standards, including HTML, CSS, ARIA, and WCAG) of web pages. A Kilotest job generates findings by using Testaro to test a page against about 1300 rules defined by an ensemble of twelve rule engines. Testaro produces a report of the job. The report describes violations of the rules. Kilotest uses Testilo to enhance the report with a classification of the rule violations into about 380 issues. Kilotest makes facts about the tested pages, the issues, and the violations retrievable at four levels of granularity.',
     'how to retrieve findings': {
       'level 1': 'Use the listPages tool to get a list of tested pages, each with its latest report. The listIssues output about any report lists all reports about the same page.',
       'level 2': 'Use the listIssues tool to get a list of issues in one report.',

package/capability.md

@@ -2,7 +2,7 @@
 
 ## Capability
 
-Web-page front-end quality audit. Kilotest tests web pages for front-end quality, namely accessibility, usability, and web standards, and makes structured findings available for retrieval.
+Web-page front-end quality audit. Kilotest tests web pages for front-end quality, namely accessibility, usability, and web standards, including HTML, CSS, ARIA, and WCAG, and makes structured findings available for retrieval.
 
 ## Purpose
 

package/docs/AI-TOOLS.md

@@ -4,7 +4,7 @@
 
 Until 2026 Kilotest was intended, and implemented, as a web application performing a service for human users.
 
-Beginning in May 2026, it [became evident](https://github.com/jrpool/kilotest/issues/2) that Kilotest could operate as a set of tools for language models to allow them to improve their answers to questions about the front-end quality (accessibility, usability, and web standards) of specific web pages.
+Beginning in May 2026, it [became evident](https://github.com/jrpool/kilotest/issues/2) that Kilotest could operate as a set of tools for language models to allow them to improve their answers to questions about the front-end quality (accessibility, usability, and web standards, including HTML, CSS, ARIA, and WCAG) of specific web pages.
 
 A decision was made to **make Kilotest discoverable, usable, and, where appropriate, used as a provider of tools for language models**.
 
@@ -42,7 +42,7 @@ The external features that support the use of Kilotest as a collection of AI too
 - A [pull request](https://github.com/public-apis/public-apis/pull/6346/changes) to add Kilotest to the list of public APIs in the `public-apis` repository.
 - An [issue](https://github.com/APIs-guru/openapi-directory/issues/2677) to add Kilotest to `openapi-directory`.
 - A [pull request](https://github.com/w3c/wai-evaluation-tools-list/pull/1153) to add Kilotest to the WAI evaluation tools list.
-- Registration of Kilotest as an active server in the [official MCP Registry](https://registry.modelcontextprotocol.io) (`io.github.jrpool/kilotest`), maintained by the [Model Context Protocol](https://modelcontextprotocol.io/) project. The [PulseMCP](https://www.pulsemcp.com/servers) directory and the VS Code MCP gallery both crawl this registry, so Kilotest is discoverable through them with no separate submission.
+- Registration of Kilotest as an active server in the [official MCP Registry](https://registry.modelcontextprotocol.io/v0.1/servers?search=io.github.jrpool/kilotest), maintained by the [Model Context Protocol](https://modelcontextprotocol.io/) project. The [PulseMCP](https://www.pulsemcp.com/servers) directory and the VS Code MCP gallery both crawl this registry, so Kilotest is discoverable through them with no separate submission.
 - Registration of Kilotest with the [Smithery](https://smithery.ai/servers/pool/kilotest) MCP server registry.
 - Registration of Kilotest with the [Glama](https://glama.ai/mcp/connectors/com.kilotest/kilotest) MCP server registry, including a claim of ownership of the MCP connector by the maintainer via a `TXT` DNS record for `_glama-claim.kilotest.com`, with the value `glama_claim_gVV4HrPdcXr9TEfj1p3icEUBJ3_OVJGX`.
 - Registration of Kilotest with [Awesome MCP Servers](https://www.tensorblock.co/mcp/servers/github-jrpool-kilotest-f518ba36).
@@ -62,11 +62,9 @@ The external features that support the use of Kilotest as a collection of AI too
 
 ## Required maintenance
 
-Whenever the `/api/version.ts` file is updated:
+Whenever the `version` property of the `package.json` file is updated:
 
-- Update the `server.json` file (version field).
-- Update the `lhm.plugin.json` file (version field).
-- Regenerate `openapi.yaml` (`npm run generate:openapi`).
+- Update `openapi.yaml` and the versions of `server.json` and `lhm.plugin.json` (`npm run generate`).
 - Create a pull request and merge to `main` (triggers `publish-mcp.yml` automatically for the MCP Registry).
 - Execute `lhm plugin update --dir .` (for LobeHub).
 
@@ -95,12 +93,11 @@ To-dos recommended by Claude Sonnet 5 Medium on Devin:
 
 - **Other directories not yet targeted.** The [mcp.so](https://mcp.so/submit) directory offers a free tier but steers submitters toward a $39 paid listing; deferred as a commercial decision. The Docker MCP Catalog is not a fit because it requires stdio transport and a Dockerfile, and Kilotest is streamable-http.
 
-- **Client-onboarding friction isn't documented.** Some MCP clients need the `mcp-remote` npx bridge to use a remote streamable-HTTP server like Kilotest's. Ready-made Claude Desktop/Cursor/Windsurf config instructions added to QAI would convert "discovered" into "used" faster, since case 3 of your use cases assumes a technically savvy discoverer but not all users are.
+- **Client-onboarding friction isn't documented.** Some MCP clients need the `mcp-remote` npx bridge to use a remote streamable-HTTP server like Kilotest's. Ready-made Claude Desktop/Cursor/Windsurf config instructions added to the AI tutorial would convert "discovered" into "used" faster, since case 3 of your use cases assumes a technically savvy discoverer but not all users are.
 
 Other future work:
 
-- Add to QAI, or replace much of the current QAI content with, an [Add Custom Connector link](https://claude.ai/customize/connectors?modal=add-custom-connector&connectorName=Kilotest&connectorUrl=https%3A%2F%2Fkilotest.com%2Fmcp).
-- Consider subscribing to a `Claude.ai` Team plan and submitting Kilotest to the [Claude Connectors Directory](https://claude.com/docs/connectors/building/submission). Details provided by GLM-5.2 High: “If accepted, Kilotest would get a permanent listing URL like `https://claude.ai/directory/connectors/kilotest` with a Connect button, and would appear in Claude’s in-product browse/search and ‘Suggested Connectors’. This is the highest-value listing for your use cases, because it puts Kilotest directly in front of Claude users who have not explicitly searched for it.”
+- Add to the AI tutorial, or replace much of the current AI tutorial content with, an [Add Custom Connector link](https://claude.ai/customize/connectors?modal=add-custom-connector&connectorName=Kilotest&connectorUrl=https%3A%2F%2Fkilotest.com%2Fmcp).
 - Recommended by GLM-5.2 High: Submit a Kilotest-appropriate request to one or more AI platforms and discover whether the model discovers Kilotest and, if so, either uses it or offers to use it in the creation of a response.
 - Recommended by ChatGPT: A general capability manifest that says, in one machine-readable place: Here are the capabilities Kilotest provides; here are all the interfaces through which you can invoke them; here are their requirements and effects. For example:
 

package/docs/SERVICE.md

@@ -326,9 +326,8 @@ Both logs are rotated; see “PM2 log rotation” above for the application log
 When the Kilotest web, API, or MCP interface is revised in a feature branch:
 
 1. Update the version in `package.json`
-1. Update the version in `server.json`
-1. Update the version and any changes in the API in `lhm.plugin.json`
-1. If the API has changed, run the `generate:openapi` script
+1. Update any changes in the API in `lhm.plugin.json`
+1. Run the `generate` script
 1. Execute the command `npx @lobehub/market-cli plugin update --dir .`
 1. Commit and push the changes to the feature branch
 1. Create a pull request to merge the feature branch into `main`

package/docs/decisions/001-api-design.md

@@ -5,111 +5,37 @@ status: accepted
 
 # API design
 
-## Context and problem
+## Context, problem, and decision
 
 Kilotest manages data that are organized into reports. Each report contains the results of one session in which multiple rule engines were used for testing the front-end quality of one web page.
 
-The UI offers users opportunities to influence and interrogate the data managed by the application. Users do this with input via links and forms. The output is HTML. UI users are typically humans.
+The API offers existing data as a hierarchy of granularity:
 
-The opportunities to interrogate the data in the UI are organized as a hierarchy of granularity:
+1. All tested pages.
+2. Reports available about one page.
+3. Details of one report, including summaries of the reported issues.
+4. Details of one issue, including summaries of its violators.
+5. Details of one violator, including its diagnoses.
 
-1. All available reports
-2. Details of one report, including summaries of the reported issues.
-3. Details of one issue, including summaries of its violators.
-4. Details of one violator, including its diagnoses.
+It also offers downloads of complete reports in JSON format.
 
-A violator of an issue is a particular element (HTML, SVG, etc.) on the page. When a rule engine reports a violation of one of its rules, the rule engine usually identifies an element as responsible for that violation. If the rule classifier used by Kilotest classifies that rule as belonging to a particular issue, then Kilotest refers to that element as a violator of that issue.
+The API would be simpler to implement if it offered only one-shot interrogation, i.e. downloads of complete reports. But the available evidence indicates that this would be inferior for typical users.
 
-This hierarchical design is based on a realistic assumption about how human users interact with Kilotest. They visit its home page and begin what to them is a session. Although requests to Kilotest are stateless, the response at each level includes links that contain all the specifications required for a request at the next level. For example, the response to a request at level 3 includes, for each violator, a link that makes a request at level 4 and includes identifiers of the page, the issue, and the violator.
-
-The responses to requests in the UI at any level include some of the information about the previous levels. For example, a response at level 3 includes a summary of information about the report and about the issues in that report. The prior-level summarized information is based on assumptions about what a typical human user would value. For example, at level 3, the prior-level information does not summarize all the available reports, but does include a list of the rule engines that succeeded and failed in testing the page and the counts of issues reported.
-
-These assumptions for human UI users may or may not be valid for how API consumers prefer to interact with a Kilotest API. Those interactions may vary depending on the tasks that they are performing. Consider three scenarios:
-
-1. A user asks a language model for all available information about the front-end quality of a particular web page.
-2. A user asks a language model for all the available information about issues related to a particular topic, such as keyboard navigation, for a particular web page.
-3. A user asks a language model to describe the front-end quality of a particular web page. Having consumed the description, the user asks the model to describe one of the reported issues. Having consumed that description, the user asks the model to describe one of the reported violators of that issue. Having consumed that description, the user asks the model to describe the diagnoses of that violation.
-
-Scenario 1 seems to justify an API that can aggregate all information from all available reports about the page into a single response.
-
-Scenario 2 seems to justify an API that filters out from the scenario-1 response all information about issues unrelated to the specified topic.
-
-Scenario 3 seems to justify an API that mimics the UI in structure.
-
-Even these apparently justified API designs depend on the assumption that users mean what they say. For example, in scenario 1 a user asks for **all** available information about the front-end quality of a particular web page. The user may really want all that information only if it is not too voluminous, and otherwise want a summary.
-
-Uncertainty about how consumers will interact with the API creates a design problem: How should the API be further developed?
-
-As of the date of this decision, a partial initial API version already exists: an API that mimics the UI for levels 1, 2, and 3. It is exposed as a traditional HTTP REST API and also as a connector to a collection of MCP tools. For each level, the API provides an operation.
-
-## Considered options
-
-1. **Iterate and instrument.** (1) Finish redesigning the operations at levels 1, 2, and 3, to represent the hypothesized typical needs of language-model consumers. Then (2) add an operation that implements level 4. Then (3) add an operation that collects comments from consumers on how the API design could better satisfy their needs. Then (4) add metrics to make API usage and submitted comments available to Kilotest managers.
-2. **Research first.** (1) Pause further API development while doing fundamental research to predict consumer needs. Then (2) resume API and metrics development, including API redesign if the research results warrant.
-
-## Decision
-
-The decision is to adopt **option 1: iterate and instrument**.
-
-## Empirical basis
-
-The decision is based on the working hypothesis that the typical consumer will be a language model (most often a foundation model) performing a task for a human user. Even without a pause for fundamental research, there is enough empirical evidence to justify this decision.
-
-### Completion of the 4-level hierarchy
-
-There is empirical support for an API optimized for scenario 3, i.e. incremental rather than one-shot interrogation. Both single-shot comprehensive requests and incremental drill-downs occur in significant numbers in real-world language-model use.
+Both one-shot comprehensive requests and incremental drill-downs occur in significant numbers in real-world language-model use.
 
 - Jian _et al._ (2024) studied experienced ChatGPT users and found that **43.8% of prompts were single-component**, **38.2% were dual-component**, and only **18.0% were multi-component**. A request such as scenario 1 (“tell me everything about page X”) or scenario 2 (“tell me about defect class X on page Y”) is structurally common because it is typically a single-component prompt.
 - However, follow-up refinement is frequent. Mysore _et al._ (2025) analyzed large-scale Bing Copilot and WildChat writing sessions and report: “Rather than passively accepting output, users actively refine, explore, and co-construct text.” This matches scenario 3.
 
-For scenario 3, current patterns do not require the consumer to restart at level 1. Anthropic’s tool-using agent documentation describes an agentic loop in which the full conversation history is kept and “every turn sees the complete prior context”. Cohere’s multi-step tool-use documentation explains that the model can use information learned from one tool call to parameterize a subsequent call. MCP’s typed tool schemas support this pattern. Therefore the existing hierarchy can be expected to be practical in scenario 3.
-
-### Usage and suggestion metrics
-
-There is also empirical support for modesty in any estimate of the adequacy of the current or any other single API design. As found by Zhu _et al._ (2025), “users do not transfer existing conversational norms to LLM interactions, but instead develop new registers with distinct pragmatic features.” Metrics will help to inform the contributors to the API about how consumers are actually using it and about proposed improvements.
+Anthropic’s tool-using agent documentation describes an agentic loop in which the full conversation history is kept and “every turn sees the complete prior context”. Cohere’s multi-step tool-use documentation explains that the model can use information learned from one tool call to parameterize a subsequent call. MCP’s typed tool schemas support this pattern.
 
-## Cost and context-window constraints
+Zhu _et al._ (2025) found that “users do not transfer existing conversational norms to LLM interactions, but instead develop new registers with distinct pragmatic features.”
 
-A user-friendly rendering of an entire Kilotest report is estimated at about 5 MB of text, or roughly 1.25 million tokens. For a cost estimate, we can use one major frontier model as of the date of this decision (Claude 3.5 Sonnet). On that basis, the report size exceeds the 200,000-token context window of the model, so the model cannot consume the whole report in one prompt. If it is passed chunked, each pass will cost roughly $3.75 in input tokens. Every subsequent question about it will require re-sending it. By contrast, a four-level drill-down through report → issue → violator → diagnosis costs roughly $0.07 for a typical path.
+A user-friendly rendering of an entire Kilotest report is estimated at about 5 MB of text, or roughly 1.25 million tokens. That exceeds a typical context window, so a language model cannot consume the whole report in one prompt. On the basis of a 2026 pricing estimate of $0.0005 per 1,000 tokens, if the report is passed chunked, each pass will cost roughly $3.75 in input tokens. Every subsequent question about it will require re-sending it. By contrast, a four-level drill-down through page → report → issue → violator → diagnosis costs roughly $0.07 for a typical path.
 
 These estimates can be applied to a hypothetically typical conversation. It would involve one report, two issues, and six violators (two per issue). The user would not ask about diagnoses. Delivering such results with the full-report method requires one pass to identify the report, two passes to describe the issues, and six passes to describe the violators, for a total of about $33.75. Doing so incrementally costs about $0.26, which is only **1/130th** of the cost of the same result with the full-report strategy.
 
 On the basis of these cost estimates, even if a user initially wanted a comprehensive report and then wanted a language model to interpret it, the impact of that strategy on cost would likely motivate the user to switch to an incremental strategy as a default.
 
-## Sub-decision: ancestor information in level responses
-
-Given this decision, a secondary decision to make is what information from prior levels to repeat in a response. Four alternatives were considered:
-
-1. **Identifiers only:** The report, issue, and violator would be described by their unique identifiers only. The consumer would use the identifiers to retrieve from its conversation-history context any forgotten information needed about them.
-2. **Identifiers plus labels:** Ancestor entities (report, issue, and/or violator) would be described only by their unique identifiers and human-interpretable labels. If the consumer needs other forgotten facts about them, it would use the identifiers to retrieve those facts by repeating ancestor requests.
-3. **Currently pertinent facts:** The facts from ancestor requests would be repeated if, and only if, the consumer could need them for interpreting the response to the current-level request. For example, if the current-level request is about one report, facts about other reports are not pertinent, but any facts about the report are pertinent. Likewise for one issue or one violator.
-4. **Cumulative facts:** All the information from the prior responses would be repeated, so that any needed information would be available in the current response and no search of the conversation history would be needed.
-
-The sub-decision was **currently pertinent facts** (option 3). This decision was based on cost and reliability, as follows.
-
-- **Cost:** Option 3 is slightly more costly than option 2 when all pertinent facts are remembered, because it provides duplicate information. But option 3 is substantially less costly than option 2 if needed facts are forgotten, because option 3 avoids the need to repeat an ancestor request to re-retrieve forgotten facts. Option 4 is much more costly than option 3, because of the much larger response bodies and the inclusion of much irrelevant information in responses.
-- **Quality:** Option 2 provides better locality than option 1, and option 3 provides better locality than option 2. Locality improves the probability that a language model will actually make use of pertinent facts instead of ignoring them or fabricating hallucinated replacements for them.
-- **Reliability:** Option 1 entails a greater risk of information loss and hallucination than option 2. With option 1, the consumer could be unable to retrieve the needed information using identifiers if the conversation history were truncated, if an operation were invoked in isolation, or if the model were asked later to summarize findings in natural language.
-
-No sub-decision option is optimal under all possible conditions, but the working hypothesis about prevailing use patterns favors option 3.
-
-## Implementation plan
-
-- The existing request handlers for levels 1, 2, and 3 will be revised. After revision, they will omit excess information about prior levels and include all currently pertinent facts.
-- Level 4 will be implemented. It will return the diagnoses for one violator of one issue in one report.
-- A comment operation will be provided. This will allow consumers to report friction or suggest improvements to the API design.
-- Usage metrics will be defined, captured, and recorded. This will allow Kilotest managers to observe which levels, issues, and patterns are most common and what comments have been received.
-- If the empirical data later show that the API does not serve some common scenario well, the API will be redesigned accordingly.
-
-### Risks and mitigations
-
-- **Risk:** The hierarchy may not match the way consumers actually want to query the data.
-  - **Mitigation:** The comment operation and usage metrics will surface mismatches early, allowing Kilotest managers to make data-driven decisions about API improvements.
-- **Risk:** The cost estimates assume the typical consumer preserves conversation history. A poorly implemented consumer could still incur higher-than-necessary costs.
-  - **Mitigation:** It is hypothesized that typical consumers will be models that maintain message history. When they do not, the ancestor labels provide a minimal human-friendly substitute that facilitates history reconstruction when needed.
-- **Risk:** Scenario 1 consumers may still want an aggregated “everything about page X” response.
-  - **Mitigation:** A future operation can be added to aggregate the hierarchy on the server side and return a structured summary. That decision is deferred until usage and comment data justify it.
-
 ## References
 
 - Jian, J., _et al._ (2024). [Understanding User Prompting Behavior in Generative AI](https://dl.acm.org/doi/abs/10.1002/pra2.1318).

package/lhm.plugin.json

@@ -1,7 +1,7 @@
 {
   "author": "Jonathan Robert Pool",
   "cloudEndpoint": "https://kilotest.com/mcp",
-  "description": "Tools that test web pages for front-end quality (accessibility, usability, and web standards) and make test results available",
+  "description": "Tools that test web pages for front-end quality (accessibility, usability, and web standards, including HTML, CSS, ARIA, and WCAG) and make test results available",
   "homepage": "https://github.com/jrpool/kilotest",
   "identifier": "jrpool-kilotest",
   "name": "Kilotest",
@@ -10,15 +10,18 @@
   "tags": [
     "accessibility",
     "a11y",
-    "testing",
     "mcp",
     "mcp-server",
-    "modelcontextprotocol"
+    "modelcontextprotocol",
+    "testing",
+    "w3c",
+    "wcag",
+    "web standards"
   ],
   "tools": [
     {
       "name": "getKilotestOverview",
-      "description": "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. Returns a prose overview of the Kilotest domain, the tool workflow, and links to further documentation. Kilotest integrates an ensemble of 12 rule engines, with about 1,300 rules, to test web pages for front-end quality (accessibility, usability, and web standards). Each test session generates a standardized report describing which elements violated which rules and grouping the violations into about 380 issues. Kilotest can list the tested pages, the reports about each page, the issues in each report, the violators of each issue, and the diagnoses of each violation. Kilotest also accepts requests to test pages not yet tested and to retest already tested pages.",
+      "description": "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. Returns a prose overview of the Kilotest domain, the tool workflow, and links to further documentation. Kilotest integrates an ensemble of 12 rule engines, with about 1,300 rules, to test web pages for front-end quality (accessibility, usability, and web standards, including HTML, CSS, ARIA, and WCAG). Each test session generates a standardized report describing which elements violated which rules and grouping the violations into about 380 issues. Kilotest can list the tested pages, the reports about each page, the issues in each report, the violators of each issue, and the diagnoses of each violation. Kilotest also accepts requests to test pages not yet tested and to retest already tested pages.",
       "inputSchema": {
         "type": "object",
         "properties": {},
@@ -412,7 +415,7 @@
     },
     {
       "name": "listIssues",
-      "description": "Lists the issues reported in one report, along with the history of all reports about the same page. Use this after listPages to drill into a specific report, identified by its timestamp and job identifier. Returns basics about the report's issues and a list of every report about the same page, from oldest to latest.",
+      "description": "Lists the issues reported in one report, along with the history of all reports about the same page. Use this after listPages to drill into a specific report, identified by its timestamp and job identifier. Returns basics about the report’s issues and a list of every report about the same page, from oldest to latest.",
       "inputSchema": {
         "type": "object",
         "properties": {
@@ -1151,7 +1154,7 @@
     },
     {
       "name": "listViolators",
-      "description": "Lists the elements of a tested page that were reported as exhibiting one issue in one report. Use this after listIssues to drill from an issue down to the elements it affects. Returns basics about each violating element, including its identifier in the page's element catalog.",
+      "description": "Lists the elements of a tested page that were reported as exhibiting one issue in one report. Use this after listIssues to drill from an issue down to the elements it affects. Returns basics about each violating element, including its identifier in the page’s element catalog.",
       "inputSchema": {
         "type": "object",
         "properties": {
@@ -4184,7 +4187,7 @@
     },
     {
       "name": "awaitTest",
-      "description": "Waits for a job ordered via the orderNewTest or orderRetest tool to finish, using the report identifier either tool returned. Use this instead of polling listIssues when an immediate answer is preferred. Blocks until the report is ready, the job fails, or a maximum wait time elapses, sending no interim notices; returns the finished job's status and, if ready, its report identifier.",
+      "description": "Waits for a job ordered via the orderNewTest or orderRetest tool to finish, using the report identifier either tool returned. Use this instead of polling listIssues when an immediate answer is preferred. Blocks until the report is ready, the job fails, or a maximum wait time elapses, sending no interim notices; returns the finished job’s status and, if ready, its report identifier.",
       "inputSchema": {
         "type": "object",
         "properties": {
@@ -4506,5 +4509,5 @@
       }
     }
   ],
-  "version": "59.0.0"
+  "version": "59.1.2"
 }

package/llms-full.txt

@@ -2,7 +2,7 @@
 
 ## What Kilotest is
 
-Kilotest is an application that performs ensemble testing of web pages for front-end quality (i.e. accessibility, usability, and standard conformance) and reports the test results.
+Kilotest is an application that performs ensemble testing of web pages for front-end quality (i.e. accessibility, usability, and web standards, including HTML, CSS, ARIA, and WCAG) and reports the test results.
 
 ## What Kilotest does for language models
 
@@ -14,18 +14,12 @@ Without calling any tool, an LLM can, under some conditions, load web pages and
 - fragmentary, because of capability limitations, such as inability to run browsers and interact with web pages
 - inaccurate, because of the tendency to replace missing information with hallucinations
 
-To provide a more inexpensive, thorough, and accurate assessment, the agent could, in principle, ask an ensemble of specialized rule engines to test the page. However, selecting and running such rule engines and consolidating their results is itself expensive and difficult, and most available rule engines are not callable as MCP tools. Kilotest assumes responsibility for assembling, integrating, and running several rule engines. Kilotest:
-
-- defines an MCP tool that tests web pages for front-end quality
-- defines MCP tools that report the test results
-- defines connectors to those tools, compatible with major AI platforms
-
-The tool that tests web pages for front-end quality has attributes that no other such tool has. It:
+To provide a more inexpensive, thorough, and accurate assessment, the agent could, in principle, ask an ensemble of specialized rule engines to test the page. However, selecting and running such rule engines and consolidating their results is itself expensive and difficult, and most available rule engines are not callable as MCP tools. Kilotest fills the gap between an LLM and rule engines. Kilotest:
 
 - selects an ensemble of 12 rule engines that implement tests for, in total, more than a thousand rules for front-end quality
 - runs the tests of the rule engines
 - combines the reports of the rule engines into a single integrated report
-- consolidates the 1000+ rules having 12 different naming systems into 300+ “issues” with a uniform naming system
+- consolidates the rules into about 380 “issues” with a uniform naming system
 
 The tools that report test results extract from reports statistics and details at various levels of granularity, as required by an agent to fulfill particular user requests.
 
@@ -46,11 +40,13 @@ The rule engines in the Kilotest ensemble take responsibility for determining wh
 
 ## Kilotest versus other MCP servers
 
-In the marketplace for MCP servers that test for front-end quality, all servers other than that of Kilotest leverage at most 1 rule engine, most often `axe-core`. The Kilotest testing tool leverages `axe-core` plus 11 other rule engines. This has these main effects:
+In the marketplace for MCP servers that test for front-end quality, all servers other than that of Kilotest leverage at most 3 rule engines, most often only `axe-core`. Most other MCP servers also require authentication. Kilotest leverages `axe-core` plus 11 other rule engines, and it does not require authentication.
+
+For web pages that have not yet been tested, a single-rule-engine MCP can provide faster results than Kilotest. A tool running only the `axe-core` tests can complete its work in about 5 seconds. The testing tool of Kilotest usually completes its work in 2 to 4 minutes, because all 12 rule engines are run, and some of the tests involve navigation and interaction with the page and LLM inference.
+
+For web pages about which reports are already available, Kilotest can provide faster results than a single-rule-engine MCP server, because Kilotest stores test results for subsequent retrieval. A retrieval from a Kilotest reporting tool can be completed in less than 2 seconds.
 
-- For web pages that have not yet been tested, a single-rule-engine MCP can provide faster results than Kilotest. A tool running only the `axe-core` tests can complete its work in about 5 seconds or less. The testing tool of Kilotest usually completes its work in 2 to 3 minutes, because all 12 rule engines are run, and some of the tests involve navigation and interaction with the page and LLM inference. Moreover, Kilotest currently allows users (both humans and models) to **recommend** new pages for testing but authorizes only Kilotest managers to make the tool proceed with the testing. The wait for manager action can take up to a day. A feature permitting immediate testing ordered by AI agents is planned, but, until it is implemented, Kilotest will be useful for not-yet-tested pages only in long-running (multi-day) workflows.
-- For web pages about which reports are already available, Kilotest can provide faster results than a single-rule-engine MCP server, because Kilotest stores test results for subsequent retrieval. A retrieval from a Kilotest reporting tool can be completed in less than 2 seconds.
-- Kilotest results are more comprehensive than single-rule-engine MCP server results. Every rule engine provides limited coverage of front-end quality, so false negatives (missed defects) are more common with single-rule-engine MCP servers. This difference [has been documented in research](https://arxiv.org/pdf/2304.07591).
+Kilotest results are more comprehensive than single-rule-engine MCP server results. Every rule engine provides limited coverage of front-end quality, so false negatives (missed defects) are more common with single-rule-engine MCP servers. This difference [has been documented in research](https://arxiv.org/pdf/2304.07591).
 
 ## How to use Kilotest
 
@@ -63,12 +59,12 @@ Kilotest offers a comprehensive suite of capabilities to users via its web UI:
 - Get statistics about issues reported in one report, and a history of all reports about the same page: `https://kilotest.com/listIssues.html/{timeStamp}/{jobID}`
 - Get details about one issue reported in one report: `https://kilotest.com/listViolators.html/{issueID}/{timeStamp}/{jobID}`
 - Get diagnoses by rule engines of rule violations for one HTML element exhibiting one issue in one report: `https://kilotest.com/listDiagnoses.html/{issueID}/{timeStamp}/{jobID}/{catalogIndex}`
-- [Recommend the testing of a not-yet-tested page](https://kilotest.com/requestNewTestForm.html)
-- Recommend the retesting of a previously tested page: `https://kilotest.com/requestRetestForm.html/{timeStamp}/{jobID}`
+- [Request the testing of a not-yet-tested page](https://kilotest.com/requestNewTestForm.html)
+- Request the retesting of a previously tested page: `https://kilotest.com/requestRetestForm.html/{timeStamp}/{jobID}`
 - [Get statistics about frequently reported issues across all pages](https://kilotest.com/listTopIssues.html)
 - [Get a list of the operations that Kilotest managers are authorized to request](https://kilotest.com/manage.html)
-- [Tutorial, “Accessibility testing strategies”](https://kilotest.com/tutorial.html)
-- [Tutorial, “QAI tutorial”](https://kilotest.com/qai/)
+- [Tutorial, “Accessibility testing strategies”](https://kilotest.com/tutorialWeb.html)
+- [Tutorial, “Connect an AI Platform”](https://kilotest.com/tutorialAI.html)
 
 ### API
 
@@ -200,11 +196,11 @@ More information about Kilotest features and internals:
 ### General
 
 - [Introduction to Kilotest](https://kilotest.com/)
-- [Tutorial, “Accessibility testing strategies”](https://kilotest.com/tutorial.html)
-- [Tutorial on authorizing language models to use Kilotest](https://kilotest.com/qai/)
+- [Tutorial, “Accessibility testing strategies”](https://kilotest.com/tutorialWeb.html)
+- [Tutorial on authorizing language models to use Kilotest](https://kilotest.com/tutorialAI.html)
 - [README file](https://github.com/jrpool/kilotest/blob/main/README.md)
 - [Summary of Kilotest capabilities](https://kilotest.com/capability.md)
 - [Testaro rule-engine orchestrator](https://github.com/YRA-Tech/testaro)
-- [Testaro rule classifier](https://github.com/YRA-Tech/testaro-issues)
+- [Testaro rule classifier](https://github.com/jrpool/testaro-issues)
 - [Research report on Testaro](https://arxiv.org/abs/2309.10167)
 - [Blog post on the Kilotest use case](https://medium.com/cvs-health-tech-blog/how-to-run-a-thousand-accessibility-tests-63692ad120c3)

package/llms.txt

@@ -1,6 +1,6 @@
 # Kilotest
 
-Kilotest helps language models and AI platforms to give thorough, accurate and truthful answers when users ask about the front-end quality (i.e. accessibility, usability, and web standards) of web pages. Kilotest integrates an ensemble of twelve independent rule engines to test a web page. Kilotest creates a structured report of the results and saves the report for future reference. Kilotest API endpoints and MCP tools can provide multipage, single-page, and element-level test results.
+Kilotest integrates an ensemble of 12 rule engines, with about 1,300 rules, to test web pages for front-end quality (accessibility, usability, and web standards, including HTML, CSS, ARIA, and WCAG, including HTML, CSS, ARIA, and WCAG). Each test job generates a standardized report describing which elements violated which rules and grouping the violations into about 380 issues. Kilotest can list the tested pages, the reports about each page, the issues in each report, the violators of each issue, and the diagnoses of each violation. Kilotest also accepts requests to test pages not yet tested and to retest already tested pages. Kilotest features are available via a web UI, an API, and an MCP server with streamable HTTP and no authentication.
 
 ## API
 
@@ -40,4 +40,4 @@ Kilotest helps language models and AI platforms to give thorough, accurate and t
 - [Privacy policy](https://kilotest.com/privacy.html)
 - [OpenAPI specification for Kilotest](https://kilotest.com/openapi.yaml)
 - [Kilotest as connector to and collection of AI Tools](https://github.com/jrpool/kilotest/blob/main/docs/AI-TOOLS.md)
-- [Tutorial on authorizing language models to use Kilotest](https://kilotest.com/qai/)
+- [Tutorial on authorizing language models to use Kilotest](https://kilotest.com/tutorialAI.html)

package/mcp.ts

@@ -54,12 +54,12 @@ export const mcpPath = '/mcp';
 // instructions and in the getKilotestOverview tool description (but not in the other tool
 // descriptions, to avoid diluting how models read each tool), because some MCP clients do
 // not propagate server-level instructions or the server description to their models.
-const sharedContext = 'Kilotest integrates an ensemble of 12 rule engines, with about 1,300 rules, to test web pages for front-end quality (accessibility, usability, and web standards). Each test job generates a standardized report describing which elements violated which rules and grouping the violations into about 380 issues. Kilotest can list the tested pages, the reports about each page, the issues in each report, the violators of each issue, and the diagnoses of each violation. Kilotest also accepts requests to test pages not yet tested and to retest already tested pages.';
+const sharedContext = 'Kilotest integrates an ensemble of 12 rule engines, with about 1,300 rules, to test web pages for front-end quality (accessibility, usability, and web standards, including HTML, CSS, ARIA, and WCAG). Each test job generates a standardized report describing which elements violated which rules and grouping the violations into about 380 issues. Kilotest can list the tested pages, the reports about each page, the issues in each report, the violators of each issue, and the diagnoses of each violation. Kilotest also accepts requests to test pages not yet tested and to retest already tested pages.';
 
 // Detailed overview of the Kilotest domain, data hierarchy, and tool workflow, returned by
 // the getKilotestOverview tool and served as the docs://kilotest/overview resource.
 const kilotestOverview = [
-  'Kilotest tests web pages for front-end quality: accessibility, usability, and web standards.',
+  'Kilotest tests web pages for front-end quality: accessibility, usability, and web standards, including HTML, CSS, ARIA, and WCAG.',
   'Kilotest integrates an ensemble of twelve independent rule engines to test a web page and stores the results as a structured report.',
   'Results are organized as a hierarchy. A tested page has one or more reports, from oldest to latest. A report contains issues. An issue has violators: elements of the tested page reported as exhibiting the issue. A violator has diagnoses: explanations from rule engines of how the element exhibited the issue.',
   'Typical workflow: call the listPages tool to learn whether the page has been tested. If it has, drill down from its latest report with the listIssues, listViolators, and listDiagnoses tools, or retrieve the entire report with the getReport tool. The listIssues output also lists all reports about the same page, so you can examine earlier reports. If the page has not been tested, request a test with the requestNewTest tool. If the latest report is obsolete, request a retest with the requestRetest tool.',
@@ -74,7 +74,7 @@ export const createMCPServer = (): McpServer => {
   const server = new McpServer({
     name: 'Kilotest',
     version,
-    description: 'Tools that test web pages for front-end quality (accessibility, usability, and web standards) and make test results available'
+    description: 'Tools that test web pages for front-end quality (accessibility, usability, and web standards, including HTML, CSS, ARIA, and WCAG) and make test results available'
   },
   {
     instructions: `${sharedContext} Use the listPages tool to start. If it shows that the page you want facts about has been tested, drill down from its latest report with the listIssues, listViolators, and listDiagnoses tools. If not, use the requestNewTest tool to request that the page be tested, or the orderNewTest tool for immediate, automatically approved testing. If the latest report about the page is obsolete, use the requestRetest tool to request that the page be retested, or the orderRetest tool for immediate, automatically approved retesting. For detailed documentation, call the getKilotestOverview tool.`

package/openapi.yaml

@@ -1,8 +1,8 @@
 openapi: 3.1.0
 info:
   title: Kilotest API
-  description: 'Kilotest is an ensemble testing and reporting service for front-end web quality. It uses an ensemble of 12 rule engines to test web pages for front-end quality (accessibility, usability, and web standards). Kilotest acts as a web server for human users, an MCP server for AI platforms, and an API for programmatic access. With this API you can request that a page be tested or retested, discover available reports, incrementally retrieve facts from a report: from what reports are available, to what issues were reported in one report, to what elements violated one issue, to what diagnoses rule engines gave for one violation.'
-  version: 59.1.0
+  description: 'Kilotest is an ensemble testing and reporting service for front-end web quality. It uses an ensemble of 12 rule engines to test web pages for front-end quality (accessibility, usability, and web standards, including HTML, CSS, ARIA, and WCAG). Kilotest acts as a web server for human users, an MCP server for AI platforms, and an API for programmatic access. With this API you can request that a page be tested or retested, discover available reports, incrementally retrieve facts from a report: from what reports are available, to what issues were reported in one report, to what elements violated one issue, to what diagnoses rule engines gave for one violation.'
+  version: 59.1.2
   license:
     name: MIT
     identifier: MIT

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jrpool/kilotest",
-  "version": "59.1.0",
+  "version": "59.1.2",
   "description": "Ensemble testing for front-end web quality",
   "type": "module",
   "main": "index.ts",
@@ -14,7 +14,7 @@
     "test": "c8 node --require ./test/setup.ts --experimental-test-module-mocks --test --test-concurrency=1 --test-randomize '**/*.test.ts'",
     "test:smoke": "node smokeTest.ts",
     "checkinfo": "node checkinfo.ts",
-    "generate:openapi": "node scripts/generate-openapi.ts"
+    "generate": "node scripts/generate-openapi.ts && node scripts/update-versions.ts"
   },
   "repository": {
     "type": "git",

package/scripts/generate-openapi.ts

@@ -58,7 +58,7 @@ const generate = () => {
     openapi: '3.1.0',
     info: {
       title: 'Kilotest API',
-      description: 'Kilotest is an ensemble testing and reporting service for front-end web quality. It uses an ensemble of 12 rule engines to test web pages for front-end quality (accessibility, usability, and web standards). Kilotest acts as a web server for human users, an MCP server for AI platforms, and an API for programmatic access. With this API you can request that a page be tested or retested, discover available reports, incrementally retrieve facts from a report: from what reports are available, to what issues were reported in one report, to what elements violated one issue, to what diagnoses rule engines gave for one violation.',
+      description: 'Kilotest is an ensemble testing and reporting service for front-end web quality. It uses an ensemble of 12 rule engines to test web pages for front-end quality (accessibility, usability, and web standards, including HTML, CSS, ARIA, and WCAG). Kilotest acts as a web server for human users, an MCP server for AI platforms, and an API for programmatic access. With this API you can request that a page be tested or retested, discover available reports, incrementally retrieve facts from a report: from what reports are available, to what issues were reported in one report, to what elements violated one issue, to what diagnoses rule engines gave for one violation.',
       version,
       license: {
         name: license,

package/scripts/update-versions.ts

@@ -0,0 +1,38 @@
+/*
+  update-versions.ts
+  Copies the version field of package.json into the version fields of server.json and lhm.plugin.json, keeping package.json the single source of truth for the Kilotest version.
+*/
+
+// IMPORTS
+
+import fs from 'node:fs';
+import path from 'node:path';
+import pkg from '../package.json' with {type: 'json'};
+
+// CONSTANTS
+
+const {version} = pkg;
+const targetFiles = ['server.json', 'lhm.plugin.json'];
+
+// FUNCTIONS
+
+// Replaces the version field of a JSON file with the package.json version, leaving all other content byte-for-byte unchanged.
+const updateVersion = (fileName: string): void => {
+  const filePath = path.join(import.meta.dirname, '..', fileName);
+  const content = fs.readFileSync(filePath, 'utf8');
+  const match = content.match(/^(\s*)"version": "([^"]+)"/m);
+  if (!match) {
+    throw new Error(`No version field found in ${fileName}`);
+  }
+  const oldVersion = match[2];
+  if (oldVersion === version) {
+    console.log(`${fileName} already at version ${version}`);
+    return;
+  }
+  fs.writeFileSync(filePath, content.replace(match[0], `${match[1]}"version": "${version}"`));
+  console.log(`Updated ${fileName} version: ${oldVersion} → ${version}`);
+};
+
+// EXECUTION
+
+targetFiles.forEach(updateVersion);

package/server.json

@@ -6,7 +6,7 @@
     "url": "https://github.com/jrpool/kilotest",
     "source": "github"
   },
-  "version": "59.1.0",
+  "version": "59.1.2",
   "remotes": [
     {
       "type": "streamable-http",

package/web/home/index.html

@@ -16,15 +16,15 @@
         "sameAs": "https://github.com/jrpool/kilotest",
         "datePublished": "2025-10-14",
         "dateModified": "2026-08-26",
-        "applicationCategory": "Front-end quality (i.e. accessibility, usability, and web standards) testing and reporting service",
+        "applicationCategory": "Front-end quality (i.e. accessibility, usability, and web standards, including HTML, CSS, ARIA, and WCAG) testing and reporting service",
         "isAccessibleForFree": true,
-        "description": "Testing of web pages for front-end quality (i.e. accessibility, usability, and web standards) with an ensemble of 12 rule engines and provision of results at selectable levels of detail.",
+        "description": "Testing of web pages for front-end quality (i.e. accessibility, usability, and web standards, including HTML, CSS, ARIA, and WCAG) with an ensemble of 12 rule engines and provision of results at selectable levels of detail.",
         "softwareHelp": {
           "@type": "CreativeWork",
           "url": "https://kilotest.com/tutorialWeb.html"
         },
         "featureList": [
-          "Automated testing of front-end quality (i.e. accessibility, usability, and web standards)",
+          "Automated testing of front-end quality (i.e. accessibility, usability, and web standards, including HTML, CSS, ARIA, and WCAG)",
           "WCAG 2.2 conformance evaluation",
           "HTML5 conformance evaluation",
           "CSS3 conformance evaluation",
@@ -62,7 +62,7 @@
       <details>
         <summary>More than a thousand? Really?</summary>
         <h2>Ensemble testing</h2>
-        <p>Kilotest does <strong>ensemble testing</strong> of web pages for <a href="https://www.w3.org/mission/accessibility/">accessibility</a>, usability, and web standards.</p>
+        <p>Kilotest does <strong>ensemble testing</strong> of web pages for <a href="https://www.w3.org/mission/accessibility/">accessibility</a>, usability, and web standards, including HTML, CSS, ARIA, and WCAG.</p>
         <p>Efficient testing <strong>first</strong> leverages <strong>automated rule engines</strong> and corrects the defects that they discover, <strong>then</strong> employs human testers.</p>
         <p>Choosing among the <a href="https://www.w3.org/WAI/test-evaluate/tools/list/">many automated rule engines</a> is hard, because they <a href="https://arxiv.org/pdf/2304.07591">vary in what and how they test</a>.</p>
         <p><strong>Ensemble testing</strong>, instead of choosing only one, combines <strong>multiple rule engines</strong>. It can discover more issues than single-rule-engine testing, and the rule engines can check one another&rsquo;s quality.</p>