Skip to main content
Glama

Run Rego tests across multiple roots

rego_test_multiroot
Read-onlyIdempotent

Run opa test across multiple roots to avoid package conflicts. Supports explicit root lists or automatic scan with leaf rule, shared paths, and per-root coverage 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`.
sharedPathsNoPaths added to every root's `opa test` invocation and excluded from auto-discovery. Use for shared library directories that all roots import from.
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`.
ignorePatternsNoAdditional directory name patterns to skip during scan (e.g., ["vendor", "*.generated"]). Supports `*` wildcards. Only used with `scanDir`.
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.
runPatternNoRun only tests whose names match this regular expression (passed as `--run` to each root).
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`.
Behavior5/5

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

The description adds extensive behavioral detail beyond annotations, including the leaf discovery rule, coverage mode switching, per-root threshold behavior, and interaction of parameters like `varValues` requiring `verbose`. No contradictions with annotations.

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?

The description is concise for the complexity, covering essential details in a few sentences. Could benefit from bullet points for the two modes, but the prose is clear and front-loaded with the core purpose.

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?

Given the complexity (11 parameters, two modes, scan logic, coverage nuances) and lack of output schema, the description thoroughly explains all necessary context for correct invocation, including edge cases like the leaf rule and mutual exclusivity of `roots` and `scanDir`.

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?

All 11 parameters have schema descriptions (100% coverage). The overall description adds contextual understanding of parameter interactions (e.g., `coverage` and `threshold` affecting output mode, `sharedPaths` excluded from scan). Slightly more structured parameter grouping would improve, but still adds value.

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 clearly states the tool runs `opa test` once per root and aggregates results, solving the package-conflict problem (OPA issue #4724). It distinguishes itself from sibling tools like `rego_test` by specifying multi-root handling.

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?

Explicitly describes two modes (`explicit` and `scan`) with their use cases, when each should be used, and mentions when to use alternative like `rego_test` for single roots. Provides clear context for `sharedPaths` and coverage options.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/OrygnsCode/opa-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server