opa-mcp-server

Overview Schema Source Related Servers Score Discussions Admin

Conftest test

conftest_test

Evaluate configuration files against Rego policies using conftest test, returning per-file and per-namespace pass/fail/warn results.

Instructions

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.

Input Schema

TableJSON Schema

Name	Required	Description
`data`	No	Paths to directories from which additional data will be loaded for the Rego policies. Each path must be inside an allowed root.
`files`	No	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`.
`parser`	No	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 `.tfstate` file as `json`). One of: cue, dockerfile, dotenv, edn, hcl1, hcl2, hocon, ignore, ini, json, jsonnet, nginx, properties, spdx, textproto, toml, vcl, xml, yaml. For `inlineConfig`, prefer `inlineConfigParser`.
`policy`	No	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` directory.
`combine`	No	Combine all configuration files into a single input document before evaluating. Useful when policies need to inspect relationships across multiple files.
`namespace`	No	Rego namespace (package name) to test against. Defaults to `main`. Use `allNamespaces: true` to test all discovered namespaces instead.
`failOnWarn`	No	Return `passed: false` even when only warnings (no hard failures) are present.
`inlineConfig`	No	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.
`inlinePolicy`	No	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`.
`allNamespaces`	No	Test policies found in all discovered namespaces. Overrides `namespace`.
`inlineConfigParser`	No	Parser to use for `inlineConfig`. One of: cue, dockerfile, dotenv, edn, hcl1, hcl2, hocon, ignore, ini, json, jsonnet, nginx, properties, spdx, textproto, toml, vcl, xml, yaml. Defaults to yaml. Ignored when `files` is used (conftest infers the parser from each file's extension, unless `parser` is set).

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv0.5.0Sep 5, 2026

changedInput schema / properties / inlineConfigParser / description

Previous value: -"Parser to use for `inlineConfig`. Valid values: yaml (default), json, toml, hcl1, hcl2, ini, xml, dotenv, cue, jsonnet, properties, edn, hocon, dockerfile. Ignored when `files` is used (conftest infers the parser from each file's extension, unless `parser` is set)."New value: +"Parser to use for `inlineConfig`. One of: cue, dockerfile, dotenv, edn, hcl1, hcl2, hocon, ignore, ini, json, jsonnet, nginx, properties, spdx, textproto, toml, vcl, xml, yaml. Defaults to yaml. Ignored when `files` is used (conftest infers the parser from each file's extension, unless `parser` is set)."

addedInput schema / properties / inlineConfigParser / enum

Added value: +[
+  "cue",
+  "dockerfile",
+  "dotenv",
+  "edn",
+  "hcl1",
+  "hcl2",
+  "hocon",
+  "ignore",
+  "ini",
+  "json",
+  "jsonnet",
+  "nginx",
+  "properties",
+  "spdx",
+  "textproto",
+  "toml",
+  "vcl",
+  "xml",
+  "yaml"
+]

changedInput schema / properties / parser / description

Previous value: -"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 `.tfstate` file as `json`). Valid values: yaml, json, toml, hcl1, hcl2, ini, xml, dotenv, cue, jsonnet, properties, edn, hocon, dockerfile. For `inlineConfig`, prefer `inlineConfigParser`."New value: +"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 `.tfstate` file as `json`). One of: cue, dockerfile, dotenv, edn, hcl1, hcl2, hocon, ignore, ini, json, jsonnet, nginx, properties, spdx, textproto, toml, vcl, xml, yaml. For `inlineConfig`, prefer `inlineConfigParser`."

addedInput schema / properties / parser / enum

Added value: +[
+  "cue",
+  "dockerfile",
+  "dotenv",
+  "edn",
+  "hcl1",
+  "hcl2",
+  "hocon",
+  "ignore",
+  "ini",
+  "json",
+  "jsonnet",
+  "nginx",
+  "properties",
+  "spdx",
+  "textproto",
+  "toml",
+  "vcl",
+  "xml",
+  "yaml"
+]

Changed2 schema fields changedv0.1.20Jun 3, 2026

changedInput schema / properties / inlineConfigParser / description

Previous value: -"Parser to use for `inlineConfig`. Valid values: yaml (default), json, toml, hcl1, hcl2, ini, xml, dotenv, cue, jsonnet, properties, dockerfile. Ignored when `files` is used (conftest infers the parser from each file's extension)."New value: +"Parser to use for `inlineConfig`. Valid values: yaml (default), json, toml, hcl1, hcl2, ini, xml, dotenv, cue, jsonnet, properties, edn, hocon, dockerfile. Ignored when `files` is used (conftest infers the parser from each file's extension, unless `parser` is set)."

addedInput schema / properties / parser

Added value: +{
+  "description": "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 `.tfstate` file as `json`). Valid values: yaml, json, toml, hcl1, hcl2, ini, xml, dotenv, cue, jsonnet, properties, edn, hocon, dockerfile. For `inlineConfig`, prefer `inlineConfigParser`.",
+  "type": "string"
+}

Addedv0.1.13May 28, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond annotations, it discloses the external binary requirement and failure mode (CONFTEST_NOT_FOUND), and warns that policies can call OPA built-ins such as http.send, implying possible side effects. It also states the result granularity. This is substantial behavioral context; no contradiction with readOnlyHint=false/openWorldHint=true.

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

Conciseness5/5

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

The description is a single dense paragraph with no filler: purpose, formats, output, prerequisite, parameter routing, default, and side-effect warning all appear in order. Every sentence earns its place and the most important scoping info is front-loaded.

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?

For an 11-parameter, no-output-schema, no-required-parameter tool, it covers the essential decision points: how to supply inputs, what happens when policy is omitted, runtime prerequisite, and what results look like. The schema covers remaining parameter details, so nothing needed for correct invocation is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline applies; the description does not need to restate parameter details. It adds a useful high-level grouping (config vs policy, file vs inline) and the default-policy behavior, but those are already reflected in the schema. No additional semantic enrichment beyond schema.

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

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Evaluate configuration files ... against Rego policies using `conftest test`.' It enumerates supported input formats and clarifies the output is per-file, per-namespace pass/fail/warn results, which distinguishes it from sibling policy-editing and OPA-data tools. This is as strong a purpose statement as an agent could want.

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

Usage Guidelines4/5

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

It gives clear direction for selecting config and policy inputs: 'Provide config via `files` ... or `inlineConfig`', 'Provide policy via `policy` ... or `inlinePolicy`', and explains the default `./policy` directory. It does not explicitly name a sibling alternative or say when not to use the tool, but the context is unambiguous enough to be actionable.

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

Install Server

Conftest test

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools