ai-governance-controls
This server provides MCP-compatible AI governance tools for reviewing AI system prompts, classifying deployment risk, planning red-team tests, and inspecting MCP server configurations.
ai_safety_screen: Screens a system prompt and optional deployment context for safety risks, returning a structured analysis framework.
ai_risk_classify: Classifies an AI deployment description into risk tiers and applicable regulations (EU AI Act, NIST AI RMF), returning a structured framework.
ai_red_team: Generates a bounded adversarial test plan (up to 30 test cases) for a system prompt, organized by attack category, without executing tests.
governance_search: Searches the bundled, versioned governance control library for matching controls and implementation-kit artifacts.
governance_get: Retrieves the exact objective, evidence requirements, or acceptance criteria for a specific control or kit artifact.
ai_control_review: Compares supplied documents or artifact text against selected control evidence requirements, reporting supported, gaps, or unknown evidence.
ai_mcp_review: Reviews a JSON MCP client configuration and captured tools/list manifest against an approved baseline, reporting new/removed tools, capability changes, mixed write/untrusted surfaces, and missing identity evidence.
ai_evidence_validate: Validates governance report structure, control IDs, finding statuses, and evidence-reference links.
ai_report_export: Exports a validated review as JSON, Markdown, or CSV while retaining stable finding and evidence-reference IDs.
ai_risk_classify_v2: Collects deployment facts, separates internal risk from jurisdiction applicability, and abstains when required facts are missing.
ai_output_validate: Validates supplied output samples against required fields, types, and patterns, reporting every failing sample.
ai_red_team_v2: Creates stable, versioned test cases with explicit pass criteria, marked not_run until a runner supplies results.
ai_eval_review: Imports red-team runner results, reports pass/fail/inconclusive coverage, and detects regressions against a prior equivalent run.
Click on "Deploy 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., "@ai-governance-controlsScreen this system prompt for safety risks: 'You can access customer financial data.'"
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.
AI Governance Controls
AI governance checks for MCP-compatible assistants. Use this server to review AI system prompts, classify deployment risk, plan adversarial testing, and inspect an MCP server configuration before connecting it to an agent.
Works in Claude Code, Cursor, Windsurf, Codex, and any other MCP-compatible tool.
Built on the control library from AI Governance Institute.
What the tools do
Tool | Control | What it does |
| Reviews a system prompt and deployment context for actuator, financial, personal-data, health, content, agentic, and authorization signals. Returns a host-readable review framework. | |
| Pre-screens a deployment description for high-impact sectors, automation, oversight, consequential decisions, scale, and relevant governance references. | |
| Produces a bounded test plan with stable attack categories and expected safe behavior. It does not run the tests. | |
| Finds matching controls and implementation-kit artifacts in the bundled, versioned library. | |
| Retrieves the exact objective, evidence requirements, or acceptance criteria for one control or kit artifact. | |
| Compares supplied documents or artifact text with selected control evidence requirements. Missing evidence remains unknown; it is never treated as proof of safety or compliance. | |
| Reviews a JSON MCP client configuration and captured | |
| Checks report structure, control IDs, finding statuses, and evidence-reference links. | |
| Exports a validated review as JSON, Markdown, or CSV while retaining stable finding and evidence-reference IDs. | |
| Collects deployment facts, separates internal risk from jurisdiction applicability, and abstains when required facts are missing. | |
| Validates actual supplied output samples against required fields, types, and patterns. | |
| Creates stable, versioned test cases with explicit pass criteria. Plans are marked | |
| Imports test outcomes, reports coverage and inconclusive cases, and detects regressions against a prior equivalent run. |
The governance library is bundled with the package so the same package version uses the same control wording and evidence requirements on every run. governance_search and governance_get are the way to inspect that library; you do not need to load the entire catalog into your prompt.
Related MCP server: scan-your-ai-toolkit
MCP configuration review
ai_mcp_review is a static review. Give it the configuration your MCP client would use, a captured tools/list response, and optionally the previously approved manifest. For example:
{
"config": {
"mcpServers": {
"github": {
"command": "github-mcp-server",
"args": ["--repository", "acme/project"]
}
},
"metadata": {
"identity": "svc-agent-github",
"scopes": ["issues:read"]
}
},
"tool_manifest": {
"tools": [
{
"name": "list_issues",
"description": "List issues in the approved repository",
"annotations": {"readOnlyHint": true}
}
]
},
"approved_baseline": {
"tools": [
{
"name": "list_issues",
"description": "List issues in the approved repository",
"annotations": {"readOnlyHint": true}
}
]
}
}The review parses those values as data. It does not launch the configured command, install a package, connect to an endpoint, read environment variables, or retrieve credentials. A tool description or readOnlyHint is treated as a claim to review, not as proof that the runtime enforces that behavior. The output identifies what still needs an owner, publisher verification, scope evidence, approval, or runtime testing.
Installation
Add this block to your MCP configuration file. No global install required.
{
"mcpServers": {
"ai-governance-controls": {
"command": "uvx",
"args": ["ai-governance-controls"]
}
}
}Configuration file locations:
Claude Code:
.claude/settings.json(project) or~/.claude/settings.json(global)Cursor:
.cursor/mcp.jsonWindsurf:
.windsurf/mcp.json
Requires uv to be installed.
Usage
Once installed, call the tools directly in conversation.
Prompt safety screening (ai_safety_screen):
Screen this system prompt for safety risks: "You are a customer service assistant with access to customer accounts. You can initiate transfers up to $10,000 on behalf of verified customers."
Deployment risk intake (ai_risk_classify or ai_risk_classify_v2):
Classify this deployment using structured facts: a clinical decision-support system used by an EU hospital, processing patient health data, with a clinician reviewing every recommendation before treatment.
Red-team planning (ai_red_team or ai_red_team_v2):
Create 15 adversarial test cases for this healthcare assistant. It can read patient records and call a prescription tool. Include prompt injection, tool abuse, data extraction, and boundary-probing cases, but do not run them.
MCP deployment review (ai_mcp_review):
Review this captured MCP configuration and
tools/listmanifest against the approved baseline. Identify added tools, permission changes, missing identity evidence, and any tool that combines write access with untrusted content.
Find governance material (governance_search):
Search the governance library for controls and kit artifacts about MCP tool permissions and prompt injection.
Retrieve one requirement (governance_get):
Retrieve the evidence requirements and acceptance criteria for AGT-019.
Review supplied evidence (ai_control_review):
Review this server inventory and intake document against AGT-019 and identify which evidence requirements are supported, gaps, or still unknown.
Validate an output sample (ai_output_validate):
Validate these representative JSON outputs against a rule requiring an object with
decisionandreasonfields, and report every failing sample.
Validate a governance bundle (ai_evidence_validate):
Validate this proposed governance report and flag supported findings that lack evidence references or reference unknown controls.
Export a review (ai_report_export):
Export this validated review as JSON for systems integration, Markdown for a reviewer, or CSV for a tracking spreadsheet.
Review imported evaluation results (ai_eval_review):
Import these red-team runner results, report pass/fail/inconclusive coverage, and compare them with the prior equivalent run for regressions.
How it works
The prompt, risk, and red-team tools perform lightweight deterministic pre-screening and return a bounded framework for the host assistant to complete. The governance and MCP review tools perform deterministic checks against the bundled offline library and return structured findings. Evidence references record the artifact, hash, source, capture time, locator, and whether the basis was supplied, observed, or inferred.
These tools assist a governance review; they do not certify an organization, determine legal applicability conclusively, prove runtime enforcement, or execute a red-team plan. A generated test plan has status not_run until execution results are supplied by a separate runner. Missing facts and missing evidence are returned explicitly so a reviewer can decide what to collect next. No additional API key is required, and the server performs no automatic telemetry or remote inference.
The structured risk tool treats the EU AI Act and NIST AI RMF differently: EU results are potential applicability records that require legal review, while NIST is reported as voluntary framework guidance. The output validator checks the samples you provide; it does not generate samples or decide whether an output is substantively correct. Evaluation review distinguishes pass, fail, and inconclusive, and a model judge alone is not proof that a real-world side effect occurred.
Documentation rule for future tools
Every new tool must be added to the “What the tools do” table with a direct link to the corresponding control, playbook, kit, or other reviewed content on aigovernance.com. Its entry must describe the input, the output, and the boundary of what it does not prove. Every new tool must also have a concrete example in Usage. Keep internal release names out of these user-facing descriptions.
Requirements
Any MCP-compatible AI tool (Claude Code, Cursor, Windsurf, Codex, etc.)
License
Apache 2.0. See LICENSE.
More
Full control library, self-assessment wizard, and real-time regulatory alerts at aigovernance.com.
Available Tools
3 toolsai_red_teamA
Generate adversarial test cases for an AI system prompt (SEC-005).
Produces a red team runbook: specific adversarial inputs tailored to the system prompt, organized by attack category. Returns a structured framework for the host to generate the test cases.
Args: system_prompt: The system prompt to red team. num_test_cases: Number of test cases to generate (default 10, max 30).
| Name | Required | Description | Default |
|---|---|---|---|
| system_prompt | Yes | ||
| num_test_cases | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must cover behavior. It states the output is a 'red team runbook' and 'structured framework', but does not disclose any side effects, permissions, or rate limits. Adequate but minimal.
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?
The description is concise with two paragraphs. Front-loaded with the core purpose, followed by parameter details. Every sentence adds value, no fluff.
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?
With an output schema present, the description need not detail return values. It covers purpose, output type, and parameters effectively. Could benefit from a brief example or more detail on the runbook structure, but is largely complete for a simple tool.
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?
Schema coverage is 0%, but the description includes an 'Args' section that explains both parameters: system_prompt (the prompt to test) and num_test_cases (default 10, max 30). Adds significant meaning beyond the schema's bare titles and types.
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?
Clearly specifies the verb 'Generate adversarial test cases' and the resource 'AI system prompt', with a security procedure reference (SEC-005). Distinguishes itself from siblings ai_risk_classify and ai_safety_screen by its specific red-teaming focus.
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?
The description implies usage for testing AI prompts, but lacks explicit guidance on when to use this tool versus siblings or when not to use it. No exclusions or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ai_risk_classifyA
Classify an AI deployment's risk tier and applicable regulations (HOC-001).
Evaluates a deployment description against the HOC-001 risk classification control, referencing EU AI Act risk tiers and NIST AI RMF. Returns a structured analysis framework for the host to complete.
Args: deployment_description: Description of the AI system and how it is deployed. Include: what the system does, who uses it, what decisions it influences, what data it processes, and any human oversight in place.
| Name | Required | Description | Default |
|---|---|---|---|
| deployment_description | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the evaluation process and references regulations, and notes the return is a 'structured analysis framework for the host to complete,' implying interactive use. No annotations are present, so the description carries the full burden but does not disclose all behavioral traits (e.g., side effects, auth requirements).
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?
The description is well-structured with a clear purpose statement, explanation of the evaluation framework, and an Args section. It is reasonably concise for the complexity, though some sentences could be tightened.
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?
Given the single parameter and presence of an output schema, the description provides adequate context for the tool's purpose and input. The notion of a 'structured analysis framework' is somewhat vague, but sufficient for an agent to understand the tool's role.
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?
With 0% schema description coverage, the description compensates by providing detailed guidance on what to include in the deployment_description parameter (system purpose, users, decisions, data, oversight). This adds significant meaning beyond the schema's basic type and title.
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?
Clearly states it classifies risk tier and applicable regulations for an AI deployment, referencing specific controls (HOC-001, EU AI Act, NIST AI RMF). Does not explicitly differentiate from sibling tools like ai_red_team and ai_safety_screen, but the distinct purpose is evident.
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?
Provides guidance on when to use (evaluating deployment description against HOC-001) and what to include in the description. Lacks explicit when-not-to-use examples or alternatives, though the context of siblings might imply they are for different tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ai_safety_screenA
Screen an AI system's configuration for safety risks (SAF-001).
Evaluates a system prompt against the SAF-002 output validation control. Returns a structured analysis framework for the host to complete.
Args: system_prompt: The system prompt or configuration to screen. context: Optional deployment context (e.g. "customer-facing chatbot for a bank").
| Name | Required | Description | Default |
|---|---|---|---|
| system_prompt | Yes | ||
| context | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it evaluates against SAF-002 and returns a framework for the host to complete, but does not detail the evaluation process, side effects, or whether it runs actual checks. No annotations were provided to supplement.
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?
Two sentences plus a clean Args block. Efficient but could condense further. Information is well front-loaded.
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?
Given an output schema exists, description does not need to detail return format. Covers core behavior and parameters. Could elaborate on output usage or integration with other safety tools.
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?
Description includes an Args section explaining both parameters (system_prompt and context) with practical examples, adding meaning beyond the schema which only provides titles and types. Schema coverage is effectively 100% via description.
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?
Clearly states the tool screens an AI system's configuration for safety risks (SAF-001) and evaluates a system prompt against a control. Differentiates from siblings (ai_red_team, ai_risk_classify) by focusing on prompt screening versus red teaming or risk classification.
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?
Implies usage for safety screening but does not explicitly specify when to use this tool versus siblings. Lacks 'when-not-to-use' instructions or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
3 tool updates
v0.1.0- First observed
ai_red_team - First observed
ai_risk_classify - First observed
ai_safety_screen
TDQS
Scored across 3 tools
Each tool targets a distinct governance activity: red teaming, risk classification, and safety screening. No overlap in purpose, making them easily distinguishable for an agent.
All tools use snake_case with 'ai_' prefix and a descriptive term + action. 'ai_red_team' slightly deviates as noun-noun versus verb-noun in others, but the pattern is mostly consistent.
Three tools cover core governance areas but feel minimal for a comprehensive governance suite. The count is acceptable for a focused server but borderline low for broader coverage.
Only three of many possible AI governance controls are implemented (e.g., missing bias, privacy, explainability). Moreover, tools return analysis frameworks rather than performing actual analysis, leaving significant gaps.
Maintenance
Related MCP Connectors
MCP-native AI evaluation: rubric audits, eval suites, and proof reports for AI/LLM output.
Find, vet, and run MCP tools through a secure audited gateway with prompt-injection risk scoring
Zero-secret MCP gateway for AI agents: risk-scored, audited calls with human-in-the-loop approval.
Compliance frameworks (SOC 2, ISO 27001, CMMC, NIST, more) delivered to AI agents as MCP tools.
Related MCP Servers
- AlicenseBqualityCmaintenancePre-execution governance for AI agents. 45 MCP tools for hold queues, audit trails, risk scoring, and policy enforcement. Validates agent actions before they execute.4539 npm1MIT
- FlicenseNot gradedqualityNot gradedmaintenanceOpen-source AI governance toolkit. MCP servers & CLIs for scanning, auditing, and managing your AI environment-
- AlicenseNot gradedqualityDmaintenanceQuantitative governance gate for AI agents. Six gates (risk, profit, novelty, complexity, quality, utility) return PROCEED/PAUSE/HALT/ESCALATE with confidence scores and hash-chained, tamper-evident audit trails. Generates NIST AI RMF and EU AI Act Annex IV artifacts. 10 MCP tools; local stdio and hosted Streamable HTTP with a free tier.MIT

AgentsGateofficial
AlicenseNot gradedqualityAmaintenanceEnables AI agents to securely call MCP tools with risk scoring, checkpoints, rollback, and approval workflows.6 npmMIT