Skip to main content
Glama
OrygnsCode

opa-mcp-server

by OrygnsCode
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Migrate Rego to v1 syntax

rego_migrate_v1

Migrate Rego v0 policies to Rego v1: rename reserved rules, replace removed built-ins, format syntax with opa fmt, validate with opa check, and compare rule/value equivalence against test inputs.

Instructions

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 Schema

TableJSON Schema
NameRequiredDescriptionDefault
inputsNoUp 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 compared by value and by type, and `equivalence` reports any that differ.
sourceYesRego 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 are returned in `errors` so you can resolve them manually.
queriesNoUp 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)`. An expression that names a rule this tool renames, as `data.<package>.<rule>`, reaches it under its new name on the migrated side.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.8.0
    • changedInput schema / properties / inputs / description
      Previous value: -"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 is compared by value and by type, and `equivalence` reports any that differ."New value: +"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 compared by value and by type, and `equivalence` reports any that differ."
    • addedInput schema / properties / queries
      Added value: +{
+  "description": "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)`. An expression that names a rule this tool renames, as `data.<package>.<rule>`, reaches it under its new name on the migrated side.",
+  "items": {
+    "minLength": 1,
+    "type": "string"
+  },
+  "maxItems": 10,
+  "minItems": 1,
+  "type": "array"
+}
  2. Changed2 schema fields changedv0.7.0
    • addedInput schema / properties / inputs
      Added value: +{
+  "description": "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 is compared by value and by type, and `equivalence` reports any that differ.",
+  "items": {},
+  "maxItems": 20,
+  "minItems": 1,
+  "type": "array"
+}
    • changedInput schema / properties / source / description
      Previous value: -"Rego v0 source to migrate to Rego v1 syntax. `opa fmt --rego-v1` auto-fixes reserved keywords and adds `import rego.v1`; any remaining issues are returned in `errors` so you can resolve them manually."New value: +"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 are returned in `errors` so you can resolve them manually."
  3. Addedv0.1.13

TDQS

A4.6/5.0
Behavior5/5

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

With annotations only indicating readOnlyHint=false and openWorldHint=true, the description carries and exceeds the burden: it discloses the rename logic, built-in replacement via appended helpers, behaviour-preservation intent, that evaluation runs the policy 'http.send included' (matching openWorldHint), that migrated source is returned even when check finds errors, and the INVALID_REGO failure mode. No contradiction with 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?

Purpose is front-loaded in the first sentence and every subsequent sentence carries concrete information (rename rules, equivalence reporting, edge cases). It is dense and long, but the length is largely earned by genuine tool complexity; only minor tightening is possible.

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?

There is no output schema, so the description must cover return values, and it does: `rewrites`, `notes`, `equivalence`, `errors`, and the `INVALID_REGO` message. Combined with the mutation/network annotations, an agent has everything needed to call and interpret results.

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 coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: it explains that `inputs` drives per-rule value/type comparison with `equivalence` reporting differences, and that `queries` is how functions are compared and can resolve names this tool renames. This goes beyond the schema's own descriptions.

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+resource: 'Migrate Rego v0 source to Rego v1.' It clearly delineates this from siblings like rego_format and rego_check by explaining it performs renames/built-in replacement, then delegates syntax conversion and validation to those tools internally.

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 context for when the tool applies (v0 sources needing v1 migration) and handles edge cases: source that parses only as v1 is returned unchanged, source parsing as neither returns INVALID_REGO. However, it never explicitly names sibling alternatives (e.g., rego_fix, rego_format) or states when NOT to reach for this tool, so routing among the many rego_* siblings is left to inference.

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