Skip to content
Vispero CORADocs

cora-mcp-rules

list_rules’ result: the accessibility rules scan_page and scan_url run for the project, as its config’s rule selection sets them on the page at the call’s url, or where no route of the config sets its own. Each rule gives its ID, what it checks, its WCAG success criteria, its category, whether its findings fail the gate or are only reported, the config key that decided that, and the severity and fix class of the issues it finds.

Each version lists its fields, then a section for each object they hold, headed by its path, in which [] stands for each entry of a list. Where objects of several kinds share a path, each kind has a section, named by the field that tells them apart. A field marked required is in every object of its kind, and the description of any other says when it is absent.

Version 1

Section titled “Version 1”

The version this release writes. Its JSON Schema is schemas/cora-mcp-rules/v1.json in the @vispero/cora package and at https://cora.vispero.com/docs/0.10/schemas/cora-mcp-rules/v1.json.

  • format (“cora-mcp-rules”, required): The result’s format, always cora-mcp-rules.
  • version (1, required): The version of cora-mcp’s tool surface, which every result and error of its tools declares.
  • rules (array of objects, required): Every rule the config’s rule selection runs, on or report, on the page at the call’s url or where no route sets its own, sorted by ID; only those the call’s rules selectors name, when it gives some. A rule the selection turns off is not listed.

rules[]

Section titled “rules[]”
  • id (string, required): The rule’s ID: its engine’s prefix, then the rule’s own ID, such as axe/image-alt.
  • description (string, required): What the rule checks, in one line, such as Images must have alternative text. For a rule this cora does not know, as in a run another cora wrote that explain_finding reads, it is what that run recorded, cut short, ending with …, when it is long.
  • wcag (array of strings, required): The WCAG success criteria the rule checks, such as 1.1.1; empty for a best practice, whose failures are not WCAG failures. For a rule this cora does not know, they are those the run recorded, kept in order while the list has room.
  • severity (“critical”, “serious”, “moderate” or “minor”, required): How much the rule’s failures hinder people by default; a finding takes axe-core’s impact for its element where axe-core gives one. For a rule this cora does not know, it is the severity the run recorded for the issue’s first finding.
  • fixClass (“mechanical”, “content”, “design” or “manual”, required): What fixing the rule’s failures takes: its fix class, which the rules reference describes: https://cora.vispero.com/docs/reference/rules/#fix-classes
  • category (“aria”, “color”, “forms”, “keyboard”, “language”, “name-role-value”, “parsing”, “semantics”, “sensory-and-visual-cues”, “structure”, “tables”, “text-alternatives” or “time-and-media”, required): What the rule checks, as CORA groups rules, which a rule selector can name. The rules reference describes each category: https://cora.vispero.com/docs/reference/rules/#categories
  • setting (“on” or “report”, required): How the config’s rule selection runs the rule: on, so its new violations fail CI’s gate, or report, so its findings are shown but never fail the gate and are never baselined.
  • decidedBy (string, required): The config key that decided the setting, as an issue path names it, such as rules.standard, rules.bestPractices or routes[0].rules.overrides["axe/region"].