Skip to main content
Glama

List rules

list_rules
Read-only

Lists a ruleset's rules sorted by name and filters them by format, filename overrides, or enabled status so you can see which checks apply before linting.

Instructions

Lists a ruleset's rules, sorted by name. format keeps the rules that apply to documents of that format: oas3.1 includes rules for OpenAPI 3.1 and 3.x; oas3 includes rules for every OpenAPI 3 version. Rules that overrides in the ruleset add or turn off for a document are included when filename matches them. Use explain_rule for one rule in detail.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_rules"
  }
}

Input Schema

NameRequiredDescriptionDefault
formatNoA format such as oas2 (or swagger), oas3, oas3.1, asyncapi2, asyncapi3 or arazzo1.0
rulesetNoA ruleset name from list_rulesets (or oas, asyncapi, arazzo), or an inline YAML/JSON ruleset. Default: the default ruleset.
filenameNoA document name, such as "openapi.json", to include the rules the ruleset's overrides apply to it, as lint_document would. Never read. Default: document.yaml.
enabledOnlyNoOnly rules that lint_document runs

Output Schema

NameRequiredDescriptionDefault
rulesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already establish this as a read-only, non-open-world operation. The description adds useful behavioral detail beyond them: rules are sorted by name, format filtering has inheritance semantics, and override rules are included when filename matches.

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

Conciseness5/5

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

The core action is front-loaded in the first sentence, followed by compact details on format and overrides. The final sentence cleanly routes the agent to explain_rule, with no redundant wording.

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?

An output schema exists and all parameter descriptions are already complete. The description supplies the non-obvious cross-parameter behavior an agent needs to call the tool correctly, so nothing important is missing.

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 100%, so the schema already documents all four parameters. The description still adds meaning beyond the schema for format inheritance and filename-driven override inclusion, though it does not explain enabledOnly or ruleset defaults.

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?

The description states a specific verb and resource: it lists a ruleset's rules, sorted by name. It also distinguishes the detail use case by naming explain_rule as the alternative.

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

Usage Guidelines4/5

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

It explicitly routes single-rule details to explain_rule, giving clear usage context. However, it does not state when to choose list_rulesets, lint_document, or validate_ruleset, nor does it define exclusions.

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