Skip to main content
Glama
Sign In
opa-mcp-server

opa-mcp-server

by OrygnsCode
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Suggest fix for Rego diagnostics

rego_suggest_fix
Read-onlyIdempotent

Converts Rego compile errors and Regal lint findings into actionable fix suggestions, one per diagnostic.

Instructions

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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "diagnostics": "<diagnostics>"
    },
    "name": "rego_suggest_fix"
  }
}

Input Schema

NameRequiredDescriptionDefault
diagnosticsYesDiagnostics as rego_check or rego_lint return them: `errors` or `violations`, unchanged.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed10 schema fields changedv0.9.0
    • changedInput schema / properties / diagnostics / description
      Previous value: -"Diagnostics from rego_check or rego_lint."New value: +"Diagnostics as rego_check or rego_lint return them: `errors` or `violations`, unchanged."
    • changedInput schema / properties / diagnostics / items / properties / category / description
      Previous value: -"Category (Regal violations)."New value: +"Category of a rego_lint violation."
    • changedInput schema / properties / diagnostics / items / properties / code / description
      Previous value: -"Diagnostic code (e.g. \"rego_unsafe_var_error\")."New value: +"Error code from rego_check, e.g. \"rego_unsafe_var_error\"."
    • addedInput schema / properties / diagnostics / items / properties / description
      Added value: +{
+  "description": "Description of a rego_lint violation.",
+  "type": "string"
+}
    • addedInput schema / properties / diagnostics / items / properties / level
      Added value: +{
+  "description": "Level of a rego_lint violation.",
+  "type": "string"
+}
    • addedInput schema / properties / diagnostics / items / properties / location / properties / text
      Added value: +{
+  "type": "string"
+}
    • changedInput schema / properties / diagnostics / items / properties / message / description
      Previous value: -"Diagnostic message."New value: +"Error message from rego_check."
    • addedInput schema / properties / diagnostics / items / properties / related_resources
      Added value: +{
+  "description": "Documentation links of a rego_lint violation.",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "description": {
+        "type": "string"
+      },
+      "ref": {
+        "type": "string"
+      }
+    },
+    "type": "object"
+  },
+  "type": "array"
+}
    • changedInput schema / properties / diagnostics / items / properties / title / description
      Previous value: -"Title (Regal violations)."New value: +"Rule name of a rego_lint violation, e.g. \"not-equals-in-loop\"."
    • removedInput schema / properties / diagnostics / items / required
      Removed value: -[
-  "code",
-  "message"
-]
  2. Addedv0.1.13
  3. Removedv0.1.5
  4. Addedv0.1.2
  5. Removedv0.1.1
  6. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context with no output schema to fall back on: one suggestion per diagnostic and the confidence tiers (high/medium/low) with the rule that medium means the answer is the rule's documentation.

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?

Three tight sentences, front-loaded with the purpose before the input source and the return semantics. Every sentence carries information the agent needs; there is no filler.

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

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description takes on the job of describing returns, and it does so (one suggestion per diagnostic, confidence semantics). What is missing is minor: nothing about suggestion content itself (e.g., whether code patches are included) or limits on diagnostic volume.

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 100% for the single `diagnostics` parameter, so baseline is 3. The description goes slightly beyond by explaining the parameter's provenance (pass `errors`/`violations` through unchanged), which clarifies the expected shape and that no transformation is needed.

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?

States a specific verb and resource: mapping Rego compile errors and Regal lint findings to fix suggestions. It also names the sibling tools that produce the inputs (rego_check, rego_lint), which lets an agent route between check/lint and the suggest step without opening schemas.

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?

Explicitly tells the agent when and how to use it: pass `errors` from `rego_check` or `violations` from `rego_lint` unchanged, i.e. run it as a follow-up to diagnostics. It stops short of naming when not to use it or pointing at rego_fix as the auto-apply alternative.

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