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., "@governance-gateway check this message for PII and safety before I send it: 'Email me at jane@example.com'"
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.
Governance checks that an AI agent runs before it acts, built so they keep up with the agent instead of falling behind it.
Every request gets a format check and a personal-data (PII) scan, which never skip. A safety classifier, which flags toxic text and jailbreak attempts, is the slow, optional check: it runs only if a cheap screen finds the text suspicious and it can still finish before the request's deadline. Under load, a guardrail that checks everything falls behind and its checks finish after the agent has already acted; this one stays on time and never drops the privacy check.
It runs locally as an MCP server, so text never leaves your machine, and works with any MCP client: Claude Desktop, Claude Code, Cursor, VS Code, Gemini CLI and others. In Claude Code an optional hook makes the checks compulsory for every command, file write and web request the agent makes.
With uv nothing needs installing in advance:
uvx governance-gateway --versionOr with pip: pip install governance-gateway, then run governance-gateway.
Python 3.10 or later; the only dependency is the mcp package.
Related MCP server: genpark-jev-system1-subconscious-decision-skill
Claude Desktop: in claude_desktop_config.json (Settings > Developer > Edit Config):
{
"mcpServers": {
"governance-gateway": { "command": "uvx", "args": ["governance-gateway"] }
}
}Cursor: the same block in ~/.cursor/mcp.json (or .cursor/mcp.json in a project).
Gemini CLI: the same block in ~/.gemini/settings.json.
VS Code (Copilot agent mode): in .vscode/mcp.json:
{
"servers": {
"governance-gateway": { "type": "stdio", "command": "uvx", "args": ["governance-gateway"] }
}
}Claude Code:
claude mcp add governance-gateway -- uvx governance-gatewayIf you installed with pip, use "command": "governance-gateway" and no args.
Tool | What it does |
| Runs the checks. Returns |
| Requests so far: verdicts, mean and 95th-percentile lag, share on time, share of classifier checks skipped or screened out. |
| The latest decisions: verdict, kinds of personal data found, timing. No text. |
| For a pipeline's deadline, traffic shape, peak-hour factor, detector recall, target and cost share: whether checking everything is enough, adaptive checking is needed, or only more capacity helps. |
| Races "check everything" against the deadline-aware guard on a simulated clock with measured check costs. |
Resources: governance://status and governance://policy (which checks run, which are
mandatory, and how the gateway decides). All tools are read-only.
An MCP tool is only called when the agent decides to call it. In Claude Code a
PreToolUse hook can run the check before every action instead. The easiest way is the
governance-guard plugin, which adds both the server and the hook:
/plugin marketplace add tanishq-ctrl/governance-gateway
/plugin install governance-guard@governance-gatewayOr add the hook yourself to ~/.claude/settings.json (or a project's
.claude/settings.json):
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash|Write|Edit|MultiEdit|NotebookEdit|WebFetch",
"hooks": [
{
"type": "command",
"command": "uvx",
"args": ["--from", "governance-gateway", "governance-gateway-hook"],
"timeout": 10,
"onFailure": "block"
}
]
}
]
}
}The hook sends the text of each action (the command, the file content, the URL) to the
running gateway, with a budget of GSL_HOOK_DEADLINE_MS (default 200 ms):
harmful or malformed: the action is refused and the agent is told why;
personal data found: you are asked whether to allow it;
otherwise: nothing changes, and your normal permissions apply.
If the gateway is not running, the hook still runs the personal-data scan itself. If the
check cannot run at all, the action is blocked (set GSL_FAIL_OPEN=1 to allow it
instead). Addresses at GSL_ALLOW_EMAIL_DOMAINS (default anthropic.com, users.noreply.github.com, example.com) are ignored, so commit trailers pass.
Option | Environment | Default | Meaning |
|
|
| Run the suspicion screen before the classifier |
|
|
| How the classifier's cost is estimated from recent checks |
|
| 1 | Workers serving the queue |
|
| none | Append one JSON line per decision (no text) |
|
| 8737 | Local port for the hook (127.0.0.1 only) |
| Do not open the local port |
Personal data: e-mail addresses, telephone numbers and US-style national ID numbers, by pattern. Names, postal addresses and other identifiers are not detected.
Harmful text: a TF-IDF and logistic-regression classifier trained on ToxicChat, real prompts to a public chatbot labelled by people. On held-out ToxicChat messages it catches about 6 in 10 harmful messages with a precision of about 0.78; it is a light first line of defence, not a complete safety system, and it was trained on English.
The screen passes on 95% of harmful messages in validation and sends about 31% of ordinary traffic to the classifier.
Use it alongside, not instead of, your organisation's own data-protection controls.
The gateway comes from an MSc project that measured how far governance checks fall behind fast automated decisions as load grows. Checking everything collapses at full capacity: on real chatbot traffic it stopped meeting its target at 77% of capacity. The deadline rule held to 1.06, and the screen plus the deadline rule to 1.44, while keeping the privacy check on time.
Prabhu, T. S. (2026). Quantifying "Governance Speed Lag" (GSL) in Agentic AI Ecosystems: A simulation-based framework for self-adaptive real-time data compliance. MSc Data Science project, VIT.
https://github.com/tanishq-ctrl/governance-gateway
Code: MIT. The bundled models and workload data are derived from ToxicChat and are for non-commercial use only (CC BY-NC 4.0); see LICENSE-DATA.md.
Check a text before acting on it: format, personal data (always) and safety (if time allows).
Returns the verdict ('allow', 'redact' or 'block'), the reasons, the redacted text when personal data was found, whether the safety classifier ran, and the timing against the deadline. The original text is never echoed back.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| deadline_ms | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnlyHint/openWorldHint annotations by disclosing the verdict vocabulary, that the safety classifier may be skipped under time pressure, that the original text is never echoed back, and that timing is measured against the deadline. These are exactly the behavioral facts an agent needs before calling.
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?
Front-loaded with the core action and the check ordering, and the second sentence covers the return contract compactly. Slightly dense but no filler sentences.
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?
Output schema exists, so describing return values is a bonus rather than a requirement, and the deadline behavior is the main remaining gap. For a 2-parameter read-only checker the description is nearly sufficient to call 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?
Schema description coverage is 0%, so the description must compensate. It indirectly explains deadline_ms via 'if time allows' and 'timing against the deadline', but never states units, the 100ms default, or what happens when the deadline is exceeded, so compensation is only partial.
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?
States a specific verb and resource ('check a text') and enumerates the three dimensions checked: format, personal data, safety. The purpose is immediately clear, though there is no naming of the sibling tools since they are governance/decision tools rather than other text checkers.
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?
Gives a clear trigger ('before acting on it') and priority guidance: personal data is checked always, safety only if time allows. It doesn't name an alternative tool or state when-not to use this, which keeps it below a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Which checking policy a pipeline needs at a given mean load (the project's decision matrix).
traffic: 'even', 'random' or 'bursty'. peak_factor: busiest-hour ratio q (1 = steady). recall: the detector's recall with no queue; target: required share caught in time; cost_share: the detector's share of checking cost; load: mean arrivals ÷ capacity.
| Name | Required | Description | Default |
|---|---|---|---|
| load | No | ||
| recall | No | ||
| target | No | ||
| traffic | No | random | |
| cost_share | No | ||
| deadline_ms | No | ||
| peak_factor | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the agent knows this is a closed-domain read, and an output schema exists to explain the result. The description adds only that the parameters describe load, traffic shape and detector properties — it says nothing about how the matrix is resolved, whether defaults are sensible, or how results vary with traffic pattern.
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 purpose sentence is front-loaded and the remaining lines are a compact parameter glossary where each line earns its place. The telegraphic style ("recall: the detector's recall with no queue") occasionally reads as shorthand rather than prose, but nothing is padded.
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 7-parameter analytical tool with no required params and no schema descriptions, the definition does most of the semantic work and the output schema covers return values. The gaps are real though: deadline_ms is unexplained, no value ranges or units are given for the numeric inputs, and there is no indication of what the returned policy looks like or how to read it.
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 across 7 parameters, the description carries the full burden and mostly succeeds: it defines traffic (including the enum values 'even', 'random', 'bursty' that the schema does not enumerate), peak_factor as the busiest-hour ratio with a worked example, plus recall, target, cost_share and load. Only deadline_ms is left entirely undefined, which keeps it out of the top score.
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 frames the tool as answering "which checking policy a pipeline needs at a given mean load", which is a recognizable decision/lookup task rather than a verb+resource statement. It never says what form the answer takes (a policy name? a tier?) and never distinguishes itself from the sibling simulate_load, so an agent can't cleanly tell which of the two to reach for.
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?
There is no when-to-use guidance at all — no conditions, prerequisites, or named alternatives among check_message, simulate_load, or recent_decisions. The closest signal is the parenthetical "(the project's decision matrix)", which hints at context but gives no invocation rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Requests handled so far: verdicts, lag (mean, p95), share on time, share skipped.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered, and the output schema documents the return payload the description is enumerating. What remains undisclosed is genuinely behavioral: the time window implied by 'so far' (since process start? since deployment? rolling window?), whether counters reset, and whether the tool is per-instance or global. Those gaps matter for a metrics tool and are not covered by any structured field.
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?
It is a single short line with no padding, which is good, but it is a colon-led fragment rather than a complete sentence — there is no lead verb to anchor the metric list. Front-loading is fine; the grammatical incompleteness slightly undercuts immediate comprehension.
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 zero-parameter, read-only tool with a full output schema and clear annotations, most of the burden is already carried by structured fields, and the description correctly avoids restating return values in detail. The only substantive omission is the scope of 'so far' and its relationship to the other observability siblings.
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 zero parameters there is nothing for the description to disambiguate, so the baseline applies. The description correctly implies a parameterless snapshot call rather than a filtered query, which is consistent with the empty schema.
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 lists the metrics exposed ('verdicts, lag (mean, p95), share on time, share skipped') but never states a verb or object — it is a noun-phrase fragment, not a statement that this tool reports governance telemetry. An agent can infer it is a read-only status/metrics endpoint, but it is not distinguished from siblings such as recent_decisions or decision_matrix, which could plausibly return overlapping information.
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?
There is no guidance on when to call this versus recent_decisions (which likely also surfaces verdicts) or decision_matrix. No prerequisites, no mention of whether the call is cheap, cacheable, or safe to poll repeatedly, and no exclusions. The agent must guess its place in the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The latest governance decisions, newest last: source, verdict, kinds of personal data found, whether the classifier ran, and timing. The checked text is never included.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely non-derivable behavior: ordering ('newest last') and the privacy guarantee that 'the checked text is never included' — an important disclosure about what is withheld. It says nothing, however, about truncation, pagination, or how the limit interacts with ordering.
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?
One tight sentence with the ordering constraint front-loaded and the privacy caveat in a second short clause; nothing is wasted. The field enumeration is long, but it is the substantive payload of the sentence rather than filler.
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 simple read-only tool with an output schema and explicit annotations, most of what an agent needs is present: what it returns, in what order, and what is excluded. The gaps are the unexplained limit parameter and the absence of any note on result truncation or how to reach older decisions.
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% and the single 'limit' parameter (default 20) is never explained — whether it caps the number of decisions returned, whether results are truncated silently, and what the maximum is remain unknown. With zero schema documentation, the description needed to compensate and does not.
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 names the resource precisely ('the latest governance decisions') and enumerates what each record contains (source, verdict, data kinds, classifier flag, timing), which clearly separates it from siblings like decision_matrix or governance_status. The verb is only implicit — it reads as a noun phrase rather than 'List/Return' — but an agent can still tell what it retrieves.
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?
There is no explicit when-to-use guidance: nothing says to call this instead of governance_status for a summary or decision_matrix for aggregate views, and no conditions or prerequisites are stated. The word 'recent' implies a recency-scoped read, but that is inference, not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Race 'check everything' against the deadline-aware guard with measured check costs.
traffic: 'steady', 'rush_hour' or 'real_chatbot' (real WildChat timings). Returns, for each guard, the final lag, harmful messages caught in time, the share of PII checks on time and the share of classifier checks skipped.
| Name | Required | Description | Default |
|---|---|---|---|
| load | No | ||
| seed | No | ||
| seconds | No | ||
| traffic | No | steady | |
| deadline_ms | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), and the description usefully clarifies that this is a simulation producing comparative metrics per guard rather than a real-traffic operation. It does not say anything about cost, runtime, or whether the simulation is deterministic given the seed — and it repeats return fields that the output schema already documents.
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?
Front-loads the core purpose in one sentence, then attaches parameter and return notes compactly; no filler sentences. The awkward line breaks and the phrase "'check everything'" in quotes, which is never defined, cost a little clarity.
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?
An output schema exists, so declining to explain the returned metrics in detail is acceptable. But with five undocumented parameters and a jargon term ('check everything', 'deadline-aware guard') that is never defined relative to the sibling tools, an agent cannot confidently set load, seconds, or deadline_ms without guessing.
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 description coverage is 0% across five parameters, so the description carries the burden and only partially meets it: it enumerates the three valid traffic values ('steady', 'rush_hour', 'real_chatbot' with WildChat timings), which is genuinely useful since the schema has no enum. Load, seed, seconds, and deadline_ms are entirely undefined — no units, ranges, or effect on the simulation.
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?
States a specific action: race a 'check everything' strategy against a 'deadline-aware guard' with measured check costs, which together with the name simulate_load makes clear this is a load/stress simulation. It does not explicitly distinguish itself from siblings like check_message or decision_matrix, so an agent must infer that this is the offline simulation counterpart to live checking.
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 explicit when-to-use or when-not-to-use statement, and no mention of prerequisites or alternatives. Usage is implied by the word 'simulate' and by the traffic-mode list, from which an agent can infer this is for pre-deployment capacity testing rather than live message checking, but the routing decision against check_message is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.1check_messagedecision_matrixgovernance_statusrecent_decisionssimulate_loadScored across 5 tools
Each tool has a clearly distinct role: check_message performs an actual check, governance_status reports aggregate metrics, decision_matrix recommends a policy by load, simulate_load runs comparative simulations, and recent_decisions lists recent records. The only mild adjacency is between status metrics and recent decisions, but their granularity and use cases are clearly different.
The names mix verb_noun (check_message, simulate_load) with noun_noun or adjective_noun phrases (governance_status, decision_matrix, recent_decisions). It remains readable, but there is no predictable verb-first or resource-first convention across the set.
Five tools is well scoped for a governance gateway: one operational check, one status view, one recent-decisions view, one policy matrix, and one simulation. Each tool has a clear purpose and none feels redundant or excessive.
The surface covers the core lifecycle: checking text, inspecting aggregate and recent outcomes, evaluating policy by load, and simulating alternatives. Minor gaps remain around configuring or updating policies/thresholds and drilling into per-source or per-rule details, but the main workflows are covered.
Deterministic runtime safety for AI agents: scan PII, gate tool actions, verify LLM output.
Real-time MCP & A2A prompt-injection, jailbreak, and tool-schema poisoning firewall for AI agents.
AgentGuard — 20-tool AI safety MCP: policy preflight, risk scoring, audit logging, rate limits.
Scan prompts for injection attacks, redact PII, and audit LLM SDK usage from any MCP client
