Skip to main content
Glama

Open Components

by com.uxfront
OverviewDiscussionsAdmin

List Rules

list-rules
Read-onlyIdempotent

Lists checklist rules as records, filtered by component, ID, scope, layer, level or check. Each rule has a stable ID to cite in reviews and commits, its level (must or should), its scope, its requirement, how to check it (like a unit test, a review or axe's button-name rule) and a link to it.

WHEN TO USE: to review code rule by rule, to get only the rules that apply to a task, to look rules up by ID, or to find the ones a tool can check. Pass scope ["component", "both"] to build or review a component, and ["usage", "both"] to review a screen that uses it. WHEN NOT TO USE: for a component's API, DOM contract and tokens, use get-contract, which has every rule too.

It returns up to 50 rules at a time, and total counts every rule that matches. When there are more, pass nextOffset as offset, with the same filters, to get the next page.

A component meets the standard when it meets every must rule. Each should rule is expected unless there's a good reason not to follow it.

Input Schema

NameRequiredDescriptionDefault
idsNoThe IDs of the rules to look up, like ["button/keep-focus"].
checkNoHow the rule is checked.
layerNoui (how it looks), ux (user experience), dx (developer experience) or ax (agentic experience).
levelNo
limitNoHow many rules to return, at most.
scopeNoWho meets the rule: component (the component itself), usage (the code that uses it) or both. Rules without a scope, like the Design Tokens', match any scope.
offsetNoWhere the page starts: 0, or the nextOffset of the page before.
automatedNotrue for the rules tools check all of (unit tests, axe, a type check, a linter or a visual regression test), false for the ones a person checks, at least in part.
componentNoThe component or foundation, like button or design-tokens.

Output Schema

NameRequiredDescriptionDefault
rulesYes
totalYesHow many rules match, on every page.
unknownNoThe IDs asked for that no rule has, with the ones that might have been meant.
nextOffsetNoThe offset of the next page, when there is one.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / component / enum
      Previous value: -[
-  "design-tokens",
-  "button",
-  "card",
-  "checkbox-group",
-  "checkbox",
-  "dialog",
-  "input",
-  "popover",
-  "radio-group",
-  "spinner",
-  "switch",
-  "textarea",
-  "tooltip"
-]New value: +[
+  "design-tokens",
+  "button",
+  "card",
+  "checkbox-group",
+  "checkbox",
+  "dialog",
+  "field",
+  "input",
+  "popover",
+  "radio-group",
+  "spinner",
+  "switch",
+  "textarea",
+  "tooltip"
+]
  2. Changed1 schema field changed
    • changedInput schema / properties / component / enum
      Previous value: -[
-  "design-tokens",
-  "button",
-  "card",
-  "checkbox-group",
-  "checkbox",
-  "dialog",
-  "input",
-  "radio-group",
-  "spinner",
-  "switch",
-  "textarea",
-  "tooltip"
-]New value: +[
+  "design-tokens",
+  "button",
+  "card",
+  "checkbox-group",
+  "checkbox",
+  "dialog",
+  "input",
+  "popover",
+  "radio-group",
+  "spinner",
+  "switch",
+  "textarea",
+  "tooltip"
+]
  3. Changed1 schema field changed
    • changedInput schema / properties / component / enum
      Previous value: -[
-  "design-tokens",
-  "radio-group",
-  "button",
-  "card",
-  "checkbox-group",
-  "checkbox",
-  "dialog",
-  "input",
-  "spinner",
-  "switch",
-  "textarea",
-  "tooltip"
-]New value: +[
+  "design-tokens",
+  "button",
+  "card",
+  "checkbox-group",
+  "checkbox",
+  "dialog",
+  "input",
+  "radio-group",
+  "spinner",
+  "switch",
+  "textarea",
+  "tooltip"
+]
  4. Changed1 schema field changed
    • changedInput schema / properties / component / enum
      Previous value: -[
-  "design-tokens",
-  "button",
-  "card",
-  "checkbox-group",
-  "checkbox",
-  "dialog",
-  "input",
-  "spinner",
-  "switch",
-  "textarea",
-  "tooltip"
-]New value: +[
+  "design-tokens",
+  "radio-group",
+  "button",
+  "card",
+  "checkbox-group",
+  "checkbox",
+  "dialog",
+  "input",
+  "spinner",
+  "switch",
+  "textarea",
+  "tooltip"
+]
  5. Changed1 schema field changed
    • changedInput schema / properties / component / enum
      Previous value: -[
-  "design-tokens",
-  "button",
-  "spinner",
-  "input",
-  "card",
-  "checkbox",
-  "dialog",
-  "switch",
-  "textarea",
-  "tooltip",
-  "checkbox-group"
-]New value: +[
+  "design-tokens",
+  "button",
+  "card",
+  "checkbox-group",
+  "checkbox",
+  "dialog",
+  "input",
+  "spinner",
+  "switch",
+  "textarea",
+  "tooltip"
+]
  6. Changed1 schema field changed
    • changedInput schema / properties / component / enum
      Previous value: -[
-  "design-tokens",
-  "button",
-  "spinner",
-  "input",
-  "card",
-  "checkbox",
-  "switch",
-  "textarea",
-  "tooltip",
-  "checkbox-group"
-]New value: +[
+  "design-tokens",
+  "button",
+  "spinner",
+  "input",
+  "card",
+  "checkbox",
+  "dialog",
+  "switch",
+  "textarea",
+  "tooltip",
+  "checkbox-group"
+]
  7. Changed1 schema field changed
    • changedInput schema / properties / component / enum
      Previous value: -[
-  "design-tokens",
-  "button",
-  "spinner",
-  "input",
-  "card",
-  "checkbox",
-  "switch",
-  "textarea",
-  "tooltip"
-]New value: +[
+  "design-tokens",
+  "button",
+  "spinner",
+  "input",
+  "card",
+  "checkbox",
+  "switch",
+  "textarea",
+  "tooltip",
+  "checkbox-group"
+]
  8. Changed1 schema field changed
    • changedInput schema / properties / component / enum
      Previous value: -[
-  "design-tokens",
-  "button",
-  "spinner",
-  "input",
-  "card",
-  "checkbox",
-  "switch",
-  "tooltip"
-]New value: +[
+  "design-tokens",
+  "button",
+  "spinner",
+  "input",
+  "card",
+  "checkbox",
+  "switch",
+  "textarea",
+  "tooltip"
+]
  9. Changed1 schema field changed
    • changedInput schema / properties / component / enum
      Previous value: -[
-  "design-tokens",
-  "button",
-  "spinner",
-  "input",
-  "switch",
-  "tooltip"
-]New value: +[
+  "design-tokens",
+  "button",
+  "spinner",
+  "input",
+  "card",
+  "checkbox",
+  "switch",
+  "tooltip"
+]
  10. Changed1 schema field changed
    • changedInput schema / properties / component / enum
      Previous value: -[
-  "design-tokens",
-  "button",
-  "spinner",
-  "input",
-  "tooltip"
-]New value: +[
+  "design-tokens",
+  "button",
+  "spinner",
+  "input",
+  "switch",
+  "tooltip"
+]
  11. Changed1 schema field changed
    • changedInput schema / properties / component / enum
      Previous value: -[
-  "design-tokens",
-  "button",
-  "spinner",
-  "input"
-]New value: +[
+  "design-tokens",
+  "button",
+  "spinner",
+  "input",
+  "tooltip"
+]
  12. Changed4 schema fields changed
    • addedInput schema / properties / limit
      Added value: +{
+  "default": 50,
+  "description": "How many rules to return, at most.",
+  "maximum": 50,
+  "minimum": 1,
+  "type": "integer"
+}
    • addedInput schema / properties / offset
      Added value: +{
+  "default": 0,
+  "description": "Where the page starts: 0, or the nextOffset of the page before.",
+  "maximum": 9007199254740991,
+  "minimum": 0,
+  "type": "integer"
+}
    • addedOutput schema / properties / nextOffset
      Added value: +{
+  "description": "The offset of the next page, when there is one.",
+  "type": "number"
+}
    • addedOutput schema / properties / total / description
      Added value: +"How many rules match, on every page."
  13. First observed

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description layers on behavior they can't express: a 50-rule page cap, that `total` counts all matches, the exact pagination contract ('pass nextOffset as offset, with the same filters'), and the must/should compliance semantics for interpreting results.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Strongly front-loaded: identity, then WHEN TO USE / WHEN NOT TO USE, then pagination, then semantics. Most sentences earn their place, though the sentence enumerating returned rule fields loses some value against an existing output schema and costs a bit of length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter, fully optional, paginated list tool with an output schema and annotations, the description covers everything an agent still needs: filtering intent, pagination mechanics, scope choice, and how to interpret must versus should results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is high (89%), so the schema documents most parameters; the description adds selection guidance beyond it, notably which scope combinations to pass when building versus reviewing a screen. It doesn't cover every parameter (e.g. automated, layer) in prose, but the marginal value over the schema is real.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Lists checklist rules as records') plus the full set of filter dimensions, and explicitly disambiguates from get-contract ('for a component's API, DOM contract and tokens, use get-contract, which has every rule too'). An agent can select it without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit WHEN TO USE (rule-by-rule review, task-scoped rules, ID lookup, tool-checkable rules) and WHEN NOT TO USE naming the sibling to use instead. It even tells the agent which scope values to pass for the two most common review scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Open Components toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources