Skip to main content
Glama
OrygnsCode

opa-mcp-server

Explain Rego decision

rego_explain_decision
Read-onlyIdempotent

Evaluate a Rego query with full tracing to explain why a decision was made, providing a structured trace and per-rule fired/not-fired summary.

Instructions

Evaluate a Rego query with full tracing and return a structured trace plus per-rule fired/not-fired summary. Use this when you need to answer "why was this denied?" -- the agent reads the structured trace and narrates the cause without re-implementing the trace parser.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYesRego query to evaluate, e.g. "data.example.allow".
sourceNoInline Rego policy source. Mutually exclusive with `paths`.
pathsNoPolicy / data file or directory paths. Each must be inside an allowed root.
inputNoInline input document.
inputPathNoPath to a JSON input file. Mutually exclusive with `input`.
unknownsNoRefs to treat as unknown during partial evaluation.
partialNoRun partial evaluation rather than full evaluation.
strictBuiltinErrorsNoTreat builtin errors as fatal instead of returning undefined.
Behavior4/5

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

Annotations already declare read-only and idempotent behavior. The description adds value by explaining the trace output and the role of the agent in narrating the cause, without contradicting annotations.

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?

Two sentences, no waste. First sentence states purpose and output, second gives usage guidance. Perfectly concise.

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?

Given the complexity (8 parameters, no output schema), the description explains the core functionality and usage. Could be more specific about the trace format, but it's sufficient for an agent.

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 coverage is 100%, so the baseline is 3. The description does not add parameter-specific details beyond what the schema provides.

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 clearly states it evaluates a Rego query with full tracing, returning a structured trace and per-rule summary. This distinguishes it from sibling tools like rego_eval and rego_explain_undefined by focusing on trace-based explanation.

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 states when to use ('when you need to answer why was this denied?') and provides context that the agent reads the trace. No exclusions or alternative suggestions, but the use case is clear.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/OrygnsCode/opa-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server