Skip to main content
Glama

Run Rego tests across multiple roots

rego_test_multiroot

Run OPA tests across multiple root directories to prevent package conflicts. Supports explicit root lists or automatic scanning, plus shared paths, coverage, and thresholds.

Instructions

Run opa test once per root and aggregate results. Solves the package-conflict problem that occurs when opa test . is run on a repo with multiple independent package namespaces (OPA issue #4724). Two modes: explicit (supply root list with optional per-root include paths for shared libraries) and scan (auto-discover leaf test roots using the leaf rule -- a directory is a root only if it directly contains *_test.rego files and none of its eligible subdirectories do, preventing OPA's automatic recursion from double-running tests). Use sharedPaths in scan mode to add shared library directories to every root's invocation without including them in discovery. Coverage and threshold work per-root; overallCoveragePct is the mean across roots that have coverage data.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rootsNoExplicit list of test root directories. Use when roots are known upfront or when scan mode cannot determine the correct roots. Mutually exclusive with `scanDir`.
scanDirNoTop-level directory to scan for test roots. Uses the leaf rule: a directory is a root only if it directly contains `*_test.rego` files and none of its eligible subdirectories do. Mutually exclusive with `roots`.
verboseNoEmit per-test pass/fail details for each root.
coverageNoInclude per-line coverage data per root. Switches output to coverage-report mode: test record counts are not available, but `coverage`, `coveragePct`, and `overallCoveragePct` fields are populated.
maxDepthNoMaximum directory depth to scan. Default: 10. Only used with `scanDir`.
maxRootsNoMaximum number of test roots allowed. Returns INVALID_INPUT if scan finds more. Default: 50. Only used with `scanDir`.
thresholdNoMinimum coverage percentage required per root (0-100). Roots below threshold have `thresholdMet: false` in their result. Implicitly enables coverage-report output mode.
varValuesNoInclude local variable bindings in trace output (`--var-values`). Only useful with `verbose: true`.
runPatternNoRun only tests whose names match this regular expression (passed as `--run` to each root).
sharedPathsNoPaths added to every root's `opa test` invocation and excluded from auto-discovery. Use for shared library directories that all roots import from.
ignorePatternsNoAdditional directory name patterns to skip during scan (e.g., ["vendor", "*.generated"]). Supports `*` wildcards. Only used with `scanDir`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.17

TDQS

A5/5.0
Behavior5/5

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

It discloses far more than the annotations provide: the exact leaf-rule heuristic, that `sharedPaths` are added to every invocation yet excluded from discovery, that coverage switches output mode and drops test record counts, that `overallCoveragePct` is the mean across roots with coverage data, and that exceeding `maxRoots` returns INVALID_INPUT. No contradiction with readOnlyHint=false or openWorldHint=true.

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 description is dense but every sentence earns its place for an 11-parameter, two-mode tool with a subtle leaf rule. It is front-loaded with the core verb and problem, then methodically explains modes, discovery semantics, and coverage aggregation without wasted words.

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?

Despite no output schema, the description names the key result fields (`coverage`, `coveragePct`, `overallCoveragePct`, `thresholdMet`), the error condition (INVALID_INPUT on maxRoots), and the per-mode behavior trade-offs. For a tool this complex with only minimal annotations, nothing an agent needs to invoke it correctly is left unspecified.

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

Parameters5/5

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

Schema coverage is 100%, yet the description adds genuine semantic value beyond the schema by explaining parameter interactions: `threshold` implicitly enables coverage mode, `roots` and `scanDir` are mutually exclusive, `sharedPaths` are excluded from auto-discovery, and `maxRoots` enforces a hard cap. It also explains the behavioral consequences of `coverage` on output fields, which the schema alone does not convey.

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 opens with a specific verb-resource pair — "Run `opa test` once per root and aggregate results" — that immediately establishes what the tool does. It further distinguishes itself from the sibling `rego_test` (single root) by naming the package-conflict problem (OPA issue #4724) it uniquely solves.

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?

The description gives explicit mode-selection criteria: use `explicit` when roots are known upfront or scan cannot determine them, and it precisely defines the leaf rule that governs `scan` mode. It frames the motivating scenario (when `opa test .` fails on multi-namespace repos), and the schema enforces mutual exclusion between `roots` and `scanDir`, so an agent can select the correct invocation path without inference.

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