Agent Guardrail MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| AGENT_GUARDRAIL_DATA_DIR | No | Override the default data directory for the audit log (default: ~/.local/share/agent-guardrail-mcp/ on Linux/macOS, %APPDATA%\agent-guardrail-mcp\ on Windows). Useful for Docker/CI or isolating test data. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| scan_inputA | Scan incoming text for prompt injection attempts. Use this before an agent acts on user input, retrieved documents, tool outputs, or any other text that could contain hidden instructions. Args: text: The text to scan for injection patterns. source: Where this text came from (e.g. "user_input", "document_content", "tool_output"). Recorded in the audit trail for traceability. Returns: A dict with: score (0-100), risk_level (low/medium/high), reasons (list of matched pattern explanations), and recommendation (Proceed / Flag for review / Block). |
| scan_outputA | Scan outgoing text for PII and secrets/credentials before an agent sends it. Use this on agent-generated responses before returning them to a user, posting them externally, or logging them anywhere outside this system. Args: text: The text to scan for PII (emails, phone numbers, SSNs, credit cards) and secrets (AWS keys, GitHub tokens, API keys, private keys). Returns: A dict with: risk_level (low/medium/high), findings (list of what was detected and where), redacted_text (safe version with sensitive data replaced by labeled tokens), and recommendation. |
| get_audit_trailA | Retrieve recent entries from the guardrail audit log. Use this to review what scans have been performed, check compliance history, or investigate flagged activity. Args: limit: Maximum number of entries to return (most recent first). risk_level: Optional filter — only return entries matching this risk level ("low", "medium", or "high"). Returns: A list of audit entries, each with id, timestamp, scan_type, source, risk_level, risk_score, reasons, recommendation, and a text preview (never the full scanned text). |
| get_guardrail_statsA | Get aggregate statistics across all scans performed by the guardrail system. Use this for a dashboard-style overview: how many scans total, broken down by risk level, scan type, and recommendation. Returns: A dict with total_scans, by_risk_level, by_scan_type, and by_recommendation breakdowns. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
Each tool has a distinct purpose: scanning input for injection, scanning output for PII/secrets, retrieving detailed audit entries, and getting aggregate statistics. No overlap or potential confusion.
All tools follow a consistent verb_noun pattern using snake_case: get_audit_trail, get_guardrail_stats, scan_input, scan_output. The naming is predictable and intuitive.
With only 4 tools, the set is well-scoped for a guardrail system that scans inputs and outputs, provides an audit log, and offers aggregate statistics. Each tool serves a clear, non-redundant function.
The tool surface covers the core lifecycle: scanning input (injection detection), scanning output (PII/secrets), reviewing history via audit trail, and obtaining overview stats. No obvious gaps for the stated purpose.