Skip to main content
Glama
cody-aigov
by cody-aigov

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

ai_safety_screen

SAF-002

Reviews a system prompt and deployment context for actuator, financial, personal-data, health, content, agentic, and authorization signals. Returns a host-readable review framework.

ai_risk_classify

HOC-001

Pre-screens a deployment description for high-impact sectors, automation, oversight, consequential decisions, scale, and relevant governance references.

ai_red_team

SEC-005

Produces a bounded test plan with stable attack categories and expected safe behavior. It does not run the tests.

governance_search

Governance controls and playbooks

Finds matching controls and implementation-kit artifacts in the bundled, versioned library.

governance_get

Governance controls and playbooks

Retrieves the exact objective, evidence requirements, or acceptance criteria for one control or kit artifact.

ai_control_review

MCP governance playbook

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.

ai_mcp_review

MCP governance playbook

Reviews a JSON MCP client configuration and captured tools/list manifest against an approved baseline. Reports new tools, removed tools, capability changes, mixed write/untrusted-content surfaces, and missing identity evidence.

ai_evidence_validate

Audit-ready AI documentation

Checks report structure, control IDs, finding statuses, and evidence-reference links.

ai_report_export

Audit-ready AI documentation

Exports a validated review as JSON, Markdown, or CSV while retaining stable finding and evidence-reference IDs.

ai_risk_classify_v2

AI system risk classification

Collects deployment facts, separates internal risk from jurisdiction applicability, and abstains when required facts are missing.

ai_output_validate

AI output validation

Validates actual supplied output samples against required fields, types, and patterns.

ai_red_team_v2

Adversarial robustness testing

Creates stable, versioned test cases with explicit pass criteria. Plans are marked not_run until a runner supplies results.

ai_eval_review

Adversarial robustness testing

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.json

  • Windsurf: .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/list manifest 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 decision and reason fields, 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.)

  • uv


License

Apache 2.0. See LICENSE.


More

Full control library, self-assessment wizard, and real-time regulatory alerts at aigovernance.com.

Available Tools

3 tools
ai_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).

ParametersJSON Schema
NameRequiredDescriptionDefault
system_promptYes
num_test_casesNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior3/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

ParametersJSON Schema
NameRequiredDescriptionDefault
deployment_descriptionYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose4/5

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.

Usage Guidelines3/5

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").

ParametersJSON Schema
NameRequiredDescriptionDefault
system_promptYes
contextNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

  1. 3 tool updatesv0.1.0
    • First observedai_red_team
    • First observedai_risk_classify
    • First observedai_safety_screen

TDQS

A3.6/5.0

Scored across 3 tools

Disambiguation5/5

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.

Naming Consistency4/5

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.

Tool Count3/5

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.

Completeness2/5

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

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    D
    maintenance
    Quantitative 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
  • A
    license
    Not graded
    quality
    A
    maintenance
    Enables AI agents to securely call MCP tools with risk scoring, checkpoints, rollback, and approval workflows.
    6 npm
    MIT