Skip to main content
Glama
OrygnsCode

opa-mcp-server

by OrygnsCode
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

OPA capabilities

rego_capabilities
Read-onlyIdempotent

Retrieve OPA capabilities: builtins, future keywords, features, and WASM ABI versions. Check the current or a specific version, list available versions, or fetch full details for named builtins.

Instructions

Return OPA capabilities -- the available builtins, future keywords, features, and WASM ABI versions. With current: true, returns the running OPA's capabilities. With version: "v1.19.0", returns those of a specific version. With neither, lists available named versions. By default (names_only: true), returns only builtin names and count to stay within response size limits. Pass builtins: [...] for the full type signatures and documentation of a few named builtins; names_only: false returns every full record, which needs OPA_MCP_MAX_RESPONSE_BYTES raised above its default.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
currentNoPrint the capabilities of the currently installed OPA. Mutually exclusive with `version`.
versionNoA specific OPA capabilities version (e.g. "v1.21.0"). When neither flag is set, lists available versions.
builtinsNoReturn the full record (type signature, documentation, metadata) for up to 100 builtin names, exact matches only. `matched` counts the records returned and names not found are listed under `missing`. When the records would not fit the response cap the tool returns OUTPUT_TOO_LARGE rather than a truncated result; ask for fewer names. Do not combine with `names_only: true`, which asks for the opposite.
names_onlyNoWhen true, or omitted, return only builtin names, count, future keywords, and features. The full payload for every builtin is larger than the default response cap (OPA_MCP_MAX_RESPONSE_BYTES), so `names_only: false` on its own needs that cap raised; use `builtins` to get full records for a few names instead.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.7.0
    • changedInput schema / properties / version / description
      Previous value: -"A specific OPA capabilities version (e.g. \"v1.19.0\"). When neither flag is set, lists available versions."New value: +"A specific OPA capabilities version (e.g. \"v1.21.0\"). When neither flag is set, lists available versions."
  2. Changed3 schema fields changedv0.6.0
    • addedInput schema / properties / builtins
      Added value: +{
+  "description": "Return the full record (type signature, documentation, metadata) for up to 100 builtin names, exact matches only. `matched` counts the records returned and names not found are listed under `missing`. When the records would not fit the response cap the tool returns OUTPUT_TOO_LARGE rather than a truncated result; ask for fewer names. Do not combine with `names_only: true`, which asks for the opposite.",
+  "items": {
+    "minLength": 1,
+    "type": "string"
+  },
+  "maxItems": 100,
+  "minItems": 1,
+  "type": "array"
+}
    • removedInput schema / properties / names_only / default
      Removed value: -true
    • changedInput schema / properties / names_only / description
      Previous value: -"When true (default), return only builtin names, count, future keywords, and features. The full spec payload routinely exceeds client response size limits. Set to false to retrieve complete type signatures, documentation, and metadata for every builtin."New value: +"When true, or omitted, return only builtin names, count, future keywords, and features. The full payload for every builtin is larger than the default response cap (OPA_MCP_MAX_RESPONSE_BYTES), so `names_only: false` on its own needs that cap raised; use `builtins` to get full records for a few names instead."
  3. Changed1 schema field changedv0.3.0
    • changedInput schema / properties / version / description
      Previous value: -"A specific OPA capabilities version (e.g. \"v0.69.0\"). When neither flag is set, lists available versions."New value: +"A specific OPA capabilities version (e.g. \"v1.19.0\"). When neither flag is set, lists available versions."
  4. Addedv0.1.13
  5. Removedv0.1.5
  6. Addedv0.1.2
  7. Removedv0.1.1
  8. 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 establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds genuinely useful behavior beyond that: the default behavior (`names_only: true`), the response-size limitation rationale, the need to raise OPA_MCP_MAX_RESPONSE_BYTES for full records, and the OUTPUT_TOO_LARGE risk implied by the schema. Nothing contradicts 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose and then progresses logically through parameter modes, defaults, and caveats. Every sentence carries distinct information, and the length is justified by the four-parameter mode matrix. There is no filler or redundant restatement of the title.

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 there is no output schema, the description carries the burden of return-value clarity and does it well: it names the returned categories, explains the `count` and `matched`/`missing` behavior via the schema's `builtins` description, and warns about response-size limits. Minor gap: it does not describe the exact JSON shape of the non-builtin sections (e.g., fields for future keywords/features/WASM versions), but enough is stated for an agent to select and invoke the tool correctly.

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 value beyond the schema by explaining the parameter interplay: the mutual exclusivity implied for `current`/`version`, the effect of omitting both, and the relationship between `builtins` and `names_only`. The schema already contains detailed per-parameter text, so the description does not need to repeat it all.

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 and resource: 'Return OPA capabilities' and enumerates exactly what is included ('available builtins, future keywords, features, and WASM ABI versions'). This clearly distinguishes it from the rego evaluation/parsing siblings, which operate on policies rather than OPA runtime capability metadata.

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?

The description gives strong conditional guidance for each invocation mode ('With current: true...', 'With version: "v1.19.0"...', 'With neither...') and explains when to use `builtins` vs `names_only: false` based on response-size constraints. It does not explicitly name sibling alternatives, but no sibling tool offers this capability, so the mode-level guidance effectively covers when to use the tool.

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