# OPA MCP (oci · docker.io/orygn/opa-mcp)

Author, validate, debug, and explain OPA Rego policies through any MCP-compatible client.

- Trust score: 54/100 (low)
- Change this week: 0
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-11-05

## Components

- npm · `@orygn/opa-mcp`: 89/100, [markdown](https://verifymcp.io/servers/orygnscode-opa-mcp/orygn-opa-mcp.md), [page](https://verifymcp.io/servers/orygnscode-opa-mcp/orygn-opa-mcp)
- oci · `docker.io/orygn/opa-mcp`: 54/100 (this document), [markdown](https://verifymcp.io/servers/orygnscode-opa-mcp/docker-io-orygn-opa-mcp.md), [page](https://verifymcp.io/servers/orygnscode-opa-mcp/docker-io-orygn-opa-mcp)

## Channel facts

- Registry: `oci`
- Package: `docker.io/orygn/opa-mcp`
- Version: `0.9.1`
- Transport: `stdio`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-11-05.

- **Supply Chain Security**: 0/100
  - No malware scan is available for this kind of package: the supply-chain vendors we use do not cover it. This is a permanent gap in our coverage, not a finding about the package.
  - Known CVEs could not be checked: this artifact ships no SBOM or dependency manifest, so there is no dependency list to read.
  - Install-script risk not yet assessed.
  - Dependency health could not be checked: this artifact ships no SBOM or dependency manifest, so there is no dependency list to read.
- **Provenance & Transparency**: 48/100
  - Source repository is publicly reachable at the declared URL.
  - Provenance check failed: no build-provenance attestation is published.
  - Clear OSI-approved license (MIT).
  - Actively maintained (last published 12 days ago).
  - Publishes a security disclosure policy (SECURITY.md).
- **Schema Quality & AI Usability**: 76/100
  - 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 17133 tokens (~311/item across 55 items; 52 tools + 3 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 100/100
  - No destabilizing schema changes in the last 30 days.
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
- **Tool Safety**: 81/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - 2 of 8 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation; "rego_eval" implies "eval" and declares no destructiveHint at all, which the MCP spec reads as destructive by default.
  - An AI judge read all 54 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.

**Unverified: 1 category.** A category scored 0 because we could not verify it: a data source with nothing on this package, evidence we could not reach, or a check we could not run. We only credit what we can confirm.

## Install

### How do I install the OPA MCP server?

OPA MCP runs locally as a container image, launched with docker run --rm -i -e OPA_URL -e OPA_TOKEN -e GITHUB_TOKEN docker.io/orygn/opa-mcp:0.9.1. Ready-made configuration for Claude, Cursor, VS Code, Codex and 3 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add orygnscode-opa-mcp -- docker run --rm -i -e OPA_URL -e OPA_TOKEN -e GITHUB_TOKEN docker.io/orygn/opa-mcp:0.9.1
```

This image reads OPA_URL, OPA_TOKEN and GITHUB_TOKEN. Set them in your client's env block for this server; docker run -e passes each one through to the container.

### Cursor

```json
{
  "mcpServers": {
    "orygnscode-opa-mcp": {
      "command": "docker",
      "args": [
        "run",
        "--rm",
        "-i",
        "-e",
        "OPA_URL",
        "-e",
        "OPA_TOKEN",
        "-e",
        "GITHUB_TOKEN",
        "docker.io/orygn/opa-mcp:0.9.1"
      ]
    }
  }
}
```

This image reads OPA_URL, OPA_TOKEN and GITHUB_TOKEN. Set them in your client's env block for this server; docker run -e passes each one through to the container.

### VS Code

```json
{
  "servers": {
    "orygnscode-opa-mcp": {
      "command": "docker",
      "args": [
        "run",
        "--rm",
        "-i",
        "-e",
        "OPA_URL",
        "-e",
        "OPA_TOKEN",
        "-e",
        "GITHUB_TOKEN",
        "docker.io/orygn/opa-mcp:0.9.1"
      ]
    }
  }
}
```

This image reads OPA_URL, OPA_TOKEN and GITHUB_TOKEN. Set them in your client's env block for this server; docker run -e passes each one through to the container.

### Codex

```bash
codex mcp add orygnscode-opa-mcp -- docker run --rm -i -e OPA_URL -e OPA_TOKEN -e GITHUB_TOKEN docker.io/orygn/opa-mcp:0.9.1
```

This image reads OPA_URL, OPA_TOKEN and GITHUB_TOKEN. Set them in your client's env block for this server; docker run -e passes each one through to the container.

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "orygnscode-opa-mcp": {
      "type": "local",
      "command": [
        "docker",
        "run",
        "--rm",
        "-i",
        "-e",
        "OPA_URL",
        "-e",
        "OPA_TOKEN",
        "-e",
        "GITHUB_TOKEN",
        "docker.io/orygn/opa-mcp:0.9.1"
      ],
      "enabled": true
    }
  }
}
```

This image reads OPA_URL, OPA_TOKEN and GITHUB_TOKEN. Set them in your client's env block for this server; docker run -e passes each one through to the container.

### Hermes

```yaml
mcp_servers:
  orygnscode-opa-mcp:
    command: "docker"
    args: ["run", "--rm", "-i", "-e", "OPA_URL", "-e", "OPA_TOKEN", "-e", "GITHUB_TOKEN", "docker.io/orygn/opa-mcp:0.9.1"]
```

This image reads OPA_URL, OPA_TOKEN and GITHUB_TOKEN. Set them in your client's env block for this server; docker run -e passes each one through to the container.

### Netclaw

```json
{
  "McpServers": {
    "orygnscode-opa-mcp": {
      "Transport": "stdio",
      "Command": "docker",
      "Arguments": [
        "run",
        "--rm",
        "-i",
        "-e",
        "OPA_URL",
        "-e",
        "OPA_TOKEN",
        "-e",
        "GITHUB_TOKEN",
        "docker.io/orygn/opa-mcp:0.9.1"
      ]
    }
  }
}
```

This image reads OPA_URL, OPA_TOKEN and GITHUB_TOKEN. Set them in your client's env block for this server; docker run -e passes each one through to the container.

### Other

```json
{
  "mcpServers": {
    "orygnscode-opa-mcp": {
      "command": "docker",
      "args": [
        "run",
        "--rm",
        "-i",
        "-e",
        "OPA_URL",
        "-e",
        "OPA_TOKEN",
        "-e",
        "GITHUB_TOKEN",
        "docker.io/orygn/opa-mcp:0.9.1"
      ]
    }
  }
}
```

This image reads OPA_URL, OPA_TOKEN and GITHUB_TOKEN. Set them in your client's env block for this server; docker run -e passes each one through to the container.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-11-02 (score 54, 0)

- [security regression] Provenance: unverified → fail

### 2026-11-01 (score 54, 0)

- [security regression] Provenance: fail → unverified

### 2026-10-28 (score 54, 0)

- [security] Stability: 0.97 → pass

### 2026-10-27 (score 54, +1)

No change was recorded against any check on this day. Stability & Change Management went from 93 to 97. That category is still filling its 30-day observation window: 28 days of observed history at the previous scan, 29 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-26 (score 53, 0)

- [security regression] Provenance: unverified → fail

### 2026-10-25 (score 53, +1)

- [security regression] Provenance: fail → unverified

### 2026-10-23 (score 52, +1)

- [functional] Package version: 0.9.0 → 0.9.1

### 2026-10-21 (score 51, +1)

- [security regression] Provenance: unverified → fail

## MCP tools (52)

### `rego_format` (~187 tokens)

Format Rego

Format Rego source code using `opa fmt`. Returns the formatted source and a `changed` flag indicating whether the input was already canonical. When the source uses string interpolation ($"..." or $`...` syntax) and OPA v1.12.0 or v1.12.1 is detected, the tool warns about or blocks formatting due to a known OPA bug that corrupts \{ escape sequences (fixed in OPA v1.12.2).

Input parameters:

- `source` (string, required): Rego source code to format.
- `v0Compatible` (boolean): Format a policy written in pre-1.0 Rego as pre-1.0 Rego (`--v0-compatible`), leaving its syntax as it is. OPA 1.x otherwise refuses it. To convert it to Rego v1 instead, use `rego_migrate_v1`.

### `rego_check` (~352 tokens)

Check Rego

Type-check Rego with `opa check`. Returns `{ valid: true, errors: [] }` on success, or a list of structured diagnostics with file/line locations on failure. Provide either `source` for inline checking or `paths` for file/directory checking.

Input parameters:

- `bundle` (boolean): Load `paths` as bundle files or root directories (`--bundle`). Only valid with `paths`, not inline `source`.
- `capabilities` (string): Path to a capabilities JSON file restricting allowed builtins.
- `maxErrors` (integer): Maximum number of errors to collect before `opa check` aborts compilation (`--max-errors`, OPA default 10). Raise it to surface more diagnostics from a badly broken policy in a single pass.
- `paths` (array): Filesystem paths to check. Each path must be inside an allowed root (OPA_MCP_ALLOWED_PATHS).
- `schemaDir` (string): Schema directory for input/data validation.
- `source` (string): Inline Rego source. Mutually exclusive with `paths`.
- `strict` (boolean): Enable strict mode -- fail on unused vars, deprecated builtins, etc.
- `v0Compatible` (boolean): Read the policy as Rego v0 (`--v0-compatible`), the syntax OPA used before 1.0: rules without `if`, partial sets as `deny[msg] { ... }`. Needed for a policy that has not been migrated, which OPA 1.x…

### `rego_check_schema` (~509 tokens)

Check Rego against a JSON Schema

Validate that a Rego policy's input.* field references are consistent with a JSON Schema using `opa check --schema`. Every field the policy reads from `input` must exist in the schema; mismatches surface as rego_type_error diagnostics with file/line locations. Returns `{ valid: true, errors: [] }` when all references match the schema, or `{ valid: false, errors: [...] }` with structured diagnostics when they do not. Accepts the schema inline (pass the `schema` output of `rego_infer_input_schema` directly as `inlineSchema`) or as a path to a JSON Schema file on disk, or to a schema directory when the policy declares `schemas:` annotations (`schemaPath`). Provide `source` for inline Rego or `paths` for file/directory checking.

Input parameters:

- `inlineSchema` (object): JSON Schema (draft-07) object describing the expected shape of the `input` document. Mutually exclusive with `schemaPath`. Accepts the `schema` field from `rego_infer_input_schema` output directly.
- `paths` (array): Filesystem paths to policy files or directories to validate. Each path must be inside an allowed root (OPA_MCP_ALLOWED_PATHS). Mutually exclusive with `source`.
- `schemaPath` (string): Path to a JSON Schema file on disk to use for `input` validation, or to a schema directory when the policy carries `# METADATA` / `schemas:` annotations naming files in it (opa reads a directory only…
- `source` (string): Inline Rego source to validate against the schema. Mutually exclusive with `paths`.
- `strict` (boolean): Enable strict mode -- also fail on unused variables, deprecated builtins, and other non-fatal issues in addition to schema violations.
- `v0Compatible` (boolean): Read the policy as Rego v0 (`--v0-compatible`), the syntax OPA used before 1.0: rules without `if`, partial sets as `deny[msg] { ... }`. Needed for a policy that has not been migrated, which OPA 1.x…

### `rego_lint` (~289 tokens)

Lint Rego

Lint Rego source with the Regal linter. Returns categorized violations (style, bugs, idiomatic, performance) with file/line locations. Requires `regal` on PATH or `REGAL_BINARY` set; returns REGAL_NOT_FOUND otherwise. When called with inline `source`, location-bound rules whose verdict depends on the on-disk path (`directory-package-mismatch`) are auto-disabled to avoid temp-file false positives, and `location.file` is reported as `<inline>` instead of the randomized temp path. Re-enable those rules via `enable` if your workflow actually needs them.

Input parameters:

- `configFile` (string): Path to a Regal config file (defaults to .regal/config.yaml lookup).
- `disable` (array): Disable specific named rules.
- `disableCategory` (array): Disable entire rule categories (e.g. style, idiomatic, bugs).
- `enable` (array): Enable specific named rules.
- `enableCategory` (array): Enable entire rule categories.
- `failLevel` (string): Severity at which Regal returns a non-zero exit. Default: `error`.
- `ignoreFiles` (array): Glob patterns to skip.
- `paths` (array): Filesystem paths to lint. Each path must be inside an allowed root (OPA_MCP_ALLOWED_PATHS).
- `source` (string): Inline Rego source. Mutually exclusive with `paths`.

### `rego_parse_ast` (~179 tokens)

Parse Rego to AST

Parse Rego source to a JSON AST using `opa parse`. Returns the AST as a tree of nodes (package, imports, rules, expressions, terms). Use this when you need to introspect policy structure programmatically.

Input parameters:

- `source` (string, required): Rego source code to parse.
- `v0Compatible` (boolean): Read the policy as Rego v0 (`--v0-compatible`), the syntax OPA used before 1.0: rules without `if`, partial sets as `deny[msg] { ... }`. Needed for a policy that has not been migrated, which OPA 1.x…

### `rego_inspect` (~182 tokens)

Inspect bundle or policy

Inspect an OPA bundle, policy directory, or single Rego file with `opa inspect`. Returns manifest data, namespaces, rule annotations, and (if signed) signature metadata.

Input parameters:

- `target` (string, required): Path to a bundle archive (`*.tar.gz`), directory, or single Rego file.
- `v0Compatible` (boolean): Read the policy as Rego v0 (`--v0-compatible`), the syntax OPA used before 1.0: rules without `if`, partial sets as `deny[msg] { ... }`. Needed for a policy that has not been migrated, which OPA 1.x…

### `rego_capabilities` (~366 tokens)

OPA capabilities

Return OPA capabilities -- the available builtins, future keywords, features, and WASM ABI versions. With `current: true`, returns the running OPA's capabilities. With `version: "v1.19.0"`, returns those of a specific version. With neither, lists available named versions. By default (`names_only: true`), returns only builtin names and count to stay within response size limits. Pass `builtins: [...]` for the full type signatures and documentation of a few named builtins; `names_only: false` returns every full record, which needs OPA_MCP_MAX_RESPONSE_BYTES raised above its default.

Input parameters:

- `builtins` (array): Return the full record (type signature, documentation, metadata) for up to 100 builtin names, exact matches only. `matched` counts the records returned and names not found are listed under `missing`.…
- `current` (boolean): Print the capabilities of the currently installed OPA. Mutually exclusive with `version`.
- `names_only` (boolean): When true, or omitted, return only builtin names, count, future keywords, and features. The full payload for every builtin is larger than the default response cap (OPA_MCP_MAX_RESPONSE_BYTES), so `na…
- `version` (string): A specific OPA capabilities version (e.g. "v1.21.0"). When neither flag is set, lists available versions.

### `rego_deps` (~104 tokens)

Rego dependency analysis

Static dependency analysis for a Rego reference. Given a target ref like "data.example.allow", returns the base document references (input/data leaves) and virtual document references (rules) it depends on, transitively.

Input parameters:

- `paths` (array, required): Policy / data paths to load before computing dependencies. Each must be inside an allowed root (OPA_MCP_ALLOWED_PATHS).
- `ref` (string, required): Reference to compute dependencies for, e.g. "data.example.allow".

### `rego_migrate_v1` (~674 tokens)

Migrate Rego to v1 syntax

Migrate Rego v0 source to Rego v1. First renames what v1 reserves (a rule called `contains`, `every`, `if` or `in`, and every reference to it in the module) and replaces built-ins v1 removed: `re_match` and `net.cidr_overlap` by their v1 names, and `all`, `any`, `set_diff` and the `cast_*` family by a helper function appended to the module that returns exactly what the built-in did, so behaviour does not change. `re_match` and `net.cidr_overlap` get such a helper too where the rename would change behaviour: the module mocks one spelling with `with` while calling both, or binds `regex` or `net` itself. Then `opa fmt --rego-v1` converts the syntax (`if`, `contains`, `import rego.v1`) and `opa check` validates the result. `rewrites` lists each change by line and `notes` says why; a renamed rule must also be renamed in any other module that uses it. Pass `inputs` to evaluate the original as v0 and the result as v1 against each and compare every rule of the package, and `queries` to compare expressions too, such as calls to its functions; `equivalence` reports any difference. Evaluating runs the policy, `http.send` included. Returns the migrated source even when check finds remaining errors. A source that parses only as Rego v1 is returned unchanged; one that parses as both, such as v1 that imports `rego.v1`, is reformatted like any other. If the source parses as neither, returns `INVALID_REGO` with opa's own message.

Input parameters:

- `dataPaths` (array): Data files (JSON or YAML), or directories of them, to load on both sides when comparing `inputs`, for a policy that reads `data`. Without them every such reference is undefined on both sides, and the…
- `inputs` (array): Up to 20 input documents to check the migration against. The original is evaluated as Rego v0 and the migrated policy as Rego v1 against each one, every rule of the package that is not a function is…
- `queries` (array): Up to 10 Rego expressions to compare on each of `inputs` as well. A function has no value without arguments, so this is how functions are compared: `data.lib.names.label_ok(input.name, input.label)`.…
- `source` (string, required): Rego v0 source to migrate to Rego v1 syntax. Rules named with a word v1 reserves are renamed and built-ins v1 removed are replaced before `opa fmt --rego-v1` converts the syntax; any remaining issues…

### `rego_eval` (~516 tokens)

Evaluate Rego query

Evaluate a Rego query against a policy and an input document using `opa eval`. Returns the standard `{result: [...]}` shape plus `defined`, which is false when the query produced no value (undefined is not `false`), and `printed`, the lines the policy wrote with `print()`. The bread-and-butter authoring tool. The policy is optional, so a query alone tries out a built-in or an expression. Pass `inputs` to evaluate one query against many input documents in one call, and `v0Compatible` for a policy still written in pre-1.0 Rego.

Input parameters:

- `input`: Inline input document.
- `inputPath` (string): Path to a JSON input file. Mutually exclusive with `input`.
- `inputs` (array): Several input documents to evaluate the same query against, up to 50, in place of `input`/`inputPath`. The result is `batch`: one entry per input, in order, each holding that input's `result` (empty…
- `partial` (boolean): Run partial evaluation rather than full evaluation.
- `paths` (array): Policy / data file or directory paths. Each must be inside an allowed root.
- `query` (string, required): Rego query to evaluate, e.g. "data.example.allow".
- `source` (string): Inline Rego policy source. Optional: without `source` or `paths` the query runs on its own, which is enough to try a built-in or an expression.
- `strictBuiltinErrors` (boolean): Treat builtin errors as fatal instead of returning undefined.
- `unknowns` (array): Refs to treat as unknown during partial evaluation.
- `v0Compatible` (boolean): Read the policy as Rego v0 (`--v0-compatible`), the syntax OPA used before 1.0: rules without `if`, partial sets as `deny[msg] { ... }`. Needed for a policy that has not been migrated, which OPA 1.x…

### `rego_eval_with_explain` (~364 tokens)

Evaluate Rego with execution trace

Evaluate with `--explain=full` and return OPA's raw trace events (with their AST nodes) alongside the result. For a readable trace use `rego_explain_decision`, which renders the same events as lines. Raw events are large: over the response cap the bound-variable values are dropped first, then trailing events (`explanationTruncated`), and the result is kept.

Input parameters:

- `input`: Inline input document.
- `inputPath` (string): Path to a JSON input file. Mutually exclusive with `input`.
- `partial` (boolean): Run partial evaluation rather than full evaluation.
- `paths` (array): Policy / data file or directory paths. Each must be inside an allowed root.
- `query` (string, required): Rego query to evaluate, e.g. "data.example.allow".
- `source` (string): Inline Rego policy source. Optional: without `source` or `paths` the query runs on its own, which is enough to try a built-in or an expression.
- `strictBuiltinErrors` (boolean): Treat builtin errors as fatal instead of returning undefined.
- `unknowns` (array): Refs to treat as unknown during partial evaluation.
- `v0Compatible` (boolean): Read the policy as Rego v0 (`--v0-compatible`), the syntax OPA used before 1.0: rules without `if`, partial sets as `deny[msg] { ... }`. Needed for a policy that has not been migrated, which OPA 1.x…

### `rego_eval_with_profile` (~308 tokens)

Evaluate Rego with profiling

Evaluate with `--profile` and return per-rule timing and evaluation counts. Use this to find hot rules in slow policies.

Input parameters:

- `input`: Inline input document.
- `inputPath` (string): Path to a JSON input file. Mutually exclusive with `input`.
- `partial` (boolean): Run partial evaluation rather than full evaluation.
- `paths` (array): Policy / data file or directory paths. Each must be inside an allowed root.
- `query` (string, required): Rego query to evaluate, e.g. "data.example.allow".
- `source` (string): Inline Rego policy source. Optional: without `source` or `paths` the query runs on its own, which is enough to try a built-in or an expression.
- `strictBuiltinErrors` (boolean): Treat builtin errors as fatal instead of returning undefined.
- `unknowns` (array): Refs to treat as unknown during partial evaluation.
- `v0Compatible` (boolean): Read the policy as Rego v0 (`--v0-compatible`), the syntax OPA used before 1.0: rules without `if`, partial sets as `deny[msg] { ... }`. Needed for a policy that has not been migrated, which OPA 1.x…

### `rego_eval_with_coverage` (~310 tokens)

Evaluate Rego with coverage

Evaluate with `--coverage` and return per-line coverage data. Useful for verifying that tests actually exercise the rules they're meant to.

Input parameters:

- `input`: Inline input document.
- `inputPath` (string): Path to a JSON input file. Mutually exclusive with `input`.
- `partial` (boolean): Run partial evaluation rather than full evaluation.
- `paths` (array): Policy / data file or directory paths. Each must be inside an allowed root.
- `query` (string, required): Rego query to evaluate, e.g. "data.example.allow".
- `source` (string): Inline Rego policy source. Optional: without `source` or `paths` the query runs on its own, which is enough to try a built-in or an expression.
- `strictBuiltinErrors` (boolean): Treat builtin errors as fatal instead of returning undefined.
- `unknowns` (array): Refs to treat as unknown during partial evaluation.
- `v0Compatible` (boolean): Read the policy as Rego v0 (`--v0-compatible`), the syntax OPA used before 1.0: rules without `if`, partial sets as `deny[msg] { ... }`. Needed for a policy that has not been migrated, which OPA 1.x…

### `rego_test` (~978 tokens)

Run Rego tests

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 parameters:

- `bundle` (boolean): 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.
- `count` (integer): 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 actuall…
- `coverage` (boolean): Include per-line coverage data. Switches output to coverage-report mode: test record counts are not available, but `coverage` and `coveragePct` fields are populated.
- `explain` (string): 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 rec…
- `ignorePatterns` (array): 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. `["*_gener…
- `paths` (array, required): Test directories or files. `opa test` looks for `*_test.rego` siblings of source files.
- `runPattern` (string): Run only tests whose names match this regular expression (passed as `--run`).
- `threshold` (number): Minimum coverage percentage required (0–100). Returns COVERAGE_BELOW_THRESHOLD when actual coverage falls below this value. Implicitly enables coverage-report output mode.
- `timeout` (string): 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.
- `v0Compatible` (boolean): Read the policy as Rego v0 (`--v0-compatible`), the syntax OPA used before 1.0: rules without `if`, partial sets as `deny[msg] { ... }`. Needed for a policy that has not been migrated, which OPA 1.x…
- `v1Compatible` (boolean): Opt in to OPA v1.0-compatible behaviors (`--v1-compatible`).
- `varValues` (boolean): Include 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 unl…
- `verbose` (boolean): Emit per-test pass/fail details.

### `rego_test_multiroot` (~672 tokens)

Run Rego tests across multiple roots

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 parameters:

- `coverage` (boolean): Include 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.
- `ignorePatterns` (array): Additional directory name patterns to skip during scan (e.g., ["vendor", "*.generated"]). Supports `*` wildcards. Only used with `scanDir`.
- `maxDepth` (integer): Maximum directory depth to scan. Default: 10. Only used with `scanDir`.
- `maxRoots` (integer): Maximum number of test roots allowed. Returns INVALID_INPUT if scan finds more. Default: 50. Only used with `scanDir`.
- `roots` (array): Explicit list of test root directories. Use when roots are known upfront or when scan mode cannot determine the correct roots. Mutually exclusive with `scanDir`.
- `runPattern` (string): Run only tests whose names match this regular expression (passed as `--run` to each root).
- `scanDir` (string): Top-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 w…
- `sharedPaths` (array): Paths added to every root's `opa test` invocation and excluded from auto-discovery. Use for shared library directories that all roots import from.
- `threshold` (number): Minimum coverage percentage required per root (0-100). Roots below threshold have `thresholdMet: false` in their result. Implicitly enables coverage-report output mode.
- `v0Compatible` (boolean): Read the policy as Rego v0 (`--v0-compatible`), the syntax OPA used before 1.0: rules without `if`, partial sets as `deny[msg] { ... }`. Needed for a policy that has not been migrated, which OPA 1.x…
- `varValues` (boolean): Include local variable bindings in trace output (`--var-values`). Only useful with `verbose: true`.
- `verbose` (boolean): Emit per-test pass/fail details for each root.

### `rego_bench` (~280 tokens)

Benchmark Rego query

Benchmark a Rego query against a policy + input with `opa bench`. Returns statistical timing data: iterations, ns/op, and allocation counts. Use this to spot slow rules.

Input parameters:

- `count` (integer): Number of times to repeat the benchmark (`--count N`). Defaults to OPA's built-in default of one. Above one, every repetition is returned in `runs`, `fastest` indexes the one the top-level figures co…
- `input`: Inline input document.
- `inputPath` (string): Path to a JSON input file.
- `paths` (array): Policy / data paths to load. Each must be in an allowed root.
- `query` (string, required): Rego query to benchmark.
- `v0Compatible` (boolean): Read the policy as Rego v0 (`--v0-compatible`), the syntax OPA used before 1.0: rules without `if`, partial sets as `deny[msg] { ... }`. Needed for a policy that has not been migrated, which OPA 1.x…

### `rego_compile_query` (~349 tokens)

Partially evaluate a Rego query

Run partial evaluation on a query -- substitute known values and return the residual policy. Defaults `unknowns` to `["input"]` (treat input as unknown), so the residual encodes "given input X, this is what would have to be true." Use this for offline policy slicing or pre-computing decision sets.

Input parameters:

- `input`: Inline input document.
- `inputPath` (string): Path to a JSON input file. Mutually exclusive with `input`.
- `partial` (boolean): Run partial evaluation rather than full evaluation.
- `paths` (array): Policy / data file or directory paths. Each must be inside an allowed root.
- `query` (string, required): Rego query to evaluate, e.g. "data.example.allow".
- `source` (string): Inline Rego policy source. Optional: without `source` or `paths` the query runs on its own, which is enough to try a built-in or an expression.
- `strictBuiltinErrors` (boolean): Treat builtin errors as fatal instead of returning undefined.
- `unknowns` (array): Refs to treat as unknown during partial evaluation.
- `v0Compatible` (boolean): Read the policy as Rego v0 (`--v0-compatible`), the syntax OPA used before 1.0: rules without `if`, partial sets as `deny[msg] { ... }`. Needed for a policy that has not been migrated, which OPA 1.x…

### `opa_exec` (~794 tokens)

Batch-evaluate OPA policy against input files

Evaluate a policy decision against one or more input files using `opa exec --format=json`. Unlike `rego_eval` (single input), `opa exec` processes every file independently and returns a per-file result -- ideal for CI pipelines that check many config files against a policy in one call. Supply `bundle` for a bundle, or `dataPaths` for plain `.rego`, JSON and YAML files and directories, which are loaded as `opa eval --data` loads them; the two are mutually exclusive. Each file that fails evaluation appears in `results` with an `error` field rather than a `result` field. Set one of `fail`/`failDefined`/`failNonEmpty` to turn the call into a CI gate: the result then reports `failed: true` (instead of erroring) when the gate condition is met.

Input parameters:

- `bundle` (string): Path to an OPA bundle directory or `.tar.gz` archive to load as the policy source. Mutually exclusive with `dataPaths`.
- `dataPaths` (array): Policy and data files or directories, loaded the way `opa eval --data` loads them: a `.rego` file as a module, a JSON or YAML file merged into the data root, a directory recursively, so every JSON an…
- `decision` (string, required): The policy entrypoint to evaluate for each input, e.g. `"authz/allow"`. `opa exec` names a decision by slash-separated path with no `data.` prefix; the Rego reference forms (`data.authz.allow`, `auth…
- `fail` (boolean): CI gate: report `failed: true` when any decision is undefined or errors. Mutually exclusive with `failDefined` and `failNonEmpty`.
- `failDefined` (boolean): CI gate: report `failed: true` when any decision is defined or errors. Use when a defined result means a violation. Mutually exclusive with `fail` and `failNonEmpty`.
- `failNonEmpty` (boolean): CI gate: report `failed: true` when any decision result is non-empty or errors. Mutually exclusive with `fail` and `failDefined`.
- `inputPaths` (array, required): One or more JSON/YAML input file paths, or a directory containing input files. OPA evaluates each file independently. Every path must be inside an allowed root.
- `timeout` (string): Per-exec evaluation timeout as a Go duration, e.g. `"30s"` or `"5m"`. Still bounded by the server subprocess timeout (OPA_MCP_TIMEOUT_MS).
- `v0Compatible` (boolean): Read the policy as Rego v0 (`--v0-compatible`), the syntax OPA used before 1.0: rules without `if`, partial sets as `deny[msg] { ... }`. Needed for a policy that has not been migrated, which OPA 1.x…
- `v1Compatible` (boolean): Opt in to OPA v1.0-compatible behaviors (`--v1-compatible`).

### `opa_bundle_build` (~601 tokens)

Build OPA bundle

Build a deployable bundle from policy / data paths using `opa build`. Output is a `.tar.gz` archive with optional inline signing. Supports optimization, custom revision strings, and the WASM target.

Input parameters:

- `bundle` (boolean): Load `paths` as bundle files or root directories (`--bundle`). Implied by `signingKey` and `verificationKey`; set it explicitly to rebuild an existing bundle without signing.
- `capabilities` (string): Path to a capabilities JSON file.
- `claimsFile` (string): Path to a claims file for inline signing.
- `entrypoints` (array): Entrypoint refs (required when `target=wasm` or `optimize > 0`).
- `ignore` (array): File/directory name patterns to ignore during loading (`--ignore`), e.g. `[".*"]` to skip hidden files. These are name patterns, not filesystem paths.
- `optimize` (number): Optimization level (0 = none, 2 = aggressive).
- `output` (string, required): Output bundle path (typically `*.tar.gz`). Must be in an allowed root.
- `paths` (array, required): Policy / data paths to include. Each must be in an allowed root.
- `pruneUnused` (boolean): Exclude dependents of entrypoints that are not reachable from them (`--prune-unused`). Most useful alongside `entrypoints`.
- `revision` (string): Bundle revision string written to the manifest.
- `signingAlg` (string): Signing algorithm (e.g. RS256).
- `signingKey` (string): Path to a PEM private key for signing the built bundle (`--signing-key`). Implies `bundle: true`, which OPA requires for signing.
- `target` (string): Build target (default `rego`; `wasm` compiles to WebAssembly).
- `v0Compatible` (boolean): Read the policy as Rego v0 (`--v0-compatible`), the syntax OPA used before 1.0: rules without `if`, partial sets as `deny[msg] { ... }`. Needed for a policy that has not been migrated, which OPA 1.x…
- `v1Compatible` (boolean): Opt in to OPA v1.0-compatible behaviors (`--v1-compatible`). Affects the built bundle's runtime semantics.
- `verificationKey` (string): Path to a PEM public key (or HMAC secret file) used to re-verify an existing signed bundle during the build (`--verification-key`). Implies `bundle: true`, which OPA requires for verification.
- `verificationKeyId` (string): Key ID for verification (`--verification-key-id`, OPA default `default`).

### `opa_bundle_sign` (~352 tokens)

Sign OPA bundle

Sign a bundle directory with `opa sign`. A directory is signed in place: `.signatures.json` is written into it and files are recorded as `<directory name>/<file>`, so the signed directory verifies wherever it is placed as long as its name is unchanged, with `opa_bundle_verify` or with `opa build` or `opa run --bundle <name>` from its parent. An archive is refused: OPA reads the signature from inside it, so a signed archive comes from `opa_bundle_build` with `signingKey`. The key is a PEM private key (RSA or ECDSA); for HMAC algorithms pass a file holding the secret. Extra claims such as `keyid` and `scope` come from `claimsFile`. Returns the path written, the algorithm, and the number of files covered.

Input parameters:

- `bundle` (string, required): Path to a bundle directory. Must be inside an allowed root. An archive is refused, since OPA reads the signature from inside it; build a signed archive with `opa_bundle_build` and `signingKey`.
- `claimsFile` (string): Path to a JSON file of extra claims to sign, such as {"keyid": "...", "scope": "..."}. Must be inside an allowed root.
- `signingAlg` (string): Signing algorithm: RS256 (default), RS384, RS512, PS256, PS384, PS512, ES256, ES384, ES512, HS256, HS384, HS512.
- `signingKey` (string, required): Path to the PEM private key (RSA or ECDSA), or for HMAC algorithms a file holding the secret. Must be inside an allowed root.

### `opa_bundle_verify` (~512 tokens)

Verify OPA bundle signature

Verify the signature of a signed bundle directory or `.tar.gz` archive with the public key. OPA has no standalone verify command, so this runs `opa build --verification-key` into a private temp file that is discarded. A directory is verified by name from its parent, matching how `opa_bundle_sign` signs it. OPA reads the key, checks the JWT in `.signatures.json`, compares the scope claim, then checks every file: Rego files by digest before parsing, data files and `.manifest` by parsed value, so an unparseable data file fails before its digest is compared. Failures return `INVALID_BUNDLE` with `details.reason` set to one of signature_invalid, scope_mismatch, file_modified, file_added, file_missing, file_unparseable, unsigned, signatures_malformed, not_a_bundle, bundle_load_error, or unknown when the message is not recognised; the raw output is in `details`. A key or algorithm OPA cannot use returns `INVALID_INPUT`. Pass `scope` exactly as the bundle was signed with. With a single key OPA does not check `verificationKeyId` against the signature keyid claim. `verified: true` is returned only when OPA loaded the bundle with its signature intact.

Input parameters:

- `bundle` (string, required): Path to the signed bundle directory or `.tar.gz` archive. Must be inside an allowed root.
- `scope` (string): Expected `scope` claim in the signature. Pass exactly the value the bundle was signed with, and nothing if it was signed without one; the failure reason is scope_mismatch otherwise.
- `signingAlg` (string): Signing algorithm used when the bundle was signed (e.g. `RS256`, `PS256`, `ES256`, `HS256`). Defaults to `RS256`.
- `v0Compatible` (boolean): Load the bundle as Rego v0 (`--v0-compatible`). A policy written before Rego v1 otherwise fails to load, after the signature and digests have already been checked.
- `verificationKey` (string, required): Path to the PEM file containing the RSA or ECDSA public key, or for HMAC algorithms a file holding the secret. Must be inside an allowed root.
- `verificationKeyId` (string): Name the key is registered under for OPA (`--verification-key-id`, default `default`). With a single key OPA verifies against it regardless of the signature keyid claim, so this rarely needs setting.

### `opa_list_policies` (~151 tokens)

List OPA policies

List policies registered on the running OPA server. Returns the policy IDs and a count. Set `includeSource` for the Rego text of every policy, or `includeAst` for the parsed AST of every policy; both are off by default because either one pushes a list of any real size past the response cap.

Input parameters:

- `includeAst` (boolean): Include each policy's parsed AST. Off by default; it is roughly forty times the size of the source and will exceed the response cap on all but the smallest servers.
- `includeSource` (boolean): Include each policy's Rego source. Off by default: fetch one policy with `opa_get_policy` rather than every policy at once.

### `opa_get_policy` (~112 tokens)

Get OPA policy by ID

Fetch a single policy by ID from the running OPA server. Returns the Rego source; the parsed AST is omitted unless asked for, since it is roughly forty times the size of the source it came from. Use `rego_parse_ast` on the source when an AST is what's wanted.

Input parameters:

- `id` (string, required): Policy ID, e.g. "rbac" or "policies/auth/main".
- `includeAst` (boolean): Include OPA's parsed AST alongside the source. Off by default.

### `opa_put_policy` (~102 tokens)

Upload or replace OPA policy

Upload a Rego policy under the given ID. Replaces any existing policy with that ID; `replaced` says whether one existed. The policy is uploaded as raw text/plain and OPA compiles it on the server, so a policy that does not compile comes back as INVALID_REGO with OPA's errors, and nothing is stored.

Input parameters:

- `id` (string, required): Policy ID to create or replace.
- `source` (string, required): Rego source.

### `opa_delete_policy` (~32 tokens)

Delete OPA policy

Delete a policy by ID from the running OPA server.

Input parameters:

- `id` (string, required): Policy ID to delete.

### `opa_get_data` (~147 tokens)

Read data from OPA

Read a path from OPA's data hierarchy. A `path` is read as dotted (`users.alice`) unless it contains a slash, in which case slash is the only separator (`users/alice`), so a key such as `example.com` is addressable as `hosts/example.com`. Pass `segments` instead when a key contains both.

Input parameters:

- `path` (string): Data path under `data.`, e.g. "users" or "users/alice".
- `segments` (array): Path as literal key segments, e.g. ["labels", "app.kubernetes.io/name"]. Use instead of `path` when a key contains a dot or a slash.

### `opa_put_data` (~153 tokens)

Write data to OPA

Write or replace a value at the given data path. Body is sent as JSON. A `path` is read as dotted (`users.alice`) unless it contains a slash, in which case slash is the only separator (`users/alice`), so a key such as `example.com` is addressable as `hosts/example.com`. Pass `segments` instead when a key contains both.

Input parameters:

- `path` (string): Data path to write to.
- `segments` (array): Path as literal key segments, e.g. ["labels", "app.kubernetes.io/name"]. Use instead of `path` when a key contains a dot or a slash.
- `value`: JSON value to store at this path.

### `opa_patch_data` (~134 tokens)

Patch data on OPA

Apply a JSON Patch (RFC 6902) to the data document. Each operation is `{ op, path, value? }`. Omit both `path` and `segments` to patch the root of the data hierarchy, which is how a whole new top-level document is added.

Input parameters:

- `operations` (array, required): Array of JSON Patch operations.
- `path` (string): Data path the patch is applied to.
- `segments` (array): Path as literal key segments, e.g. ["labels", "app.kubernetes.io/name"]. Use instead of `path` when a key contains a dot or a slash.

### `opa_delete_data` (~215 tokens)

Delete a data document from OPA

Remove a document from OPA's data store at the given path. A `path` is read as dotted (`users.alice`) unless it contains a slash, in which case slash is the only separator (`users/alice`), so a key such as `example.com` is addressable as `hosts/example.com`. Pass `segments` instead when a key contains both. OPA responds with 204 No Content on success; if no document exists at the path, OPA returns 404 which is mapped to `DATA_NOT_FOUND`. Root-path deletion (`/v1/data/` itself) is intentionally excluded -- supply at least one path segment.

Input parameters:

- `path` (string): Data path to delete, e.g. "users.alice" or "users/alice". Must be at least one segment deep.
- `segments` (array): Path as literal key segments, e.g. ["labels", "app.kubernetes.io/name"]. Use instead of `path` when a key contains a dot or a slash.

### `opa_query_decision` (~207 tokens)

Query OPA decision

Evaluate a decision against the running OPA server. POSTs to the data path with `{input}` and returns whatever the rule produces, plus `defined`: false when the path produced no value, which OPA reports by leaving `result` out. Undefined is not `false`; a caller that treats it as false or as allow decides on something the policy never said. Use this to ask the server "given this input, what does data.X.allow say?"

Input parameters:

- `explain` (string): Include a trace at the requested level.
- `input`: Input document to evaluate against.
- `metrics` (boolean): Include metrics in the response.
- `path` (string): Decision path under `data.`, e.g. "rbac/allow" or "rbac.allow".
- `segments` (array): Path as literal key segments, e.g. ["labels", "app.kubernetes.io/name"]. Use instead of `path` when a key contains a dot or a slash.

### `opa_compile_query` (~96 tokens)

Compile (partially evaluate) a query on OPA

Send a query to the OPA server's `/v1/compile` endpoint for partial evaluation. Returns the residual query -- what remains after substituting in everything that's known.

Input parameters:

- `input`: Optional partial input document.
- `query` (string, required): Rego query to compile, e.g. "data.rbac.allow == true".
- `unknowns` (array): Refs to treat as unknown (default: ["input"]).

### `opa_health` (~127 tokens)

OPA health check

Hit the OPA `/health` endpoint. A server that answers reports `{ healthy: true }` on 200 and `{ healthy: false }` with OPA's own reason otherwise, so an unactivated bundle is a health result rather than a tool error. `OPA_UNREACHABLE` means the server could not be reached at all. Supports `bundles` and `plugins` query flags to require those subsystems to also be healthy.

Input parameters:

- `bundles` (boolean): Require bundle plugin to be healthy as well.
- `plugins` (boolean): Require all plugins to be healthy.

### `opa_status` (~113 tokens)

OPA status

Return the running OPA server configuration via `GET /v1/config`. Returns the same underlying document as `opa_config` but presented under a `status` key as a convenience for agents that want to check "what is running" rather than "what was the server configured with". The response includes bundle settings, decision-log settings, and plugin configuration as OPA reported them at startup. Service header values are redacted, since OPA returns them verbatim and a header is the ordinary place to put an API key.

### `opa_config` (~70 tokens)

OPA configuration

Return the running OPA server configuration from `GET /v1/config`. OPA drops the `credentials` block but returns `services.*.headers` verbatim, which is the ordinary place to put an API key or a bearer token, so those values are redacted here and the header names kept.

### `rego_explain_decision` (~419 tokens)

Explain Rego decision

Evaluate a Rego query with full tracing and return the result, the rules entered (`rulesEvaluated`) and those that produced a value (`rulesFired`), and the trace as readable lines: location, nesting, operation, the expression in Rego syntax, and the values of the variables it names. Backtracking (Redo) events are left out. Use it to answer "why was this denied?" or "why did this rule not match?": the `Fail` lines name the condition that stopped a rule. A trace too long for the response cap is cut from the end (`traceTruncated`); narrow the query or the input to see the rest.

Input parameters:

- `input`: Inline input document.
- `inputPath` (string): Path to a JSON input file. Mutually exclusive with `input`.
- `partial` (boolean): Run partial evaluation rather than full evaluation.
- `paths` (array): Policy / data file or directory paths. Each must be inside an allowed root.
- `query` (string, required): Rego query to evaluate, e.g. "data.example.allow".
- `source` (string): Inline Rego policy source. Optional: without `source` or `paths` the query runs on its own, which is enough to try a built-in or an expression.
- `strictBuiltinErrors` (boolean): Treat builtin errors as fatal instead of returning undefined.
- `unknowns` (array): Refs to treat as unknown during partial evaluation.
- `v0Compatible` (boolean): Read the policy as Rego v0 (`--v0-compatible`), the syntax OPA used before 1.0: rules without `if`, partial sets as `deny[msg] { ... }`. Needed for a policy that has not been migrated, which OPA 1.x…

### `rego_explain_undefined` (~438 tokens)

Explain why a Rego query is undefined

Diagnose why a fully-qualified Rego query (e.g. "data.authz.allow") produces no value, or falls back to its default. Combines a plain eval, a full-trace eval, and per-condition AST analysis to identify the exact body expression blocking each rule. Handles both runtime failures (trace-based) and indexer elimination (standalone condition eval). A rule written with `default allow := false` always has a value, so `queryResult` reports `default` for it and the same per-rule breakdown follows: the question "why is allow false" is the question this answers. A multi-value rule such as `deny contains msg if ...` that holds no element reports `empty` with the same breakdown, which answers "why was this not denied". Returns a structured breakdown of which conditions blocked each rule plus a human-readable summary. `paths` may name directories, which are searched for the modules that declare the queried package.

Input parameters:

- `input`: Input document (JSON value) for the query.
- `inputPath` (string): Path to an input JSON file.
- `paths` (array): Policy and data paths to load, as for rego_eval: .rego files, data files, or directories (walked for .rego files). Mutually exclusive with source.
- `query` (string, required): Fully-qualified rule reference to explain, e.g. "data.authz.allow". Must match the path you would pass to rego_eval.
- `source` (string): Inline Rego source to analyse. Mutually exclusive with paths.
- `v0Compatible` (boolean): Read the policy as Rego v0 (`--v0-compatible`), the syntax OPA used before 1.0: rules without `if`, partial sets as `deny[msg] { ... }`. Needed for a policy that has not been migrated, which OPA 1.x…

### `rego_generate_test_skeleton` (~356 tokens)

Generate Rego test skeleton

Generate a `*_test.rego` skeleton from a policy. Parses the AST, finds each non-test rule, and emits one stub test per rule. Existing `test_*` and `todo_test_*` rules are skipped automatically -- only production rules get stubs. Every stub is a `todo_test_` rule, which `opa test` reports as skipped (and exits non-zero for) until a realistic input and the expected value are filled in and it is renamed `test_`: a placeholder input against a placeholder expectation would otherwise pass while testing nothing. The AST is walked to infer which `input.*` fields the policy accesses; the inferred shape is used as the placeholder `with input as {...}` in each stub, so the developer only needs to fill in realistic values rather than guess the structure. With `tableStyle: true`, each stub uses an `every tc in cases { ... }` loop so you can add multiple input/expected pairs without duplicating assertion code. The `inferredInputShape` field in the response shows the detected shape for reference.

Input parameters:

- `source` (string, required): Rego source to generate tests for.
- `tableStyle` (boolean): Generate table-driven test stubs instead of single-case stubs. Each rule gets a `cases` array and an `every tc in cases { ... }` assertion loop. Pair with `rego_test varValues: true` to see which cas…
- `v0Compatible` (boolean): Read the policy as Rego v0 (`--v0-compatible`). The stubs are still written with `import rego.v1`, which a v0 test run (`rego_test` with `v0Compatible`) accepts too.

### `rego_describe_policy` (~209 tokens)

Describe Rego policy

Parse a Rego policy and return a structured summary: package, imports, and rules. Each rule reports clauseCount (how many definitions share the name), isDefault (true if any clause is a default), hasArgs, bodyLength (total body expressions across all clauses), and inline annotations. Useful as the first step in any "what does this policy do" workflow.

Input parameters:

- `source` (string, required): Rego source to describe.
- `v0Compatible` (boolean): Read the policy as Rego v0 (`--v0-compatible`), the syntax OPA used before 1.0: rules without `if`, partial sets as `deny[msg] { ... }`. Needed for a policy that has not been migrated, which OPA 1.x…

### `rego_suggest_fix` (~114 tokens)

Suggest fix for Rego diagnostics

Map common Rego compile errors and Regal lint findings to fix suggestions. Pass `errors` from `rego_check` or `violations` from `rego_lint` unchanged. Returns one suggestion per diagnostic; confidence is `high` for well-known patterns, `medium` where the answer is the rule's documentation (`docs`), `low` for everything else.

Input parameters:

- `diagnostics` (array, required): Diagnostics as rego_check or rego_lint return them: `errors` or `violations`, unchanged.

### `rego_coverage_gaps` (~249 tokens)

Rego test coverage gaps

Run opa test --coverage and return a per-file breakdown of uncovered line ranges. Identifies which rules or branches are not yet exercised by tests. Files are sorted by coverage ascending so the worst-covered files appear first. Use threshold to limit the report to files below a target coverage percentage.

Input parameters:

- `paths` (array, required): Test directories or files. opa test looks for *_test.rego siblings of source files.
- `runPattern` (string): Run only tests whose names match this regex.
- `threshold` (number): Report only files below this coverage percentage (0-100). When omitted, all files with uncovered ranges are reported.
- `v0Compatible` (boolean): Read the policy as Rego v0 (`--v0-compatible`), the syntax OPA used before 1.0: rules without `if`, partial sets as `deny[msg] { ... }`. Needed for a policy that has not been migrated, which OPA 1.x…

### `rego_security_audit` (~217 tokens)

Rego security audit

Run regal lint restricted to its `bugs` category plus any custom rules placed in a `security` category, across one or more policy directories, and return the findings grouped by severity (high/medium) with remediation guidance and a link to each rule. Use it for a periodic fleet-wide sweep rather than per-file style review. Modules that do not parse are listed in `unparseable` and the rest are audited. These are lint findings: a policy with none can still let a request through, so probe it with `rego_eval` inputs (absent, null and wrong-typed fields) for that. Requires regal.

Input parameters:

- `configFile` (string): Path to a Regal config file. Useful when your repo has custom rule configuration.
- `ignoreFiles` (array): Glob patterns to exclude from the audit.
- `paths` (array, required): Policy directories or files to audit. Each must be inside an allowed root (OPA_MCP_ALLOWED_PATHS). Pass the root of your policy fleet to scan everything at once.

### `rego_infer_input_schema` (~363 tokens)

Infer input schema

Statically analyse one or more Rego policies and return a JSON Schema (draft-07) object describing every input.* field the policies read. It follows the ways a policy reads input: loop variables (`some c in input.containers` then `c.image`), rules whose value is an input path (`pod_spec := input.request.object.spec`), function parameters (`trusted(c)`) and `object.get` keys. A key the policy computes is left open, and a scalar type is set only where a comparison with a literal, an `is_*` check or a string built-in shows it. Uses opa parse -- no running OPA server required. A starting point for test inputs and for a schema to give rego_check_schema; review it first, since types the policy never shows are left out. Accepts inline source, individual files, or directories (walked recursively for *.rego files).

Input parameters:

- `paths` (array): Policy files or directories to analyse. Each must be inside an allowed root (OPA_MCP_ALLOWED_PATHS). Directories are walked recursively for *.rego files.
- `source` (string): Inline Rego source to analyse. Mutually exclusive with paths.
- `v0Compatible` (boolean): Read the policy as Rego v0 (`--v0-compatible`), the syntax OPA used before 1.0: rules without `if`, partial sets as `deny[msg] { ... }`. Needed for a policy that has not been migrated, which OPA 1.x…

### `rego_fix` (~337 tokens)

Auto-fix Rego violations

Run regal fix to automatically apply mechanical fixes. Regal 0.42 fixes opa-fmt, use-rego-v1, use-assignment-operator, no-whitespace-comment, directory-package-mismatch, non-raw-regex-pattern, prefer-equals-comparison, redundant-existence-check and constant-condition; older releases fix a subset. Use dryRun: true to preview changes before modifying files. NOTE: directory-package-mismatch moves files to match their package path -- use disable: ["directory-package-mismatch"] to skip it. Regal before 0.41 refuses files with uncommitted git changes unless force: true. Requires regal.

Input parameters:

- `configFile` (string): Path to a Regal config file (.regal/config.yaml).
- `disable` (array): Disable specific fix rules. Useful to skip directory-package-mismatch if you do not want files moved.
- `disableCategory` (array): Disable all rules in a category.
- `dryRun` (boolean): Preview what would be fixed without modifying any files. Recommended before the first real run.
- `enable` (array): Enable specific fix rules.
- `enableCategory` (array): Enable all rules in a category.
- `force` (boolean): On Regal before 0.41, allow fixing files that have uncommitted git changes; those releases refuse them otherwise. Regal 0.41 removed that check, and the flag is not sent to it.
- `ignoreFiles` (array): Glob patterns to exclude from fixing.
- `paths` (array, required): Policy files or directories to fix. Each must be inside an allowed root (OPA_MCP_ALLOWED_PATHS).

### `rego_format_write` (~260 tokens)

Format Rego files in place

Run `opa fmt --write` to canonically format one or more Rego files or directories in place. Use `dryRun: true` to preview which files would change without modifying them. Returns a list of files that were (or would be) reformatted. Unlike `rego_format` which returns formatted source as a string, this tool writes directly to disk. Supports `regoV1`, `v0Compatible`, and `v1Compatible` flags for version-specific formatting. If any file cannot be parsed, the operation is aborted and no files are written.

Input parameters:

- `dryRun` (boolean): Preview which files would be reformatted without modifying them. Recommended before the first real run.
- `paths` (array, required): Policy files or directories to format in place. Each must be inside an allowed root (OPA_MCP_ALLOWED_PATHS).
- `regoV1` (boolean): Format module(s) to be compatible with both Rego v1 and the current OPA version. Adds `import rego.v1` where missing.
- `v0Compatible` (boolean): Use OPA behaviors and syntax prior to the v1.0 release.
- `v1Compatible` (boolean): Use OPA v1.0-compatible behaviors.

### `rego_policy_diff` (~500 tokens)

Diff two Rego policies

Evaluate the same query against two policies (or two versions of the same policy) and compare the results. Both evaluations run in parallel. Returns `equal: true/false`, the raw result from each side, and `changedPaths` -- the dot/bracket paths that differ. Useful for verifying that a refactor preserves behavior, or understanding exactly where two policies diverge. Each side takes either inline source (sourceA/sourceB) or a file/directory path (pathA/pathB). The same input and query are used for both evaluations; pass `inputs` to compare on many input documents in one call, and `dataPaths` to load the data the policies read.

Input parameters:

- `dataPaths` (array): Additional data or policy paths loaded for both evaluations. Each must be inside an allowed root.
- `input`: Inline input document (JSON). Mutually exclusive with inputPath.
- `inputPath` (string): Path to a JSON input file. Must be inside an allowed root. Mutually exclusive with input.
- `inputs` (array): Up to 50 input documents to compare the two policies on, in place of `input`/`inputPath`. The result is `batch`, one entry per input in order, and `differing` counts the inputs on which the policies…
- `pathA` (string): File or directory path for policy A. Must be inside an allowed root. Mutually exclusive with sourceA.
- `pathB` (string): File or directory path for policy B. Must be inside an allowed root. Mutually exclusive with sourceB.
- `query` (string, required): The query to evaluate against both policies, e.g. "data.example.allow".
- `sourceA` (string): Inline Rego source for policy A. Mutually exclusive with pathA.
- `sourceB` (string): Inline Rego source for policy B. Mutually exclusive with pathB.
- `v0CompatibleA` (boolean): Read policy A as Rego v0 (`--v0-compatible`), the syntax before OPA 1.0. Set this and leave `v0CompatibleB` off to compare a legacy policy with its migrated copy.
- `v0CompatibleB` (boolean): Read policy B as Rego v0 (`--v0-compatible`).

### `rego_verify` (~410 tokens)

Formally verify a Rego policy rule

Formally verify a property about a Rego rule using SMT solving (Microsoft Z3). Unlike testing, this checks ALL possible inputs and either proves the property holds or returns a concrete counterexample input that falsifies it. Supports equality, comparison, startswith, endswith, contains, and simple regex.match patterns (prefix: ^lit.*, suffix: .*lit$, exact: ^lit$, contains: .*lit.*, wildcard: .*). Complex regex patterns (character classes, quantifiers, alternation) return INCONCLUSIVE. Also reports INCONCLUSIVE for negation-as-failure (not), comprehensions, partial set and object rules (deny contains msg), functions, else chains, and any operand it cannot encode. A body that reads an absent field is undefined rather than true, so always_true holds only if the rule is also true for an empty input: a rule requiring input.x will be answered with the counterexample {}.

Input parameters:

- `kind` (string, required): Property to prove:   always_true  - rule is true for every possible input (finds inputs that violate this)   never_true   - rule is never true for any input (finds inputs that trigger it)   satisfiab…
- `rule` (string, required): Name of the rule to verify (e.g. "allow", "deny").
- `source` (string, required): Rego source to verify.
- `v0Compatible` (boolean): Read the policy as Rego v0 (`--v0-compatible`), the syntax OPA used before 1.0: rules without `if`, partial sets as `deny[msg] { ... }`. Needed for a policy that has not been migrated, which OPA 1.x…

### `rego_playground_share` (~356 tokens)

Share Rego policy as a GitHub Gist

Share a Rego policy with teammates or create a reproducible example by publishing it as a GitHub Gist, secret unless `public: true` is passed, so only people holding the link can read it. Returns { gistUrl, rawPolicyUrl, id, public }: the gistUrl renders the policy with syntax highlighting on github.com; the rawPolicyUrl can be passed directly to OPA (`opa eval -d <rawPolicyUrl> <query>`) or used as a data source in Conftest. When query, input, or data are supplied, a metadata.json file is bundled into the Gist so recipients have the full evaluation context to reproduce results. Each call creates a new Gist -- use the returned id to reference it later. Requires GITHUB_TOKEN in the environment (GitHub personal access token with the "gist" scope); returns GITHUB_TOKEN_MISSING with setup instructions if unset.

Input parameters:

- `data` (string): Data document as a JSON string. Stored in metadata.json alongside the policy file.
- `description` (string): Short description for the Gist (shown on github.com/gists).
- `input` (string): Input document as a JSON string. Stored in metadata.json alongside the policy file.
- `policy` (string, required): Rego source code to share (the contents of a .rego file).
- `public` (boolean): Make the Gist public: listed on the account and searchable. Off by default, which creates a secret Gist that anyone holding the link can read but that is not listed anywhere.
- `query` (string): Default query to evaluate against the policy, e.g. "data.authz.allow". Stored in metadata.json alongside the policy file.

### `conftest_test` (~889 tokens)

Conftest test

Evaluate configuration files (Kubernetes manifests, Terraform plans, Dockerfiles, Helm charts, or any YAML/JSON/HCL/TOML/INI) against Rego policies using `conftest test`. Returns per-file, per-namespace pass/fail/warn results so you can pinpoint exactly which policy rules fired. Requires `conftest` on PATH or `CONFTEST_BINARY` set; returns CONFTEST_NOT_FOUND otherwise. Provide config via `files` (disk paths) or `inlineConfig` (inline string). Provide policy via `policy` (disk path) or `inlinePolicy` (inline Rego source). Omit `policy` and `inlinePolicy` to use conftest's default `./policy` directory. Policies are executed by conftest and can call OPA built-ins such as http.send. A run in which no rule was evaluated (wrong `namespace`, or no `deny`/`violation`/`warn` rules) is reported as `passed: false` with `nothingEvaluated: true` and the namespaces that do hold rules, where conftest itself would exit 0.

Input parameters:

- `allNamespaces` (boolean): Test policies found in all discovered namespaces. Overrides `namespace`.
- `combine` (boolean): Combine all configuration files into a single input document before evaluating. Useful when policies need to inspect relationships across multiple files.
- `data` (array): Paths to directories from which additional data will be loaded for the Rego policies. Each path must be inside an allowed root.
- `failOnWarn` (boolean): Return `passed: false` even when only warnings (no hard failures) are present.
- `files` (array): Filesystem paths to configuration files to evaluate (YAML, JSON, HCL, Dockerfile, etc.). Each path must be inside an allowed root (OPA_MCP_ALLOWED_PATHS). Mutually exclusive with `inlineConfig`.
- `inlineConfig` (string): Inline configuration content to evaluate (e.g. a Kubernetes manifest as a YAML string). Mutually exclusive with `files`. Defaults to YAML format; set `inlineConfigParser` to override.
- `inlineConfigParser` (string): Parser to use for `inlineConfig`. One of: cue, cyclonedx, dockerfile, dotenv, edn, groovy, hcl1, hcl2, hocon, ignore, ini, json, jsonc, jsonnet, nginx, properties, spdx, textproto, toml, vcl, xml, ya…
- `inlinePolicy` (string): Inline Rego policy source. Written to a temporary directory and passed as `--policy`. The policy should declare `package main` (or match the `namespace` parameter). Mutually exclusive with `policy`.
- `namespace` (string): Rego namespace (package name) to test against. Defaults to `main`. Use `allNamespaces: true` to test all discovered namespaces instead.
- `parser` (string): Force a specific parser for all input `files` via conftest's global `--parser` flag, overriding extension-based detection. Useful for files whose extension does not match their format (e.g. parse a `…
- `policy` (string): Path to a directory or file containing Rego policies. Must be inside an allowed root (OPA_MCP_ALLOWED_PATHS). Mutually exclusive with `inlinePolicy`. Omit to let conftest use its default `./policy` d…
- `v0Compatible` (boolean): Read the policies as Rego v0 (`--rego-version v0`), the syntax before OPA 1.0: rules without `if`, `deny[msg] { ... }`. conftest reads v1 by default and refuses such a policy.

### `conftest_verify` (~261 tokens)

Conftest verify

Run the `test_*` rules inside `*_test.rego` files within a conftest policy directory, verifying that the policies themselves are correct. Equivalent to `opa test` but using conftest's policy-loading machinery. Returns per-file pass/fail results, and NO_TESTS_FOUND when the directory holds no test rules. Requires `conftest` on PATH or `CONFTEST_BINARY` set; returns CONFTEST_NOT_FOUND otherwise.

Input parameters:

- `data` (array): Paths to data directories. Each must be inside an allowed root (OPA_MCP_ALLOWED_PATHS).
- `namespace` (string): Namespace to verify. Omit to verify all namespaces.
- `policy` (string): Path to the directory containing both the Rego policies and the `*_test.rego` test files. Must be inside an allowed root (OPA_MCP_ALLOWED_PATHS). Omit to use conftest's default `./policy` directory.
- `v0Compatible` (boolean): Read the policies as Rego v0 (`--rego-version v0`), the syntax before OPA 1.0: rules without `if`, `deny[msg] { ... }`. conftest reads v1 by default and refuses such a policy.

### `conftest_pull` (~308 tokens)

Conftest pull

Download Rego policies from an OCI registry or Git repository into a local directory using `conftest pull`. Use this to hydrate a local `policy/` directory before running `conftest_test`. Requires `conftest` on PATH or `CONFTEST_BINARY` set. The `policy` directory must be inside OPA_MCP_ALLOWED_PATHS. SECURITY: pulled policies are arbitrary Rego source that will be executed by `conftest_test`. Only pull from registries or repositories you own or explicitly trust -- malicious policy code can use OPA built-ins (http.send, opa.runtime) to exfiltrate data or make outbound network requests when the tests run.

Input parameters:

- `policy` (string): Local directory where the pulled policies will be written. Must be inside an allowed root (OPA_MCP_ALLOWED_PATHS). Omitted, it falls back to `policy` in the working directory of the server process, t…
- `url` (string, required): Policy URL to pull. Supported schemes: `oci://registry/repo:tag` (OCI registry), `github.com/org/repo//path` (GitHub subdirectory), `git::https://example.com/repo//path` (generic Git). See https://ww…

### `conftest_push` (~341 tokens)

Conftest push

Package the local Rego policy directory as an OCI artifact and push it to a registry using `conftest push`. Registry credentials must be pre-configured in the host environment (docker login, ORAS keychain, etc.) -- this tool never handles credentials. The `policy` directory must be inside OPA_MCP_ALLOWED_PATHS. Requires `conftest` on PATH or `CONFTEST_BINARY` set.

Input parameters:

- `policy` (string): Path to the local directory containing Rego policies to push. Must be inside an allowed root (OPA_MCP_ALLOWED_PATHS) and must exist. Omitted, it falls back to `policy` in the working directory of the…
- `repository` (string, required): OCI repository URL to push policies to (e.g. `ghcr.io/my-org/policies:latest`). Registry credentials must already be configured in the host environment (via `docker login`, ORAS keychain, or REGISTRY…
- `v0Compatible` (boolean): Read the policy as Rego v0 (`--v0-compatible`), the syntax OPA used before 1.0: rules without `if`, partial sets as `deny[msg] { ... }`. Needed for a policy that has not been migrated, which OPA 1.x…

### `mcp_server_info` (~61 tokens)

MCP server info

Return the name, version, and runtime details of this opa-mcp server instance. Use this when you need to confirm which version of opa-mcp is running, or to verify that the OPA, Regal, and Conftest binaries are reachable.

## Diagnostics

Captured diagnostic sections: Provenance. The full working is on the page: https://verifymcp.io/servers/orygnscode-opa-mcp/docker-io-orygn-opa-mcp#diagnostics

## Score history

- 2026-11-05: 54
- 2026-11-04: 54
- 2026-11-03: 54
- 2026-11-02: 54
- 2026-11-01: 54
- 2026-10-31: 54
- 2026-10-30: 54
- 2026-10-29: 54
- 2026-10-28: 54
- 2026-10-27: 54
- 2026-10-26: 53
- 2026-10-25: 53
- 2026-10-24: 52
- 2026-10-23: 52
- 2026-10-22: 51
- 2026-10-21: 51
- 2026-10-20: 50
- 2026-10-19: 50
- 2026-10-18: 50
- 2026-10-17: 49
- 2026-10-16: 49
- 2026-10-15: 48
- 2026-10-14: 48
- 2026-10-13: 10
- 2026-10-12: 10
- 2026-10-10: 6
- 2026-10-04: 40
- 2026-10-03: 40
- 2026-10-02: 40
- 2026-10-01: 40

## Common questions

### What is the OPA MCP server?

OPA MCP is listed in the public MCP registry as io.github.OrygnsCode/opa-mcp. Author, validate, debug, and explain OPA Rego policies through any MCP-compatible client. This page covers its container image (docker.io/orygn/opa-mcp).

### Is the OPA MCP server safe to use?

OPA MCP scores 54 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the OPA MCP server expose?

OPA MCP exposes 52 tools: rego_format, rego_check, rego_check_schema, rego_lint, rego_parse_ast, and 47 more. Their descriptions and schemas cost roughly 16,625 tokens of context every time the server is loaded.

### Is the OPA MCP server still maintained?

OPA MCP is still listed as active in the MCP registry. We last reached this channel on 5 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

### What licence is the OPA MCP server under?

OPA MCP declares the MIT licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.

## Links

- Docker Hub: https://hub.docker.com/r/orygn/opa-mcp
- Repository: https://github.com/OrygnsCode/opa-mcp-server
- Website: https://orygn.tech/
- Changelog RSS feed: https://verifymcp.io/servers/orygnscode-opa-mcp/docker-io-orygn-opa-mcp.xml
- Changelog JSON feed: https://verifymcp.io/servers/orygnscode-opa-mcp/docker-io-orygn-opa-mcp.json
- HTML version of this page: https://verifymcp.io/servers/orygnscode-opa-mcp/docker-io-orygn-opa-mcp