Global AI Governance MCP server
A read-only, non-authorizing MCP server for calling Global AI Governance reference checks, with every result marked authority_effect: NONE and left for human decision.
Run policy-as-code governance checks on an AI system inventory CSV (
check_inventory) and get findings by severity, or use the synthetic sample.Prepare and integrity-check a Decision Pack manifest with a reference-only handoff, optionally returning Markdown documents for human review (
build_decision_pack).Verify an Agent Trust Passport's schema, semantics, Ed25519 signature, key trust, validity window, and signed revocation (
validate_passport), using built-in examples or caller-supplied JSON.Call these via local stdio or a self-hosted Streamable HTTP endpoint; all tools are annotated read-only, idempotent, non-destructive, and closed-world.
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., "@Global AI Governance MCP serverrun a governance inventory check on my AI systems CSV and summarize findings"
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 Model Context Protocol Server (AI Governance MCP)
Global AI Governance · v0.5.1 · released · authority_effect: NONE
Start where you are · Connect your agent · Specifications · All products
Suite path, step 3 of 9: connect your agents · ← Toolkit · Agentic AI Governance → · start anywhere
Governance checks your AI agents can call. Start the server with one command, and your agent can check an AI system inventory, prepare a Decision Pack, or verify an Agent Trust Passport. Every result is read-only and leaves the decision with a person.
uvx --from git+https://github.com/GLOBAL-AI-GOVERNANCE/ai-governance-mcp@v0.5.1 gaig-mcpModel Context Protocol (MCP) is an open standard that lets AI assistants discover and call external tools through a common interface. This repository is a non-authorizing MCP server for Global AI Governance reference tooling.
Status: Released · v0.5.1. Run it locally with the command above or self-host it. No hosted endpoint is operated, and it is not listed in any platform directory.
Names: the console command is gaig-mcp, the import package is gaig_mcp, the MCP server name reported to clients is gaig-mcp, and environment variables use the GAIG_MCP_ / GAIG_ prefixes. The Python distribution and the desktop-extension manifest name are also gaig-mcp (wheel gaig_mcp).
v0.3.0 removed the older names. Only the names above work. If an environment variable from before v0.3.0 is still set, the server refuses to start and names the GAIG_* variable to use instead, so a security setting is never silently dropped.
AI Governance MCP exposes the real Global AI Governance reference tooling to MCP clients:
Tool | What it does | Upstream code it runs |
| Policy-as-code governance checks on an AI system inventory CSV. Returns findings by severity |
|
| Prepares the digest-listed Decision Pack, verifies its integrity, and returns the manifest, the reference-only handoff, and optional Markdown documents | toolkit |
| Verifies an Agent Trust Passport: schema, semantics, Ed25519 signature, key trust, validity window, and signed revocation (all checks run for the built-in examples; caller-supplied JSON has limits, see "Known limits") |
|
Authority boundary, enforced in code and tests. Every result carries authority_effect: "NONE", the review_boundary text, and human_decision_state: "PENDING_HUMAN_DECISION". Upstream fields that an assistant could paraphrase as an authorization are relabeled, with their values left verbatim:
operating_disposition→reference_policy_dispositionissued_assessment_result→assessment_result_recorded_in_artifact
The test suite fails if any output contains an authorization-like key, a non-NONE authority effect, conditionally_authorized, or a PERMITTED value outside the relabeled field. All three tools are annotated readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: false, and each has a title.
Compatible with MCP-based agents. Not affiliated with or endorsed by xAI, OpenAI, Anthropic, or any other model provider.
What has been tested, and what has not:
Protocol compatibility: tested with the official MCP Python SDK client (
mcp==2.3.0, stdio and Streamable HTTP,scripts/smoke_test.py) and the MCP Inspector CLI (2.11.0, stdio, and HTTP with a bearer token).Simulated provider schema checks: none performed.
Provider-client connectivity: one recorded test run. Codex CLI 0.151.0, local stdio, at commit
c71457b9660608f0135d8e6169d60f6bfdbe0013(merged as9abb2061a7a60e065ba999157787ae6091cb8581): discovery, tool listing,check_inventory, andvalidate_passportwith caller-supplied JSON strings. This is one TESTED run, not independently reproduced, and does not establish broader OpenAI compatibility, ChatGPT remote connectivity, Claude integration, or Grok connectivity. The provider sections below are configuration guidance from each provider's public documentation, not tested connections.
Install and run (local)
No clone needed. The pinned toolkit and agentic files are bundled in the package (src/gaig_mcp/_upstream/, source lock in UPSTREAM_LOCK.json), so this runs with no other checkout:
uvx --from git+https://github.com/GLOBAL-AI-GOVERNANCE/ai-governance-mcp@v0.5.1 gaig-mcp # stdioTESTED in a clean environment. Copy-paste client configs for Cursor, VS Code, Codex, Claude Code, the Grok CLI, and the Gemini CLI are in examples/client-configs/; agent-framework patterns and the Action Level guard are in examples/agent-stacks/.
From source:
git clone https://github.com/GLOBAL-AI-GOVERNANCE/ai-governance-mcp.git
cd ai-governance-mcp
python3 -m venv .venv && . .venv/bin/activate
pip install -e ".[dev]"
gaig-mcp # stdio
gaig-mcp --http --port 8000 # Streamable HTTP at http://127.0.0.1:8000/mcp ; GET /health
pytest # 144 tests
python scripts/smoke_test.py --transcript docs/verification-transcript.mdRelated MCP server: io.github.aileron-sh/aileron
Sample call
After the from-source install steps above.
Success — synthetic sample, pinned evaluation time used by the test suite:
python -c 'from gaig_mcp.core import check_inventory
out = check_inventory(use_sample=True, evaluation_time="2026-10-16T00:00:00Z")
assert out["authority_effect"] == "NONE"
assert out["human_decision_state"] == "PENDING_HUMAN_DECISION"
assert out["tool"] == "check_inventory"
r = out["result"]
assert r["validation_state"] == "VALID"
assert r["finding_count"] == len(r["findings"]) > 0
assert r["findings_by_severity"].get("CRITICAL", 0) >= 1
print(r["validation_state"], r["finding_count"])'Expected: VALID and a finding count greater than zero, including at least one CRITICAL finding. authority_effect stays NONE. human_decision_state stays PENDING_HUMAN_DECISION. The findings are reference results for human review. They do not authorize deployment.
Failure — both inputs at once:
python -c 'from gaig_mcp.core import check_inventory, GaigInputError
try:
check_inventory(inventory_csv="a,b\n", use_sample=True)
except GaigInputError as exc:
print(exc)'Expected: Provide inventory_csv or use_sample=true, not both.
Failure — no input:
python -c 'from gaig_mcp.core import check_inventory, GaigInputError
try:
check_inventory()
except GaigInputError as exc:
print(exc)'Expected: inventory_csv is empty. Supply CSV text or set use_sample=true.
Your own inventory — start from the minimal valid example:
python -c 'from pathlib import Path
from gaig_mcp.core import check_inventory
out = check_inventory(inventory_csv=Path("docs/examples/minimal-inventory.csv").read_text(), evaluation_time="2026-10-16T00:00:00Z")
print(out["result"]["validation_state"], out["result"]["finding_count"])'Expected last line: VALID 0 (the toolkit also prints its progress lines). docs/examples/minimal-inventory.csv holds the required header row and one synthetic system; replace the row with your own systems. The same file is installed with the package, so a pip or uvx install without a clone can use from gaig_mcp.core import minimal_inventory_csv and pass minimal_inventory_csv() as inventory_csv. If a column is missing, check_inventory fails closed with MISSING_REQUIRED_COLUMN, lists the required columns, and points to this file.
Package-only install (no clone): pip install "git+https://github.com/GLOBAL-AI-GOVERNANCE/ai-governance-mcp@v0.5.1". The pinned upstream files are included. Running scripts/smoke_test.py against a package install also needs the dev extra: pip install "gaig-mcp[dev] @ git+https://github.com/GLOBAL-AI-GOVERNANCE/ai-governance-mcp.git".
Protocol: the official Python SDK mcp==2.3.0, which speaks MCP 2026-07-28 (the current spec revision). The smoke test also confirms that handshake-era clients (initialize with 2025-06-18 / 2025-11-25) work over HTTP. HTTP mode is stateless with JSON responses, which suits serverless hosts.
Environment variables (HTTP mode):
Var | Purpose |
| Comma-separated Host allow-list (DNS-rebinding protection). Required for any non-loopback bind: with |
| Comma-separated origins for browser-based clients (e.g., MCP Inspector). Off by default |
| Static bearer token, at least 32 characters (for example |
| Use other checkouts instead of the bundled pinned files |
| Bind address (defaults |
Only these GAIG_* names are read. A setting name from before v0.3.0 makes the server refuse to start, with a message naming its GAIG_* replacement. This keeps the loopback-plus-tunnel case fail-closed.
Client configuration (copy-paste)
Replace https://YOUR-HOST and TOKEN with your own values. Local stdio configs for Cursor, VS Code, Codex, Claude Code, the Grok CLI, and the Gemini CLI: examples/client-configs/. Remote platforms (ChatGPT, the Claude API and claude.ai, the OpenAI, Anthropic, and xAI APIs, grok.com) cannot reach stdio or localhost. They need an HTTPS URL that you host yourself (see "Self-hosting") and must send Authorization: Bearer TOKEN, where TOKEN is your GAIG_MCP_BEARER_TOKEN. None of the remote recipes below has been tested against a live provider.
Claude Desktop (local, stdio)
claude_desktop_config.json (Settings → Developer → Edit Config):
{
"mcpServers": {
"gaig": {
"command": "uvx",
"args": ["--from", "git+https://github.com/GLOBAL-AI-GOVERNANCE/ai-governance-mcp@v0.5.1", "gaig-mcp"]
}
}
}Launch command TESTED with the MCP Python SDK stdio client; this config is not tested inside Claude Desktop.
One-click desktop extension: manifest.json (MCPB manifest_version 0.4) passes mcpb validate. Packing a .mcpb still needs platform-specific dependency bundling (cryptography has native wheels). Not yet tested in Claude Desktop.
Claude Code (local, stdio)
claude mcp add gaig --scope project -- uvx --from git+https://github.com/GLOBAL-AI-GOVERNANCE/ai-governance-mcp@v0.5.1 gaig-mcpThis writes a project .mcp.json like examples/client-configs/claude-code.mcp.json. Tools appear as mcp__gaig__check_inventory and so on. Launch command TESTED with the MCP Python SDK stdio client; not tested inside Claude Code (untested).
Grok CLI (local, stdio)
grok mcp add gaig -- uvx --from git+https://github.com/GLOBAL-AI-GOVERNANCE/ai-governance-mcp@v0.5.1 gaig-mcpOr add examples/client-configs/grok-cli.config.toml to ~/.grok/config.toml. The Grok CLI also reads a project .mcp.json, so the Claude Code file works there too; check with grok mcp doctor. Tools appear as gaig__check_inventory and so on. Launch command TESTED with the MCP Python SDK stdio client; not tested inside the Grok CLI (untested).
Claude.ai / Claude Desktop / mobile (remote custom connector)
Add custom connector → URL https://YOUR-HOST/mcp, sign-in "None", then under Request headers add authorization with the value Bearer TOKEN. Anthropic documents request headers as a beta available to a limited set of organizations. If your organization does not see that section, Claude.ai cannot connect to this server: it does not implement OAuth and does not accept anonymous network requests. Which plans can add custom connectors: unverified; check the Claude Help Center.
Anthropic Messages API (MCP connector)
curl https://api.anthropic.com/v1/messages \
-H "content-type: application/json" -H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" -H "anthropic-beta: mcp-client-2026-09-15" \
-d '{
"model": "CLAUDE_MODEL_ID", "max_tokens": 1500,
"messages": [{"role": "user", "content": "Use gaig to check the sample AI inventory and summarize the critical findings."}],
"mcp_servers": [{"type": "url", "name": "gaig", "url": "https://YOUR-HOST/mcp", "authorization_token": "TOKEN"}],
"tools": [{"type": "mcp_toolset", "mcp_server_name": "gaig"}]
}'(mcp-client-2025-11-20 is the previous header. authorization_token is required, because the server rejects requests without the token.)
OpenAI Responses API (remote MCP tool)
curl https://api.openai.com/v1/responses \
-H "content-type: application/json" -H "authorization: Bearer $OPENAI_API_KEY" \
-d '{
"model": "OPENAI_MODEL_ID",
"input": "Use gaig to verify the signed-revoked example passport and explain the result.",
"tools": [{
"type": "mcp", "server_label": "gaig", "server_url": "https://YOUR-HOST/mcp",
"headers": {"Authorization": "Bearer TOKEN"},
"allowed_tools": ["check_inventory", "build_decision_pack", "validate_passport"],
"require_approval": "never"
}]
}'"require_approval": "never" is a documented OpenAI value that skips OpenAI's per-call approval prompt, which otherwise asks before data is sent to the server. It is used here only because all three tools are read-only and non-authorizing; it grants no authority, and every result still carries authority_effect: "NONE" and waits for a human decision. Set it to "always" to review each call.
(OpenAI also documents an authorization field for OAuth access tokens; the headers form above sends the static token verbatim. For a server that is never exposed publicly, OpenAI documents a Secure MCP Tunnel (tunnel_id). That path is untested here.)
ChatGPT (developer mode / custom app)
Not currently supported. OpenAI documents the authentication options for a custom MCP server in ChatGPT as OAuth, no authentication, or mixed; there is no field for a static bearer token. This server requires a token for any remote use and does not implement OAuth, so ChatGPT on the web cannot connect to it. Use the OpenAI Responses API above instead.
xAI Grok API (remote MCP tool)
curl https://api.x.ai/v1/responses \
-H "content-type: application/json" -H "authorization: Bearer $XAI_API_KEY" \
-d '{
"model": "GROK_MODEL_ID",
"input": "Use gaig to run check_inventory on the sample and list critical findings.",
"tools": [{
"type": "mcp", "server_label": "gaig", "server_url": "https://YOUR-HOST/mcp",
"server_description": "Non-authorizing AI governance checks (authority_effect NONE)",
"headers": {"Authorization": "Bearer TOKEN"},
"allowed_tools": ["check_inventory", "build_decision_pack", "validate_passport"]
}]
}'xAI supports only Streamable HTTP or SSE; require_approval is not supported. In the xAI Python SDK, use mcp(server_url=..., server_label="gaig", allowed_tool_names=[...], extra_headers={"Authorization": "Bearer TOKEN"}).
Grok (grok.com consumer connectors)
grok.com/connectors → New Connector → Custom → enter https://YOUR-HOST/mcp. The server must be reachable on the public internet. Whether this connector can send a static Authorization: Bearer header is unverified. If it cannot, grok.com cannot connect to this server; use the xAI API above instead.
Guard agent tool calls by Action Level
gaig-mcp tools are read-only, but the agents that call them usually have other tools too. examples/agent-stacks/action_level_guard.py (standard library only) checks every tool call before it runs, using the Action Levels in the action-authority spec:
Level | Meaning | Guard decision |
0-3 | Advisory, read-only, drafts, or bounded reversible internal actions | allow |
4 | Privileged or externally consequential | ask: an accountable person approves or rejects the call |
5 | Destructive, financial, legal, employment, human-safety, critical-infrastructure, or irreversible high-impact | deny |
not in your policy | New or renamed tool | treated as Level 4 |
You list your tools and their levels (ActionLevelGuard({"send_external_email": 4, "delete_records": 5})); the three gaig-mcp tools are Level 1. The guard never approves a Level 4 call itself; only an automated approver the operator configures can (see below). One policy covers send_external_email, mcp__crm__send_external_email (Claude), and crm__send_external_email (Grok CLI).
Stack | File | How Level 4 and Level 5 are enforced | Status |
OpenAI Agents SDK (Python) |
| TESTED offline: openai-agents 0.24.0 runner, real gaig-mcp stdio server, scripted stand-in model | |
Claude Agent SDK (Python) |
| TESTED offline: claude-agent-sdk 0.2.174 hook called directly; not run against Claude | |
Claude Code |
| Hook contract TESTED with recorded-format input; not run inside Claude Code (untested) | |
Grok CLI | same hook + | Grok hooks can only deny, so Level 4 and Level 5 are denied with the reason | Hook contract TESTED with recorded-format input; not run inside the Grok CLI (untested) |
OpenAI Responses API (hosted MCP) |
| Request shapes and approval answers TESTED offline; no live request (untested) | |
Anthropic Messages API (MCP connector) | same file | Only Level 0-3 tools are enabled in | Request shape TESTED offline; no live request (untested) |
xAI API (remote MCP) | same file | Only Level 0-3 tools in | Request shape TESTED offline; no live request (untested) |
Setup for Claude Code: copy tool_call_hook.py and action_level_guard.py into .claude/hooks/, and merge claude-code.settings.json into .claude/settings.json. For the Grok CLI: copy both files into .grok/hooks/, copy grok-cli.hooks.json there too, and trust the project hooks with /hooks-trust. Pass your own levels with --policy action-levels.json. The hook denies on any error, because the Grok CLI lets a call through when a hook fails; in Claude Code v2.1.295 or later you can also add "onFailure": "block" to the hook entry.
Hosted MCP connectors (OpenAI, Anthropic, xAI) call your server from the provider, so your code cannot check each call there; expose only the tools the guard allows, and run Level 4 actions from your own client loop. The guard limits what an agent can do unattended; it does not make any action authorized. Tests: tests/test_guards.py.
New in v0.5.1: toolkit v2.8.1 bundle
Rebundles the pinned Global AI Governance Toolkit to v2.8.1 (0ab38c6a94a705e4423bfc9bb19ef2137f59f5c5), including maturity XSS/import hardening, UTC evaluation time, and GAI-AUTO-005 on Full autonomy. MCP tool names and transports are unchanged. See UPSTREAM_LOCK.json for the exact tree digest. The server version is 0.5.1.
New in v0.5.0: unattended Level 4 and more agent stacks
Operator safety setting: automated Level 4 approver. A policy file can name an approver the operator runs, and list the Level 4 tools it approves (example). Those calls run unattended with approved_by recorded; every other Level 4 call still asks a person, unknown tools are never auto-approved, and Level 5 is always denied. The approver cannot list a tool that is not at Level 4 in the same policy. Without this setting, nothing changes. Tests: tests/test_automated_approver.py.
Stack | File | Status |
Gemini CLI |
|
|
LangGraph | TESTED offline with langgraph 1.2.17 | |
A2A | Card shape TESTED with a2a-sdk 1.2.3; no A2A server or client run | |
OpenTelemetry GenAI | TESTED with opentelemetry-sdk 1.45.1, in-memory exporter | |
MCP Registry metadata |
| Validated offline against the published schema; not submitted to any registry |
Agent instructions | Format checked by |
The CI interop job installs the pinned SDKs and fails if any of these tests is skipped.
Check the passport and the Action Level before each tool call
New in v0.4.0. gaig_mcp.core.check_tool_call runs one combined check before a tool call, at this server's own clock:
The agent's passport verifies
VALID: schema, Ed25519 signature, key trust, evidence-bundle binding, and validity window.A signed revocation list was supplied, and the revocation check passed. A missing or stale list means deny.
The tool's Action Level is at or below the passport's reachable level. That level is the passport's
issued_assessment.maximum_action_level, lowered by any condition'stemporary_restriction.maximum_action_level.
If all three pass, Levels 0-3 give allow, Level 4 gives ask (an accountable person decides), and Level 5 gives deny. Every other outcome is deny. A tool without a stated level counts as Level 4. The result is call_disposition with its reasons, inside the usual envelope (authority_effect: "NONE"). allow means no check stopped the call; it is not an approval.
Time basis. check_tool_call has no time input. It always evaluates at server_clock() and reports evaluated_at and time_basis: "server_clock", and it denies if the validator did not evaluate at that time. validate_passport keeps its at_time argument for historical validation ("did this passport verify at that time?"), and now reports time_basis: caller_at_time, example_fixed_time, or server_clock. A caller-supplied time is never used for a pre-call decision.
from gaig_mcp.core import check_tool_call
out = check_tool_call("send_external_email", passport=passport_json, trusted_key=key_json,
revocation_list=revocation_json, tool_level=4,
bundle_manifest="bundle/manifest.json", bundle_root="bundle")
out["result"]["call_disposition"] # "allow", "ask", or "deny"For Claude Code and the Grok CLI, passport_tool_call_hook.py wraps this check as a PreToolUse command hook, takes tool levels from action_level_guard.py, and denies on any error. It needs gaig-mcp installed and --passport, --trusted-key, and --revocation-list files; add --bundle-manifest and --bundle-root, or the passport cannot reach VALID. Status: TESTED (tests/test_passport_guard.py); not run inside Claude Code or the Grok CLI. The existing tool_call_hook.py and the other guards are unchanged.
check_tool_call is a Python function and a hook, not an MCP tool: the MCP tool list is unchanged. The evidence bundle is read from local paths, so it is not accepted over MCP.
Auth
Local stdio: no auth. The MCP spec says stdio servers take credentials from the environment.
Loopback HTTP (
127.0.0.1,localhost,::1, with no publicGAIG_MCP_ALLOWED_HOSTSentry): the token is optional, as before.Any network exposure (non-loopback bind, reverse proxy, or tunnel):
GAIG_MCP_BEARER_TOKENis required, and the server refuses to start without it. There is no anonymous mode. An authenticating gateway in front of the server does not replace the token, because the server cannot verify a gateway's claim.Bearer token: sent as
Authorization: Bearer TOKEN(authorization_tokenin the Anthropic API,headersin the OpenAI and xAI APIs). It is one static shared secret for every caller: no rotation (restart with a new value), no per-user identity, no scopes, and no expiry. It is compared in constant time, every rejection gets the same401body, and the presented value is never echoed. Serve it only over HTTPS.OAuth 2.1: not implemented. Clients that offer only OAuth or no authentication cannot connect. Adding OAuth would require Protected Resource Metadata (RFC 9728) plus an authorization server.
Self-hosting (needed for every remote platform; Global AI Governance operates no endpoint)
Every remote deployment needs, at minimum: HTTPS, GAIG_MCP_ALLOWED_HOSTS=<the hostname clients use>, and GAIG_MCP_BEARER_TOKEN=<random secret of 32+ characters>. The server refuses to start on a non-loopback bind, or with a non-loopback allow-list entry, unless both are set.
Option | Cost (per provider docs, Oct 2026) | Fit |
Cloudflare Quick Tunnel ( | Free, no account | Testing only. Random temporary URL. Set |
Render free web service ( | $0; 512 MB; spins down after 15 min idle (about 1 min cold start) | Cheapest always-addressable URL; cold starts may time out some clients (unverified) |
Google Cloud Run ( | Free tier of 2M requests/month; billing account required | Scales to zero, HTTPS, custom domain |
Privacy note: a hosted endpoint changes the toolkit's "LOCAL · NO UPLOAD" promise for that mode. Label it clearly, and keep stdio as the private default.
Files
src/gaig_mcp/core.py: transport-independent logic, the authority envelope, andcheck_tool_callsrc/gaig_mcp/server.py: MCP server (stdio and Streamable HTTP,/health, CORS, bearer token required for network use)src/gaig_mcp/_upstream/: pinned toolkit and agentic files bundled into the package, withUPSTREAM_LOCK.json(commit, file count, tree digest per upstream)tests/: 144 tests (combined pre-call passport and Action Level guard, core behavior, determinism, fail-closed input, non-authorizing invariants, in-process, stdio, and HTTP transports, bearer enforcement, and security regressions for host allow-listing, uniform 401s, sanitized errors, unknown-argument rejection, and the required bearer token for network exposure, plus interface guards, refusal of removed setting names, bundle-lock checks, and example and client-config checks)scripts/smoke_test.py,docs/verification-transcript.md: real-client verificationscripts/fetch_upstreams.sh: pinned upstream clones;scripts/bundle_upstreams.py: copies them into the package and checks the bundle (--check, run in CI)examples/client-configs/,examples/agent-stacks/: copy-paste client configs and agent-framework patterns, each labelled TESTED or untested.github/workflows/release-assets.yml: builds the wheel and sdist from a release tag, installs them in a clean environment, and attaches them withSHA256SUMSto the release. For releases published after v0.3.0, it also attaches a CycloneDX SBOM of the clean install (*.cdx.json) and records a GitHub build-provenance attestation for every asset inSHA256SUMS(check withgh attestation verify <file> --repo GLOBAL-AI-GOVERNANCE/ai-governance-mcp). Releases up to and including v0.3.0 have no SBOM or attestationmanifest.json: MCPB desktop-extension manifest (validated, not packed)deploy/Dockerfile: container for a remote host (build locally; no image is published)No managed endpoint is operated; no hosted-service privacy policy or terms are published.
Known limits
Input checks are strict: unsupported arguments are rejected (
additionalProperties: false). Error messages give a category, the field name, and allowed values, never the value you sent; a rejected CSV reports the toolkit's error code, column, and remediation without the cell or header text. One exception comes from the MCP SDK itself: a call to a tool name that does not exist is answered withUnknown tool: <name>.Tool calls are synchronous and use process-global stdout redirection, so they are fine for low traffic. Add a worker pool before heavy use.
validate_passportwith caller-supplied JSON: passpassport_json,trusted_key_json, and optionallyrevocation_list_jsonas JSON text strings, and they reach the reference validator. No evidence bundle is accepted over MCP yet, so evidence-bundle binding cannot run, and the validator stops before its validity-window and revocation checks (each reported asNOT_RUN). For a passport that passes the structure and signature checks, expectverification_primary_status: BOUND_INPUTS_UNAVAILABLE,artifact_validation_status: INCOMPLETE,fully_validated: false, andreference_policy_disposition: NOT_PERMITTED. Supplyingrevocation_list_jsonorat_timedoes not currently produce a revocation or validity verdict in this mode (usecheck_tool_callwith a local evidence bundle for a full check), and theREVOKEDresult shown byexample: "signed-revoked"(which runs with a bundled evidence set) does not carry over to caller-supplied passports. The output'smodefield states this.Passport checks use the Agentic AI Governance
v0.1.0-alpha.2validator, whose schemas stay open to change until an independent verifier confirms them. Pin an appropriate published Global AI Governance Toolkit tag for reproducible integrations.Bundled toolkit pin: this release bundles Global AI Governance Toolkit v2.8.1 (
0ab38c6a94a705e4423bfc9bb19ef2137f59f5c5). Earlier MCP releases could lag the toolkit tip; checksrc/gaig_mcp/_upstream/UPSTREAM_LOCK.jsonfor the exact commit and tree digest. Override withGAIG_TOOLKIT_PATHonly when you intentionally bypass the lock.
Security
This repository does not operate an external security-report intake. Do not place secrets, credentials, personal data, sensitive operational information, or vulnerability material in public GitHub surfaces.
License
Apache-2.0. See LICENSE. The bundled pinned upstream files keep their own licenses, included alongside them in src/gaig_mcp/_upstream/ (toolkit: MIT; agentic: Apache-2.0).
Part of Global AI Governance
AI Governance MCP is the agent interface: the Toolkit and Agentic AI Governance checks, callable by any MCP-capable agent.
ai-governance.solutions · Connect your agent · Specifications · All products
For agents: llms.txt · machine-interface.json · AI Governance MCP (gaig-mcp). Compatible with Model Context Protocol (MCP) based agents.
Framework-neutral and jurisdiction-neutral. Outputs are non-authorizing (authority_effect: NONE). Not affiliated with or endorsed by any AI lab or platform.
Available Tools
3 toolsbuild_decision_packPrepare a Decision Pack for human reviewARead-onlyIdempotent
Run the toolkit pipeline and return the Decision Pack manifest (files + SHA-256 digests), the integrity-check result, and the reference-only handoff. include_documents=true also returns the Markdown documents for the decision-maker. The pack prepares a decision; it is not the decision.
| Name | Required | Description | Default |
|---|---|---|---|
| use_sample | No | Run the toolkit's synthetic sample inventory instead of caller CSV. | |
| inventory_csv | No | AI system inventory as CSV text with a header row (toolkit template columns: system_id, system_name, owner, ... evidence_complete). Max 1 MB. Omit when use_sample is true. | |
| evaluation_time | No | Optional fixed UTC time (ISO 8601, e.g. 2026-10-16T00:00:00Z) for byte-reproducible output. | |
| include_documents | No | Also return the Markdown documents for the decision-maker (each capped at 20,000 chars). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds genuinely useful behavioral context: what the tool returns (manifest with SHA-256 digests, integrity-check result, reference-only handoff), that include_documents expands the payload, and that document output is capped. It does not contradict the annotations; idempotence is even reinforced by this framing, though not stated outright.
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?
Three sentences, front-loaded with the core action, and the distinguishing scope clause is placed at the end for emphasis. Tight and purposeful, though the document-inclusion detail slightly duplicates the schema.
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 return values need not be enumerated, yet the description helpfully summarizes the manifest + integrity-check + handoff shape. All 4 params are covered by the schema. The main gap is the absence of routing guidance against siblings, which a complete definition of this pipeline entry point should include.
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 100%, so the schema already documents all four parameters, including the 1 MB CSV cap and the ISO 8601 format expectation. The description adds only the include_documents behavior, which is already in the schema's property description, so it adds no meaning beyond structured fields. Baseline 3.
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 a distinctive resource ('Run the toolkit pipeline and return the Decision Pack manifest'), and the closing line 'The pack prepares a decision; it is not the decision' establishes a purpose scope that clearly separates it from validate_passport and check_inventory.
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 ('prepare a decision for human review') but never states when to use this tool versus check_inventory or validate_passport, nor any prerequisites such as first validating the inventory CSV.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_inventoryCheck AI inventory for governance gapsARead-onlyIdempotent
Run the Global AI Governance toolkit's policy-as-code checks on an AI system inventory CSV (toolkit template columns) and return findings by severity. Set use_sample=true to run the synthetic sample. Output is non-authorizing (authority_effect NONE).
| Name | Required | Description | Default |
|---|---|---|---|
| use_sample | No | Run the toolkit's synthetic sample inventory instead of caller CSV. | |
| inventory_csv | No | AI system inventory as CSV text with a header row (toolkit template columns: system_id, system_name, owner, ... evidence_complete). Max 1 MB. Omit when use_sample is true. | |
| evaluation_time | No | Optional fixed UTC time (ISO 8601, e.g. 2026-10-16T00:00:00Z) for byte-reproducible output. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context beyond that: output is non-authorizing with authority_effect NONE, results are bucketed by severity, and a sample path exists. It stops short of describing pagination or how findings are structured.
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 compact sentences, with the core action front-loaded before the sample-mode hint and the non-authorization caveat. Nothing is padding, though the parenthetical 'toolkit template columns' is somewhat redundant with the schema and the sentence is dense enough to be slightly hard to scan.
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 return values need no prose explanation, and the description still covers the two input modes, the expected CSV shape, and the non-authorizing nature of the result. What remains missing is only minor: no explicit routing guidance against sibling 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?
Schema description coverage is 100%, so the schema already documents all three parameters, including the CSV column list, the 1 MB limit, and the ISO 8601 evaluation_time format. The description restates use_sample and the CSV template columns without adding syntax or format detail beyond the schema, so the baseline 3 applies.
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 gives a specific verb+resource: run policy-as-code checks from the Global AI Governance toolkit against an AI system inventory CSV, returning findings by severity. That is concrete and unambiguous. It does not, however, contrast itself with the siblings build_decision_pack or validate_passport, so an agent gets no explicit differentiation.
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?
Usage is implied by the described scenario (governance gap checking on an inventory) and the description notes 'Set use_sample=true to run the synthetic sample', which tells the agent one operating mode. There is no explicit when-to-use/when-not guidance relative to validate_passport or build_decision_pack, and no stated prerequisites for the CSV.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_passportVerify an Agent Trust PassportARead-onlyIdempotent
Verify an Agent Trust Passport (agentic-ai-governance reference validator): schema, semantics, Ed25519 signature, key trust, validity window, and signed revocation. Use example='signed-unrevoked' or 'signed-revoked' for synthetic demos, or pass passport_json and trusted_key_json (and optionally revocation_list_json) as JSON strings. Verification is not authorization (authority_effect NONE).
| Name | Required | Description | Default |
|---|---|---|---|
| at_time | No | Evaluation time, UTC ISO 8601. Defaults to the example's fixed time or now. | |
| example | No | Synthetic demo passport (test-only keys). Omit to verify caller-supplied JSON. | |
| passport_json | No | Agent Trust Passport as a JSON string. | |
| trusted_key_json | No | Trusted Ed25519 verification key as a JSON string (required with passport_json). | |
| revocation_list_json | No | Signed revocation list as a JSON string (optional). |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds genuinely useful context beyond that: the demo keys are test-only synthetic keys, and critically that 'Verification is not authorization (authority_effect NONE)', which prevents an agent from misusing the result.
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?
Purpose and scope are front-loaded in the first clause, followed by mode guidance and the authorization caveat. It is a dense single block but every sentence carries information; a list-style breakdown would read more cleanly, hence not a 5.
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 return values need no explanation, and annotations cover the safety profile. The description covers purpose, modes, required parameter combinations, and the important non-authorization caveat. It does not describe failure/error behavior, which leaves a minor gap for a verification 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 100%, so the baseline is 3. The description adds value by explaining the parameter relationships in prose: which parameters pair together (passport_json with trusted_key_json), that revocation_list_json is optional, and that passing example bypasses caller-supplied JSON. That is more than the raw schema conveys.
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 (verify) and resource (Agent Trust Passport) and enumerates precisely what is checked: schema, semantics, Ed25519 signature, key trust, validity window, and signed revocation. This distinguishes it clearly from the unrelated siblings check_inventory and build_decision_pack.
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 two clear invocation modes and the condition that selects each: use example='signed-unrevoked'/'signed-revoked' for synthetic demos, or pass passport_json (with trusted_key_json, optionally revocation_list_json) for real input. It does not state when NOT to use it or compare against siblings, but the sibling set is unrelated, so a 4 is appropriate.
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
build_decision_pack - First observed
check_inventory - First observed
validate_passport
TDQS
Scored across 3 tools
Each tool targets a distinct artifact and action: checking an AI inventory CSV, building a Decision Pack, and verifying an Agent Trust Passport. There is no meaningful overlap in purpose or inputs, so an agent can select correctly without hesitation.
All three names follow a clean snake_case verb_noun pattern (check_inventory, build_decision_pack, validate_passport). The convention is applied uniformly with no style drift.
Three tools is on the lean side for a server with a broad 'Global AI Governance' name, but each tool represents a substantial, self-contained workflow. It is slightly under-scoped rather than padded, which is acceptable.
The surface covers the core verification/assessment workflows (inventory policy checks, decision packaging, passport validation) with clear non-authorizing semantics. It lacks any authoring or lifecycle operations (e.g., generating inventories or issuing passports), but those may fall outside the server's reference-toolkit scope.
Maintenance
Related MCP Connectors
Read-only checks for DIDs, credentials, MCP servers, A2A cards and agent delegation.
Read-only Remote MCP for externally grounded AI agent trust receipts.
Find governed AI capabilities and verify signed receipts. Read-only, no account.
Read-only MCP tools for AI agent discovery, structured resources, and NIULAI information.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceEnables AI clients to perform safe, read-only IT diagnostics and retrieve local runbooks, asset records, and knowledge articles through MCP, with allowlisted network checks and audit logging.MIT
- AlicenseNot gradedqualityBmaintenanceEnables assistants to inspect tamper-evident AI agent action journals through read-only verification, event querying, and policy-rule explanation.119 PyPI1Apache 2.0
- AlicenseBqualityCmaintenanceEnables MCP-compatible agents to perform read-only incident investigations by querying logs, building timelines, searching runbooks, validating evidence, and creating ticket drafts only with explicit approval.7MIT
- AlicenseNot gradedqualityAmaintenanceEnables MCP-compatible agent hosts to delegate governed, read-only security audits and reviews of code, applications, agents, prompts, MCP configurations, and cloud environments through evidence-first findings and stable schemas.2Apache 2.0