Loading ToolBench
An MCP server for managing OPA Gatekeeper policies in Kubernetes clusters. Enables policy application, testing, listing, deletion, and violation checking through a JSON-RPC interface.
This MCP server has moderate structural definitions but significant gaps in completeness and clarity. All 6 tools are explicitly registered with names, basic descriptions, and input schemas visible in server.go. However, descriptions are generic and lack LLM-guidance (e.g., 'Apply an OPA Gatekeeper policy' doesn't explain WHEN to use it vs alternatives, or what prerequisites exist). Parameter descriptions are present but sparse, most lack format hints, constraints, or error guidance. Output schemas are completely undocumented; the code does not show what fields each tool returns, forcing LLMs to guess. Error handling is minimal (errorReporting=true but no recovery guidance visible in definitions). Tool composition is reasonable (6 focused tools), but naming could be more specific (e.g., 'opa_apply_policy' vs 'apply_opa_constraint_template' or 'apply_opa_constraint' would disambiguate). The server is STDIO-only, which is a hard transport limitation.
Apply an OPA Gatekeeper policy from a YAML file path. The server will read the file and apply it to the cluster.
Delete an OPA Gatekeeper policy (ConstraintTemplate or Constraint)
Get current policy violations in the cluster
List all OPA Gatekeeper ConstraintTemplates in the cluster
List all OPA Gatekeeper Constraints in the cluster
Test a manifest against OPA policies using dry-run. Provide either filePath OR manifest (inline YAML).
No documented output schemas. Code shows input schemas (map[string]interface{}) but nowhere in the visible source are return types, response field names, or structures documented. LLMs cannot plan downstream tool calls or extract data.
Descriptions lack LLM-optimization. Descriptions are 40 - 50 chars and state WHAT the tool does but not WHEN to call it, what prerequisites exist, or how it differs from similar tools.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 51 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 44 | 2024-11-05+ | v1 |
Parameter descriptions are minimal. 'filePath' is described as 'Path to the YAML file containing the policy (ConstraintTemplate or Constraint)' but lacks format hints (absolute vs relative? glob patterns?). 'kind' parameter in opa_list_constraints says 'Optional: Filter by constraint kind (e.g., K8sRequiredLabels)' but does not list valid values or explain how to discover them.
opa_test_policy uses mutually exclusive parameters (filePath OR manifest) but does not state this explicitly in the InputSchema 'required' array or parameter descriptions. LLMs may pass both or neither, causing ambiguous failures.
No error guidance. The code references errorReporting=true, but the visible tool definitions do not show what errors each tool can return or how to recover. E.g., opa_apply_policy may fail if the file doesn't exist, YAML is invalid, or the cluster rejects the policy, but no guidance is provided.
Tool annotations missing. No tool declares readOnlyHint, destructiveHint, or idempotentHint. The risk metadata is provided in the eval sheet (WRITE, DESTRUCTIVE), but not present in the InputSchema. Per 2026-07-28 spec, these annotations should be in the tool definition.
opa_delete_policy has minimal description (36 chars: 'Delete an OPA Gatekeeper policy (ConstraintTemplate or Constraint)'). It does not clarify whether this is reversible, what cascading effects occur, or whether a confirmation step is needed. Destructive operations should have extensive guidance.
Naming ambiguity in opa_list_constraints: does 'kind' refer to the Kind field of the constraint resource (e.g., 'K8sRequiredLabels') or the Kind field of the underlying template? Unclear naming forces the LLM to reason about Kubernetes resource semantics.