Skip to main content
Glama
OrygnsCode

opa-mcp-server

by OrygnsCode
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Infer input schema

rego_infer_input_schema
Read-onlyIdempotent

Statically analyzes Rego policies to infer a JSON Schema of every input field they read, helping generate test inputs and validate policies before running OPA.

Instructions

Statically analyse one or more Rego policies and return a JSON Schema (draft-07) object describing every input.* field the policies read. It follows the ways a policy reads input: loop variables (some c in input.containers then c.image), rules whose value is an input path (pod_spec := input.request.object.spec), function parameters (trusted(c)) and object.get keys. A key the policy computes is left open, and a scalar type is set only where a comparison with a literal, an is_* check or a string built-in shows it. Uses opa parse -- no running OPA server required. A starting point for test inputs and for a schema to give rego_check_schema; review it first, since types the policy never shows are left out. Accepts inline source, individual files, or directories (walked recursively for *.rego files).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathsNoPolicy files or directories to analyse. Each must be inside an allowed root (OPA_MCP_ALLOWED_PATHS). Directories are walked recursively for *.rego files.
sourceNoInline Rego source to analyse. Mutually exclusive with paths.
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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.8.0
    • 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. 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.",
+  "type": "boolean"
+}
  2. Addedv0.1.13

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing mechanism ('uses opa parse -- no running OPA server required') and important fidelity caveats: computed keys are left open, scalar types are only set where a comparison/literal/is_* check reveals them, and types the policy never shows are omitted. These limitations materially affect how an agent should interpret the result.

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?

Front-loaded with the core purpose, then detail on how input paths are detected and the opa parse mechanism. The enumeration of read patterns (loop variables, rule values, function params, object.get) is dense but justifies its length by setting fidelity expectations.

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?

With no output schema, the description carries the return contract and does so: it names the format (JSON Schema draft-07), the scope (every input.* field read), and the known gaps. Combined with 100% schema coverage on inputs, an agent has what it needs to call and interpret this correctly.

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 paths, source, v0Compatible fully. The description adds only a summary of the input modes (inline source, files, recursive directories) without new syntax or constraints, so the baseline 3 applies.

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 ('statically analyse'), resource (Rego policies), and output (a draft-07 JSON Schema of input.* fields). It is easy to distinguish from siblings like rego_check_schema (validates against a schema) or rego_describe_policy, since it is explicitly the tool that produces a schema.

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 context for use: it is 'a starting point for test inputs and for a schema to give rego_check_schema; review it first'. That names a downstream consumer and a precondition (review before trusting). It stops short of stating when to prefer an alternative tool, so it lands at 4 rather than 5.

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