Server data from the Official MCP Registry
Policy-as-code guardrails for AI coding agents, validated via OPA, Conftest, Checkov & Semgrep.
Policy-as-code guardrails for AI coding agents, validated via OPA, Conftest, Checkov & Semgrep.
The Constraint Registry MCP server is a well-architected policy-as-code tool with strong security practices. Authentication and authorization are appropriately scoped for its purpose (no sensitive data exfiltration, proper credential handling via environment variables). Code quality is high with comprehensive test coverage. Minor findings include broad exception handling in the SARIF normalizer and a suggestion to validate untrusted YAML input more explicitly, but these do not materially impact security for this tool's use case. Supply chain analysis found 3 known vulnerabilities in dependencies (0 critical, 3 high severity). Package verification found 1 issue.
4 files analyzed · 8 issues found
Security scores are indicators to help you make informed decisions, not guarantees. Always review permissions before connecting any MCP server.
This plugin requests these system permissions. Most are normal for its category.
Add this to your MCP configuration file:
{
"mcpServers": {
"io-github-sureshkhemka-constraints-registry": {
"args": [
"constraints-registry"
],
"command": "uvx"
}
}
}From the project's GitHub README.
Policy-as-code guardrails for AI-generated code. An MCP server that serves engineering constraints to coding agents (Claude Code, Cursor, Codex) at generation time and validates artifacts with OPA, Conftest, Checkov, and Semgrep.
A single, queryable source of engineering constraints (infrastructure, organizational, architectural) that coding agents (Claude Code, Cursor, Codex, …) consult at code-generation time, exposed over an MCP server. It does not enforce constraints itself — it provides guidance to agents and delegates deterministic validation to existing enforcement engines (OPA, Conftest, Checkov, Semgrep).
Constraints are authored in source repos, aggregated into an immutable, versioned bundle, and served over MCP so an agent can:
describe_scope — discover the valid selector vocabulary,get_constraints — fetch the rules relevant to what it's building, andvalidate — check a candidate artifact against the bound enforcement engines.Authoritative requirements:
constraint-registry-v0-spec.md. Requirement → component → test mapping:TRACEABILITY.md.
adapters/sarif/), so adding a new SARIF engine is mostly
wiring. Adding an engine = one adapter + one config line (see
Adding an enforcement engine).describe_scope, get_constraints, validate)
over stdio or a shared HTTP endpoint. get_constraints fails open
so an agent is never blocked.| Tool | Required? | Notes |
|---|---|---|
| Python ≥ 3.11 | yes | the package targets 3.11+ |
| uv | yes | manages the venv and runs entry points |
OPA (opa) | for Rego validate / fixture cross-checks | the reference enforcement engine |
Conftest (conftest) | optional | second Rego engine; its checks SKIP if absent |
Checkov (checkov) | optional | IaC scanning engine; its checks SKIP if absent |
Semgrep (semgrep) | bundled | source-code engine; installed automatically by uv sync |
Install the external engines on macOS:
brew install opa conftest checkov # semgrep is installed by `uv sync`
Each engine is optional and independent: any test or harness check whose
engine binary is not on PATH is skipped, not failed. The registry and the
get_constraints/describe_scope guidance work without any engine at all — an
engine is only needed to run validate and the fixture cross-checks for
constraints bound to it.
git clone https://github.com/SureshKhemka/constraints-registry.git
cd constraints-registry
uv sync # create the venv + install deps (incl. semgrep)
uv run cregistry-harness # run the validation harness against the bundled samples
The harness emits machine-readable JSON and exits non-zero on any failure. A green run looks like:
{ "passed": true, "summary": { "pass": 21, "fail": 0, "skip": 0, "total": 21 }, "checks": [ ... ] }
(skip is used only when an optional engine like conftest is not installed.)
Two transports — pick based on how you want tools to connect.
# stdio (default): each tool launches its own copy; nothing to manage
uv run cregistry-mcp
# one shared HTTP server every tool connects to (recommended for multiple tools)
uv run cregistry-mcp --http --port 8765 --reload-interval 60
Flags: --transport {stdio,http,sse}, --http (shorthand), --host
(default 127.0.0.1), --port (default 8765), --config
(or $CREGISTRY_CONFIG), --reload-interval SECONDS (0 = off).
Manage the shared HTTP server:
lsof -ti tcp:8765 | xargs kill # stop
# restart = stop + start
Full operational guide (stop/restart, macOS launchd auto-start, the
repo-sync/decoupling pattern): docs/RUNNING.md.
Tool input/output contracts: docs/MCP_CONTRACT.md.
The server exposes three tools: describe_scope, get_constraints, validate.
# shared HTTP server (start it first, see above), available in every project:
claude mcp add --scope user --transport http constraint-registry http://127.0.0.1:8765/mcp
# OR stdio (no separate server to run; Claude launches it):
claude mcp add constraint-registry -- uv run --directory "$(pwd)" cregistry-mcp
claude mcp list # should show: constraint-registry ... ✔ Connected
~/.cursor/mcp.json){ "mcpServers": { "constraint-registry": { "url": "http://127.0.0.1:8765/mcp" } } }
Configure an MCP server with command: uv, args: ["run","--directory","/abs/path/to/repo","cregistry-mcp"].
Agents auto-discover the tools, but to get them to consult the registry before
generating code, add an instruction to your project (or ~/.claude/CLAUDE.md):
Before writing AWS/infra code, call the constraint-registry MCP:
describe_scopeto learn valid selector values, thenget_constraintswith the right scope, and comply with everyhardconstraint as a non-negotiable downstream gate. Optionallyvalidatethe result.
A source is a directory with constraints/*.yaml (one constraint per file)
and, optionally, policies/ (engine policies) and fixtures/ (sample artifacts).
Register sources and engines in registry.config.yaml:
sources:
- { name: platform-security, path: sources/platform-security, precedence: 100 }
- { name: data-platform, path: sources/data-platform, precedence: 50 }
engines:
- { name: opa, adapter: "cregistry.engine.adapters.opa:OpaAdapter" }
- { name: conftest, adapter: "cregistry.engine.adapters.conftest:ConftestAdapter" }
- { name: checkov, adapter: "cregistry.engine.adapters.checkov:CheckovAdapter", options: { min_level: warning } }
- { name: semgrep, adapter: "cregistry.engine.adapters.semgrep:SemgrepAdapter", options: { min_level: warning } }
precedence_policy: default
A constraint (see sources/platform-security/constraints/aws-s3-no-public-access.yaml):
id: aws.s3.no-public-access
title: "S3 buckets must not be publicly accessible"
intent: "Public buckets are the top source of data-exposure incidents."
category: infrastructure # infrastructure | organizational | architectural
scope:
providers: [aws]
resource_types: [aws_s3_bucket] # Terraform resource ids (NOT "s3_bucket")
environments: [all]
repos: ["tag:data-plane"]
severity: hard # hard | soft | advisory
enforcement: # omit for an advisory (guidance-only) constraint
- { engine: opa, policy: policies/s3_public.rego }
guidance:
do: ["Attach an aws_s3_bucket_public_access_block with all four flags true"]
dont: ["Never set acl = 'public-read' or 'public-read-write'"]
example_compliant: |
{"resources": {"aws_s3_bucket": {"data": {"acl": "private", "public_access_block": true}}}}
owner: platform-security
version: 1.0.0
fixtures: # optional; cross-checked against the engine
pass: fixtures/s3_private.json
fail: fixtures/s3_public.json
Scoping notes (matters when agents query):
resource_types use the target tooling's identifiers (Terraform: aws_s3_bucket).
Call describe_scope to discover the exact vocabulary present.uv run cregistry-harness to validate schema, precedence,
and fixtures.Run the server with --reload-interval N and it re-imports from disk every N
seconds, publishing a new immutable bundle when content changes:
uv run cregistry-mcp --http --port 8765 --reload-interval 60
git pull or CI publish). Code/dependency changes still need a restart.uv run cregistry-harness runs end-to-end against the bundled, self-contained
sample sources and proves: schema conformance, deterministic import, malformed-
constraint isolation, namespacing & precedence, versioning & deprecation, engine-
interface conformance (incl. a reusable suite any adapter can be run against),
fixture cross-checks / broken-binding detection, the MCP contract / scoping /
fail-open, and hot-reload behavior. It prints structured JSON and returns a
non-zero exit on any failure — suitable for CI.
uv run cregistry-harness # human-readable JSON to stdout, exit 0/1
uv run cregistry-harness --config path/to/registry.config.yaml
Implement the EngineAdapter interface in a new module under
src/cregistry/engine/adapters/, add one line under engines: in
registry.config.yaml, and validate it against the existing conformance suite —
no changes to the schema, importer, MCP server, or harness. Full walkthrough:
docs/ADDING_AN_ENGINE.md.
src/cregistry/
model.py constraint schema (Pydantic)
loader.py load + per-field schema validation
config.py registry config (sources, engines)
importer.py import → aggregate → bundle
precedence.py namespacing precedence / conflict resolution
scope.py scope matching (query + conflict)
bundle.py store.py immutable versioned bundles + store
query.py validate.py scoped queries + artifact validation
integrity.py fixture cross-check / anti-drift
service.py transport-independent service (+ hot reload)
mcp_server.py MCP server (stdio / http) + CLI
engine/ stable engine interface, registry, and adapters:
adapters/opa, adapters/conftest, adapters/checkov, adapters/semgrep
adapters/sarif shared SARIF normalization seam (used by checkov + semgrep)
harness/ the validation harness (checks/*)
sources/ bundled sample source repos (constraints, policies, fixtures)
scenarios/ self-contained fixtures for harness edge cases
tests/ pytest suite: adapter conformance, fixtures, import, e2e
docs/ RUNNING.md, MCP_CONTRACT.md, ADDING_AN_ENGINE.md
deploy/ launchd template for auto-starting the HTTP server
CONTRACTS.md the frozen engine-adapter seam new adapters code against
Run the adapter test suite directly with uv run pytest.
Contributions are very welcome — bug reports, new engine adapters, constraint sources, and docs. Adding an engine is intentionally small: one adapter module plus one config line, with no changes to the schema, importer, MCP server, or harness.
Before opening a PR, make sure uv run pytest and uv run cregistry-harness are
green; CI runs both on every pull request.
Licensed under the Apache License 2.0. See NOTICE for attribution and the licenses of the external engines this project integrates with.
Be the first to review this server!
by Modelcontextprotocol · Developer Tools
Read, search, and manipulate Git repositories programmatically
by Modelcontextprotocol · Developer Tools
Web content fetching and conversion for efficient LLM usage
by Toleno · Developer Tools
Toleno Network MCP Server — Manage your Toleno mining account with Claude AI using natural language.