Skip to main content
Glama
OrygnsCode

opa-mcp-server

by OrygnsCode
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Evaluate Rego query

rego_eval

Evaluate a Rego query against a policy and input, returning result, defined, and printed output. Run one query across many inputs or test built-ins without a policy.

Instructions

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 Schema

TableJSON Schema
NameRequiredDescriptionDefault
inputNoInline input document.
pathsNoPolicy / data file or directory paths. Each must be inside an allowed root.
queryYesRego query to evaluate, e.g. "data.example.allow".
inputsNoSeveral 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 when the query was undefined for it) or an `error`. An input that fails at runtime does not stop the others. A policy that does not compile fails the call, and after an input times out the inputs not yet started come back as `NOT_EVALUATED`.
sourceNoInline 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.
partialNoRun partial evaluation rather than full evaluation.
unknownsNoRefs to treat as unknown during partial evaluation.
inputPathNoPath to a JSON input file. Mutually exclusive with `input`.
v0CompatibleNoRead 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 otherwise refuses to load. Where the tool also takes a query, the query is read as v0 too, with the future keywords imported so `in`, `every` and `some x in` still work in it.
strictBuiltinErrorsNoTreat builtin errors as fatal instead of returning undefined.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.8.0
    • changedInput schema / properties / v0Compatible / description
      Previous value: -"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 otherwise refuses to load."New value: +"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 otherwise refuses to load. Where the tool also takes a query, the query is read as v0 too, with the future keywords imported so `in`, `every` and `some x in` still work in it."
  2. Changed3 schema fields changedv0.7.0
    • addedInput schema / properties / inputs
      Added value: +{
+  "description": "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 when the query was undefined for it) or an `error`. An input that fails at runtime does not stop the others. A policy that does not compile fails the call, and after an input times out the inputs not yet started come back as `NOT_EVALUATED`.",
+  "items": {},
+  "maxItems": 50,
+  "minItems": 1,
+  "type": "array"
+}
    • changedInput schema / properties / source / description
      Previous value: -"Inline Rego policy source. Mutually exclusive with `paths`."New value: +"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."
    • addedInput schema / properties / v0Compatible
      Added value: +{
+  "description": "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 otherwise refuses to load.",
+  "type": "boolean"
+}
  3. Addedv0.1.13
  4. Removedv0.1.5
  5. Addedv0.1.2
  6. Removedv0.1.1
  7. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Goes well past the thin annotations, disclosing the return shape, the meaning of `defined` (undefined is not `false`), `printed` output, batch semantics with per-input `result`/`error`, runtime-failure isolation, 'a policy that does not compile fails the call', and `NOT_EVALUATED` after a timeout. This is exactly the kind of return/error behavior the agent needs and no annotation provides.

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?

Front-loaded with the core action, then each subsequent sentence carries a distinct piece of information (return shape, optional policy, batch, v0 compatibility) with no filler or repetition. Dense but every sentence earns its place.

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 a 10-parameter tool with no output schema and only two annotations, the description supplies the missing return-shape and error-handling detail an agent needs to interpret results correctly. Nothing essential for correct invocation or interpretation is absent.

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 already 100%, so the baseline is 3, but the description adds real meaning: it explains that omitting `source`/`paths` lets a query run standalone, and gives the rationale for `v0Compatible` (pre-1.0 syntax OPA 1.x otherwise refuses to load). It slightly overlaps the schema's own `inputs` prose but still adds value.

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?

States a specific verb and resource ('Evaluate a Rego query against a policy and an input document using `opa eval`') and characterizes it as 'the bread-and-butter authoring tool', which sets it apart from the explain/profile/coverage eval siblings by implication. It does not name any sibling explicitly, so an agent still has to infer the boundary against rego_eval_with_explain or opa_query_decision.

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?

Gives clear usage context: 'The policy is optional, so a query alone tries out a built-in or an expression' and 'Pass `inputs` to evaluate one query against many input documents in one call'. It does not state when NOT to use this tool or point to the specialized eval/query alternatives, so the routing guidance is implied rather than explicit.

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

Deploy Server

Other Tools