sigma-gate
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GUARD_BLOCK_AT | No | Threshold for blocking, default is medium | medium |
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| guardA | ONE deterministic pre-ship trust gate for AI/agent output. Runs leaked-secret detection (20+ providers), prompt-injection / jailbreak detection, and PII / compliance detection together -> returns safe_to_ship (bool) + block_reasons. No model, no API key, no token cost; same input gives the same verdict every time. Use before sending model output to a user, committing generated code, or forwarding untrusted text into another prompt. |
| guard_selftestA | Prove the gate works: runs a known secret, injection, PII, combined, and clean input and returns which classes fired. No arguments. |
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 2 tools
The two tools serve clearly different functions: guard performs the actual security detection, while guard_selftest verifies the gate's functionality. There is no ambiguity between running a check and testing the checker.
Both tools share the 'guard' prefix, making the relationship obvious. The names are short, readable, and follow a consistent pattern (guard and guard_selftest).
With only two tools, the server feels minimal but appropriately scoped for a single deterministic gate plus a self-test. The count is borderline on the low end but matches the focused utility.
The domain is fully covered: guard runs all detection types in one call and returns block reasons, while guard_selftest validates all detection classes. There are no missing operations for the stated purpose.