Skip to main content
Glama
OrygnsCode

opa-mcp-server

by OrygnsCode
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

Run Rego tests

rego_test
Read-onlyIdempotent

Run Rego unit tests through OPA, returning pass/fail/skip/error counts and per-test records; filter by name, enforce coverage thresholds, and debug table-driven test failures.

Instructions

Run Rego unit tests with opa test. Returns aggregate pass/fail/skip/error counts plus per-test records. errored counts tests OPA could not evaluate (a rule conflict, a raising built-in); such a test is neither a pass nor a failure, and a suite with any is not passing. Tests live in *_test.rego files; rule names beginning with test_ are picked up automatically. Use runPattern to filter by name regex; when no tests match, the error hint includes the pattern you supplied. Use threshold to gate on minimum coverage (returns COVERAGE_BELOW_THRESHOLD on failure). Use varValues: true with verbose: true to include local variable bindings in the trace -- essential for debugging table-driven tests written with every tc in cases { ... } to identify which case caused a failure. When tests use the test_x[case] parameterized form, OPA reports the rule as a single test whatever the number of cases; parameterizedGroups maps the rule name to a record per case and caseCounts totals them, so a failing rule says which case failed. Use ignorePatterns to exclude generated or fixture files. Use bundle: true when testing bundle-structured policy directories. Use timeout to raise the per-test limit beyond OPA's default 5s. Note: enabling coverage or threshold switches OPA to coverage-report output mode -- per-test counts are unavailable but coverage and coveragePct fields are populated.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
countNoNumber of times to repeat the suite (`--count N`). Default is 1. Useful for catching flaky tests. OPA stops at the first repetition that fails, so `repetitions` in the output reports how many actually ran, and each test is listed once carrying its worst outcome across them.
pathsYesTest directories or files. `opa test` looks for `*_test.rego` siblings of source files.
bundleNoLoad paths as OPA bundle roots (`--bundle`). Required when testing policies structured as bundles with a `manifest.json` at the root. Not needed for plain policy directories.
explainNoAdd a query-explanation trace to test records (`--explain`). `fails` traces only failing tests, `full` traces everything, `notes` surfaces `trace()` notes, `debug` is most verbose. Populates each record's `trace` field; pair with `verbose: true` for the human-readable trace output too.
timeoutNoPer-test timeout as a Go duration string, e.g. `"30s"` or `"2m"` (`--timeout`). OPA's default is 5s. Increase for tests that load large policy sets or call slow built-ins.
verboseNoEmit per-test pass/fail details.
coverageNoInclude per-line coverage data. Switches output to coverage-report mode: test record counts are not available, but `coverage` and `coveragePct` fields are populated.
thresholdNoMinimum coverage percentage required (0–100). Returns COVERAGE_BELOW_THRESHOLD when actual coverage falls below this value. Implicitly enables coverage-report output mode.
varValuesNoInclude local variable bindings in trace output (`--var-values`). When a table-driven test using `every tc in cases { ... }` fails, the trace shows which `tc` triggered the failure. Has no effect unless `verbose: true` is also set (OPA only emits trace entries in verbose mode).
runPatternNoRun only tests whose names match this regular expression (passed as `--run`).
v1CompatibleNoOpt in to OPA v1.0-compatible behaviors (`--v1-compatible`).
ignorePatternsNoGlob patterns for files to exclude from the test run (`--ignore <pattern>`). Pass one pattern per array element. Useful for excluding generated or fixture files that contain no tests (e.g. `["*_generated.rego", "fixtures/**"]`).

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changedv0.5.0
    • changedInput schema / properties / count / description
      Previous value: -"Number of times to repeat each test (`--count N`). Default is 1. Useful for measuring repeatability or catching flaky tests under load."New value: +"Number of times to repeat the suite (`--count N`). Default is 1. Useful for catching flaky tests. OPA stops at the first repetition that fails, so `repetitions` in the output reports how many actually ran, and each test is listed once carrying its worst outcome across them."
  2. Changed2 schema fields changedv0.1.20
    • addedInput schema / properties / explain
      Added value: +{
+  "description": "Add a query-explanation trace to test records (`--explain`). `fails` traces only failing tests, `full` traces everything, `notes` surfaces `trace()` notes, `debug` is most verbose. Populates each record's `trace` field; pair with `verbose: true` for the human-readable trace output too.",
+  "enum": [
+    "fails",
+    "full",
+    "notes",
+    "debug"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / v1Compatible
      Added value: +{
+  "description": "Opt in to OPA v1.0-compatible behaviors (`--v1-compatible`).",
+  "type": "boolean"
+}
  3. Changed4 schema fields changedv0.1.17
    • addedInput schema / properties / bundle
      Added value: +{
+  "description": "Load paths as OPA bundle roots (`--bundle`). Required when testing policies structured as bundles with a `manifest.json` at the root. Not needed for plain policy directories.",
+  "type": "boolean"
+}
    • addedInput schema / properties / count
      Added value: +{
+  "description": "Number of times to repeat each test (`--count N`). Default is 1. Useful for measuring repeatability or catching flaky tests under load.",
+  "minimum": 1,
+  "type": "integer"
+}
    • addedInput schema / properties / ignorePatterns
      Added value: +{
+  "description": "Glob patterns for files to exclude from the test run (`--ignore <pattern>`). Pass one pattern per array element. Useful for excluding generated or fixture files that contain no tests (e.g. `[\"*_generated.rego\", \"fixtures/**\"]`).",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / timeout
      Added value: +{
+  "description": "Per-test timeout as a Go duration string, e.g. `\"30s\"` or `\"2m\"` (`--timeout`). OPA's default is 5s. Increase for tests that load large policy sets or call slow built-ins.",
+  "type": "string"
+}
  4. Addedv0.1.13
  5. Removedv0.1.5
  6. Addedv0.1.2
  7. Removedv0.1.1
  8. First observedv0.1.0

TDQS

A4.2/5.0
Behavior5/5

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint, and the description adds substantial non-obvious behavior: `errored` tests are neither pass nor fail and a suite with any is not passing; enabling `coverage`/`threshold` switches to coverage-report mode which drops per-test counts; repeated runs stop at the first failing repetition; and parameterized `test_x[case]` rules are reported as a single test unless disambiguated via `parameterizedGroups`. These behaviors are invisible in the schema and are exactly what an agent needs to interpret results correctly.

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?

Front-loaded correctly with purpose and result shape in the first two sentences, and every subsequent clause carries real operational meaning. The length is mostly earned given 12 parameters, hidden mode interactions, and no output schema; however, several clauses duplicate schema text (timeout default, coverage-mode switch, threshold return value), and the single unbroken prose block scans harder than bulleted parameter guidance would.

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

Completeness4/5

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

With no output schema, the description carries the burden of explaining return values and does so well: errored counts, `parameterizedGroups`, `caseCounts`, `coverage`/`coveragePct`, `repetitions`, and `trace` are all named. Remaining gaps are minor: no guidance on when `v1Compatible` matters and no explicit note that multi-root suites belong to `rego_test_multiroot`.

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 description coverage is 100%, so the baseline is 3. The description adds genuine value beyond the schema: the table-driven-test debugging rationale for `varValues`, the error-hint-includes-pattern behavior for `runPattern`, and the `parameterizedGroups`/`caseCounts` interpretation for parameterized tests. Some overlap exists — `threshold`'s COVERAGE_BELOW_THRESHOLD return and the coverage-mode switch are restated from the schema — but the net addition justifies above baseline.

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

Purpose4/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 statement — 'Run Rego unit tests with `opa test`' — and immediately specifies the result shape (aggregate pass/fail/skip/error counts plus per-test records). It does not, however, distinguish itself from the closely overlapping sibling `rego_test_multiroot`, so an agent selecting between the two must infer the difference from the name alone.

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?

Rich conditional guidance at the parameter level: 'Use `runPattern` to filter by name regex', 'Use `bundle: true` when testing bundle-structured policy directories', 'Use `varValues: true` with `verbose: true`' for debugging table-driven tests, and 'Use `threshold` to gate on minimum coverage'. What's absent is tool-selection guidance — when to choose this over `rego_test_multiroot`, `rego_eval`, or `conftest_test`.

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