Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Agent Policy Gateway MCP Server Check if a purchase of $500 is allowed under my spend policy."
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.
Compliance and guardrails server for AI agents. Gives companies the tools to run AI agents safely and within regulatory boundaries.
As AI agents gain autonomy — making purchases, accessing data, sending emails — companies face real compliance risks:
GDPR (EU): Agents processing personal data must follow strict rules. Violations cost up to 4% of global revenue.
EU AI Act (2024): High-risk AI systems need human oversight, transparency, and documentation. Non-compliance means fines up to 35M EUR.
Internal Policies: Companies need spend limits, allowed actions, domain restrictions, and audit trails.
This server provides the "boring infrastructure" that makes autonomous agents enterprise-ready.
Related MCP server: ai-compliance-monitor
Tool | Description |
| Scan text for PII (emails, phones, SSNs, credit cards, IBANs). Returns found types and redacted version. |
| Check if an action is allowed by configurable policies (spend limits, domain allowlists, blocked actions). |
| Append-only audit log entry with timestamp. Stored in |
| Retrieve audit log entries for compliance review. |
| Check EU AI Act risk level and GDPR requirements for an action type. |
| Kill switch — logs critical event and returns immediate stop signal. |
# Via pip
pip install agent-policy-gateway-mcp
# Via uvx (no install needed)
uvx agent-policy-gateway-mcpAdd to your MCP client config:
{
"mcpServers": {
"policy-gateway": {
"command": "uvx",
"args": ["agent-policy-gateway-mcp"]
}
}
}Or with pip install:
{
"mcpServers": {
"policy-gateway": {
"command": "policy-gateway-server"
}
}
}check_pii("Send invoice to john.doe@company.com, CC 4532-1234-5678-9012")
→ has_pii: true, found: [email, credit_card], redacted version providedapply_guardrails("make_purchase", {"amount_usd": 500})
→ denied: exceeds $100 spend limit
apply_guardrails("send_email", {})
→ allowed
apply_guardrails("delete_user_data")
→ denied: blocked actioncheck_compliance("automated_decision", "EU")
→ risk_level: high
→ requirements: human oversight, transparency, documentation, fairness audits
→ gdpr_articles: Art. 22 GDPRemergency_stop("agent-007", "Agent attempting unauthorized data export")
→ kill_switch: true, logged to audit trailUnacceptable: Biometric identification (real-time) — blocked
High: Automated decisions, credit scoring, recruitment, customer profiling
Limited: Content moderation, data processing
Minimal: Chatbot interactions
Art. 6 — Lawfulness of processing
Art. 9 — Special categories of data
Art. 13/14 — Information obligations
Art. 21 — Right to object
Art. 22 — Automated decision-making
Art. 30 — Records of processing
Art. 35 — Data protection impact assessment
Logs are stored as JSONL files in ~/.agent-audit-log/:
{"entry_id": "agent-1_1710936000000", "timestamp": "2024-03-20T12:00:00+00:00", "agent_id": "agent-1", "action": "api_call", "details": "Called external pricing API"}Category | Servers |
🔗 Blockchain | |
🌍 Data | Weather · Germany · Agriculture · Space · Aviation · EU Companies |
🔒 Security | |
🤖 Agent Infra | Memory · Directory · Hub · Reputation |
🔬 Research |
MIT
Prüft ob eine Agent-Aktion gemäß konfigurierbarer Policies erlaubt ist.
Prüft: Spend-Limits, erlaubte Domains, geblockte Aktionen, Aktionen die menschliche Freigabe brauchen, API-Rate-Limits.
Args: action: Die geplante Aktion (z.B. "send_email", "make_purchase") context: Optionaler Kontext mit Details: - amount_usd: Betrag in USD (für Spend-Checks) - domain: Ziel-Domain (für Domain-Checks) - api_calls_this_minute: Aktuelle API-Calls (für Rate-Limits) - custom_policies: Dict mit Policy-Overrides
Returns: allowed: Boolean ob die Aktion erlaubt ist decision: "allow", "deny" oder "require_approval" reason: Begründung der Entscheidung policy_checked: Welche Policy gegriffen hat
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| context | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool checks policies and returns a decision, but it does not explicitly state whether the tool is read-only or if it has side effects. The term 'prüft' suggests checking, but safety implications are not clarified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for parameters and return values, and each sentence adds value. It is front-loaded with the main purpose. Minor redundancy in listing checks after the first sentence, but overall concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is fairly complete. It explains return values (allowed, decision, reason, policy_checked) and context fields. For a guardrail tool with 2 parameters, this is sufficient.
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 coverage, the description compensates well by detailing the 'action' parameter with examples and explaining the 'context' object fields (amount_usd, domain, api_calls_this_minute, custom_policies). This adds significant meaning beyond the 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 clearly states the tool checks if an agent action is allowed according to configurable policies, listing specific checks (spend limits, allowed domains, blocked actions, actions needing human approval, API rate limits). This distinguishes it from siblings like check_compliance, check_pii, emergency_stop, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for any action requiring policy verification but does not explicitly state when to use this tool versus alternatives or when not to use it. No contrast with sibling tools is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prüft ob ein Aktionstyp besondere Anforderungen unter EU AI Act oder DSGVO hat.
Kennt Risikokategorien: automated_decision, biometric_identification, credit_scoring, content_moderation, recruitment, data_processing, customer_profiling, chatbot_interaction.
Args: action_type: Art der Aktion (z.B. "automated_decision", "recruitment") jurisdiction: Rechtsraum — aktuell "EU" unterstützt
Returns: action_type: Abgefragter Aktionstyp jurisdiction: Geprüfter Rechtsraum risk_level: AI Act Risikostufe requirements: Liste der Anforderungen gdpr_articles: Relevante DSGVO-Artikel is_prohibited: Ob die Aktion verboten ist
| Name | Required | Description | Default |
|---|---|---|---|
| action_type | Yes | ||
| jurisdiction | No | EU |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. It discloses output fields, known risk categories, and that only EU jurisdiction is currently supported. No mention of side effects, but tool appears to be a read-only query.
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?
Well-structured with Args and Returns sections, front-loaded with purpose. A bit verbose with full risk category list, but each sentence adds value.
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?
No output schema, so description compensates by listing all return fields. Parameter semantics are covered, and jurisdiction limitation is mentioned. Sufficient for a query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description adds meaning: explains action_type as 'Art der Aktion' with examples, and notes jurisdiction defaults to 'EU' and is currently limited. Provides context beyond 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?
Description clearly states the tool checks if an action type has special requirements under EU AI Act or DSGVO, with specific verb 'prüft' and resource 'Aktionstyp'. It distinguishes from siblings like check_pii or apply_guardrails by focusing on compliance.
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 guidance on when to use this tool versus alternatives like check_pii or apply_guardrails. Does not mention when not to use it or provide context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scannt Text auf personenbezogene Daten (PII).
Erkennt: E-Mail-Adressen, Telefonnummern (US/EU), SSNs, Kreditkartennummern und IBANs.
Gibt gefundene PII-Typen und eine bereinigte Version zurück. Nutze dieses Tool BEVOR du Text an externe Services sendest.
Args: text: Der zu prüfende Text
Returns: found_pii: Liste der gefundenen PII-Typen mit Positionen redacted_text: Text mit entfernter PII (ersetzt durch [PII_TYP]) has_pii: Boolean ob PII gefunden wurde pii_count: Anzahl gefundener PII-Elemente
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool detects specific PII types and returns a redacted version, implying no side effects. However, it does not explicitly state that the tool is read-only or mention any authorization or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear structure: a brief explanation, a list of detected PII, and a structured Args/Returns section. It is front-loaded and every sentence adds value, though it could be slightly more streamlined.
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 single-parameter tool with no output schema or annotations, the description covers input purpose, output structure (found_pii, redacted_text, etc.), and usage context. It is complete enough for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'text' is described as 'Der zu prüfende Text' in the description, providing meaning beyond the schema which only has a title and type. The description adds context that the text is to be scanned for PII, which aids correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scans text for PII, lists specific data types (emails, phone numbers, SSNs, etc.), and explains its output. It distinguishes itself from siblings like apply_guardrails by focusing on PII detection before sending to external services.
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 explicitly tells when to use the tool: 'Nutze dieses Tool BEVOR du Text an externe Services sendest.' It does not specify when not to use or mention alternatives, but the directive is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Löst einen Notfall-Stopp für einen Agent aus.
Loggt das Emergency-Stop-Event ins Audit-Log und gibt ein Kill-Switch-Signal zurück. Der aufrufende Agent MUSS nach Erhalt dieses Signals alle laufenden Aktionen sofort beenden.
Args: agent_id: ID des zu stoppenden Agents reason: Grund für den Notfall-Stopp
Returns: kill_switch: True — Agent muss sofort stoppen agent_id: Gestoppter Agent reason: Grund des Stopps timestamp: Zeitstempel audit_entry: ID des Audit-Eintrags
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | ||
| reason | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey all behavioral traits. It explains that an audit log entry is created and a kill-switch signal is returned, and that the agent must stop immediately. This is transparent, though it could further clarify any irreversible consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a short paragraph followed by Args and Returns sections. It is not overly verbose and presents information clearly. Minor improvements could tighten the language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description provides return fields with descriptions, which is helpful. It covers the main purpose and effect. However, it lacks prerequisites or permissions information, which would enhance completeness for a critical 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?
The input schema has 0% description coverage, but the tool description includes an Args section that explains agent_id and reason. This adds substantial meaning beyond the schema, though it does not detail expected formats or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Löst einen Notfall-Stopp für einen Agent aus' (triggers an emergency stop for an agent). It specifies the verb (trigger) and resource (agent), and the function is distinct from siblings like apply_guardrails or check_compliance.
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 instructs that the calling agent MUST stop all actions upon receiving the kill-switch signal. This provides clear usage context. However, it does not explicitly mention when not to use it or list alternatives, which would be beneficial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ruft Audit-Log-Einträge für einen Agent ab.
Liest die JSONL-Audit-Datei und gibt die letzten Einträge zurück. Nützlich für Compliance-Reviews und Incident-Analyse.
Args: agent_id: Eindeutige ID des Agents limit: Maximale Anzahl Einträge (Standard: 50)
Returns: entries: Liste der Log-Einträge (neueste zuerst) total_entries: Gesamtanzahl Einträge agent_id: Abgefragter Agent
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states the tool reads the JSONL file and returns the newest entries first, implying non-destructive behavior. However, it lacks details on permissions, error handling, or file size limits, so transparency is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a header, behavior sentence, args, and returns. It is reasonably concise at 6 lines but includes redundant phrases like 'Liest die JSONL-Audit-Datei' which is implied by the purpose. Slightly more compact wording would improve this.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers purpose, parameters, and return values (including structure). It adds use-case context and ordering. Missing details like pagination or error conditions are minor, making it largely complete for a read-only log retrieval 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?
The description adds meaningful explanations for both parameters ('agent_id' as unique agent ID, 'limit' as max entries with default 50) beyond the schema's minimal info. Since schema coverage was 0%, the description compensates well, though it could also specify the data type more precisely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves audit log entries for a specific agent, reads the JSONL audit file, and returns the latest entries. It differentiates from sibling tools like 'log_action' or 'check_compliance' by focusing on reading historical logs for compliance and incident analysis.
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 explicitly mentions use cases ('Compliance-Reviews und Incident-Analyse'), providing context for when to use the tool. It does not specify when not to use it or mention alternatives, but the purpose is sufficiently clear to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Loggt eine Agent-Aktion in ein Append-Only Audit-Log.
Jeder Agent bekommt eine eigene JSONL-Datei unter ~/.agent-audit-log/. Einträge sind unveränderlich und enthalten Zeitstempel, Agent-ID, Aktionstyp und Details.
Args: agent_id: Eindeutige ID des Agents action: Art der Aktion (z.B. "api_call", "data_access") details: Zusätzliche Details zur Aktion
Returns: logged: Boolean ob erfolgreich entry_id: Eindeutige ID des Log-Eintrags file_path: Pfad zur Audit-Datei
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | ||
| action | Yes | ||
| details | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description mentions append-only nature and file location (~/.agent-audit-log/), but lacks details on authentication, rate limits, or what happens on duplicates. No annotations provided, so burden is on description.
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?
Description is concise at 5 lines of German plus Args/Returns section. Mixed language is acceptable but could be more consistent. Every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 0% schema coverage, description covers purpose, parameters, and return fields. Missing error conditions and example usage.
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%; description adds example values for action and explains details as additional details. However, it doesn't specify format constraints or allowed values beyond the examples.
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?
Description uses clear verb 'loggt' and specific resource 'Agent-Aktion in ein Append-Only Audit-Log'. It distinguishes itself from sibling tools like get_audit_log (read) and check_compliance (different purpose).
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 guidance on when to use this tool vs alternatives like check_compliance or emergency_stop. Usage is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a distinct and non-overlapping purpose: policy enforcement, legal compliance, PII scanning, emergency stop, action logging, and audit retrieval. No two tools could be confused for the same operation.
Most tools follow a verb_noun pattern (apply_guardrails, check_compliance, check_pii, get_audit_log, log_action), but 'emergency_stop' is a noun phrase without a leading verb, breaking the pattern slightly.
Six tools is well-scoped for a policy gateway server, covering guardrails, compliance, PII, emergency stop, and audit without feeling too few or excessive.
Core use cases are covered: policy enforcement, legal checks, PII scanning, emergency stop, and audit logging. Minor gaps exist (e.g., no explicit tool for human approval or policy configuration), but agents can still function with these tools.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Register every AI agent, log every action, prove it. EU AI Act compliance built in.
Pre-action allow/deny for AI agents. 24 statutes, 13 jurisdictions: EU AI Act, GDPR, DPDP.
Compliance MCP for AI agents: sanctions & KYT screening on 50+ chains, stablecoin-freeze, oracle.
Sovereign Agent OS — Persistent Memory, Governance & Compliance for AI Agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/AiAgentKarl/agent-policy-gateway-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
