Skip to main content
Glama
OrygnsCode

opa-mcp-server

by OrygnsCode
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Evaluate Rego query

rego_eval

Evaluate Rego queries against policies and input documents. Supports batch inputs and v0-compatible policies for pre-1.0 Rego syntax.

Instructions

Evaluate a Rego query against a policy and an input document using opa eval. Returns the standard {result: [...]} shape. 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

A3.6/5.0
Behavior4/5

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

Annotations declare readOnlyHint=false and openWorldHint=true, so the safety profile is partially covered; the description adds real value beyond them by disclosing the return shape (`{result: [...]}`), the pre-1.0 Rego compatibility path, and the fact that a query can run with no policy at all. It does not restate or contradict the annotations.

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

Conciseness4/5

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

Four compact sentences, front-loaded with what the tool does and the return shape before the optional-parameter notes. The colloquial "bread-and-butter authoring tool" is a slight indulgence but it conveys routing value cheaply.

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

Completeness3/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, the description usefully supplies the return shape and the headline behaviors, so the essentials an agent needs to call it are present. What is missing is disambiguation from the large cluster of near-identical eval/query siblings, which the description never addresses.

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 schema already documents all 10 parameters thoroughly, including the batch semantics of `inputs` and the v0 rationale for `v0Compatible`. The description's parameter remarks (policy optional, `inputs` for many documents, `v0Compatible` for pre-1.0 policies) largely duplicate the schema text, so baseline 3 is appropriate.

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 calls itself the "bread-and-butter authoring tool," which positions it as the default entry point. It never names a specific sibling (rego_eval_with_explain, rego_eval_with_profile, rego_eval_with_coverage, opa_query_decision), so an agent must infer the distinction from the surrounding tool list.

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

Usage Guidelines3/5

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

Gives implied usage context: policy is optional so a bare query works for built-ins/expressions, and `inputs` enables batching one query against many documents. There are no exclusions and no explicit routing to the decorated eval variants (explain/profile/coverage) that share almost the same job, which is the main decision an agent faces here.

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