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 analyze Rego policies to infer a JSON Schema for every input.* field they read, enabling integration tests, schema validation, and API documentation.

Instructions

Statically analyse one or more Rego policies and return a JSON Schema (draft-07) object describing every input.* field the policies read. Uses opa parse for AST-level analysis -- no running OPA server required. Correct starting point for writing integration tests, configuring opa check --schema validation, or documenting a policy API. 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.2/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description usefully adds behavioural context beyond that: analysis is AST-level via `opa parse` with no running OPA server required (a real differentiator from opa_exec-style tools), and input may be inline source, individual files, or recursively walked directories. It omits failure behaviour on malformed Rego and any path-root error handling.

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 sentences, front-loaded with the core verb-resource-output and then the usage guidance and input modes; nothing is padding. Slightly dense -- the usage sentence could be trimmed -- but every clause contributes.

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 correctly carries the return-value burden by specifying a draft-07 JSON Schema describing every input.* field read. Combined with the input-mode coverage and the existing annotations, an agent has everything needed to invoke 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`, and the fairly intricate `v0Compatible` flag. The description restates the source/file/directory modes but adds no detail the schema lacks, and never mentions v0Compatible. Baseline 3 is appropriate when structured fields carry the load.

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 (one or more Rego policies), and output (a draft-07 JSON Schema of every input.* field read). That output framing separates it from near-siblings like rego_check_schema (validates against a schema), rego_parse_ast (returns an AST), and rego_inspect, so an agent can route without opening any 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?

Names three concrete downstream uses -- writing integration tests, configuring `opa check --schema`, documenting a policy API -- which tells the agent when this is the right starting point. It stops short of explicit exclusions or naming the sibling to prefer when you already have a schema and only want validation (rego_check_schema), so it is clear context rather than full when/when-not guidance.

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