Provides tools for auditing local Git repositories, including verifying version alignment with tags and ensuring project metadata consistency during the release process.
Validates the presence of GitHub-specific repository assets such as issue templates and CI workflow configurations to ensure compliance with release hygiene policies.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-policy-guardian check the release hygiene and version alignment of this repo"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Deterministic MCP server for validating release hygiene in local repositories. Network-free, read-only, governance-grade outputs.
mcp-policy-guardian is intentionally minimal and governance-oriented.
Contract stability
V1 tool schemas are frozen.
No behavioral changes without explicit phase reopening.
Canonical JSON outputs documented in docs/EXAMPLE_OUTPUTS.md.
Determinism
Network-free execution.
Read-only repository inspection.
Fail-closed semantics enforced.
Design rationale documented in docs/DETERMINISM_NOTES.md.
Reproducibility
Published to PyPI.
CI-validated on push.
Tag-triggered PyPI install smoke test ensures external install integrity.
See docs/V1_CONTRACT.md for the authoritative contract.
Related MCP server: mcp-release-guardian
mcp-policy-guardian exposes three tools via the Model Context Protocol:
Tool | What it does |
| Seven file/directory presence checks: package definition, LICENSE, README, bug report template, CI workflows, V1 contract doc, determinism notes doc |
| Reads |
| Generates a deterministic markdown checklist based on local repo state |
All tools are:
Network-free — no external API calls, ever
Read-only — no writes to the target repository
Fail-closed — unresolvable state marks that result as failed, not passed
pip install mcp-policy-guardianOr with uv:
uv tool install mcp-policy-guardianmcp-policy-guardianThe server starts on stdio and waits for MCP messages.
Add the following block to your claude_desktop_config.json
(~/Library/Application Support/Claude/claude_desktop_config.json on macOS):
{
"mcpServers": {
"mcp-policy-guardian": {
"command": "mcp-policy-guardian",
"args": []
}
}
}If you installed with uv tool:
{
"mcpServers": {
"mcp-policy-guardian": {
"command": "uvx",
"args": ["mcp-policy-guardian"]
}
}
}Restart Claude Desktop after editing the config.
Input:
{
"repo_path": "/ABS/PATH/TO/REPO"
}Example response:
{
"tool": "check_repo_hygiene",
"repo_path": "/ABS/PATH/TO/REPO",
"ok": true,
"checks": [
{ "check_id": "has_package_definition", "ok": true, "details": "Found pyproject.toml" },
{ "check_id": "has_license", "ok": true, "details": "Found LICENSE" },
{ "check_id": "has_readme", "ok": true, "details": "Found README.md" },
{ "check_id": "has_bug_report_template", "ok": true, "details": "Found .github/ISSUE_TEMPLATE/bug_report.yml" },
{ "check_id": "has_ci_workflows", "ok": true, "details": "Found .github/workflows/" },
{ "check_id": "has_v1_contract", "ok": true, "details": "Found docs/V1_CONTRACT.md" },
{ "check_id": "has_determinism_notes", "ok": true, "details": "Found docs/DETERMINISM_NOTES.md" }
],
"fail_closed": false
}ok is true only when all seven checks pass. fail_closed equals not ok.
Input:
{
"repo_path": "/path/to/my-project",
"expected_tag": "v1.2.0"
}expected_tag is optional. When omitted, the tool returns version metadata without performing a comparison.
Example response (match):
{
"tool": "check_version_alignment",
"repo_path": "/path/to/my-project",
"ok": true,
"expected_tag": "v1.2.0",
"detected": {
"version": "1.2.0",
"source": "pyproject.toml"
},
"details": "Version 1.2.0 matches expected tag v1.2.0",
"fail_closed": false
}Example response (version absent — fail-closed):
{
"tool": "check_version_alignment",
"repo_path": "/path/to/my-project",
"ok": false,
"expected_tag": "v1.2.0",
"detected": {
"version": null,
"source": null
},
"details": "Could not detect version: pyproject.toml missing or [project].version absent",
"fail_closed": true
}Version is read exclusively from pyproject.toml [project].version. The leading v in expected_tag is stripped before comparison.
Input:
{
"repo_path": "/path/to/my-project",
"target_tag": "v1.2.0"
}Example response:
{
"tool": "generate_release_checklist",
"repo_path": "/path/to/my-project",
"target_tag": "v1.2.0",
"checklist_markdown": "# Release Checklist — v1.2.0\n\n## Version alignment\n...",
"inputs_used": {
"detected_version": "1.2.0",
"has_ci_workflows": true,
"has_bug_template": true
},
"fail_closed": false
}fail_closed is true when detected_version is null (version undetectable). The checklist covers: version alignment, test run, tag creation, release notes, and adoption hooks verification.
git clone https://github.com/YOUR_ORG/mcp-policy-guardian.git
cd mcp-policy-guardian
pip install -e .
pytest -qSee docs/V1_CONTRACT.md for the frozen tool contracts
and docs/DETERMINISM_NOTES.md for the
determinism and fail-closed design rationale.
See docs/EXAMPLE_OUTPUTS.md for canonical example outputs.
MIT — see LICENSE.
Deterministic check for standard repository governance artifacts. Network-free, read-only, fail-closed.
Stable keys: tool, repo_path, ok, checks, fail_closed
| Name | Required | Description | Default |
|---|---|---|---|
| repo_path | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description explicitly states key behaviors: deterministic, network-free, read-only, and fail-closed. It also lists stable output keys, providing transparency about what the tool returns. This fully compensates for missing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: three short sentences covering purpose, constraints, and output keys. No redundant information, front-loaded with the key message.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no siblings, the description covers purpose, constraints, and output structure. It lacks detail about what specific artifacts are checked, but the stable keys and behavior hints provide enough context for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'repo_path' is not described in the description, leaving its format and semantics implicit. However, the parameter name is self-explanatory given the tool's purpose, and the schema provides the type. With 0% schema coverage, some description would be better, but the parameter is simple.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a deterministic check for standard repository governance artifacts. It specifies the action (check) and resource (repo policy) with enough specificity, though the exact artifacts could be elaborated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not mention prerequisites, contexts, or exclude inappropriate uses. With no sibling tools, the omission is less critical but still a gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Only one tool exists, so there is no possibility of confusion between tools.
The single tool name 'check_repo_policy' follows a clear verb_noun pattern, consistent with itself.
One tool is minimal but may be acceptable for a very narrow single-purpose server. However, given the server name 'Policy Guardian', a broader set of policy management tools would be expected.
The tool only checks for standard repository governance artifacts. There are no tools for applying policies, reporting, or managing exceptions, leaving significant gaps for a policy guardian server.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Scan any MCP server for tool-poisoning, security, auth & license. Trust score before install.
Conformance checker for MCP servers. Free, no key, verdicts recomputable and re-measured daily.
A MCP server built for developers enabling Git based project management with project and personal…
Trust checks for MCP servers: trust scores, tool-drift detection, signed diligence receipts. Free.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/curtis-d-williams/mcp-policy-guardian'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
