BlastRadius MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| BLAST_RADIUS_AUDIT_KEY | No | HMAC secret for audit entries. Set this explicitly or audit entries will not verify across restarts. | |
| BLAST_RADIUS_AUDIT_PATH | No | Where the ledger is written. Defaults to ./blastradius-audit.jsonl. | |
| BLAST_RADIUS_SIGNING_KEY | No | HMAC secret for approval tokens. Set this explicitly or tokens will not verify across restarts. |
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 |
|---|---|
| simulate_actionA | Simulates and predicts the blast radius, danger score (0-100), and destructive reversibility of a shell command, SQL query, or cloud operation before execution. |
| inspect_payload_dlpC | Deep Data Loss Prevention (DLP) scanner. Detects, reports, and redacts API keys, passwords, JWTs, cloud credentials, credit cards, SSNs, and PII from prompts, code, and logs. |
| enforce_policyB | The central zero-trust decision point. Evaluates a prospective tool call against organizational security policies, scans parameters for DLP, and records a cryptographic audit trail. |
| request_confirmation_tokenA | Generates a time-bound, cryptographically signed (HMAC-SHA256) step-up approval token allowing an agent to execute high-impact actions when human consent is granted. |
| verify_audit_logB | Cryptographically verifies the immutable hash-chained audit ledger to detect tampering, deleted records, or unauthorized log modifications. |
| get_security_postureB | Returns current operational security metrics, the active policy profile, build edition and capabilities, blocked threat statistics, and DLP redaction totals. |
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 6 tools
Each tool has a distinct primary purpose spanning prediction, DLP scanning, posture reporting, policy enforcement, token issuance, and audit verification. There is mild overlap where enforce_policy also scans parameters for DLP and evaluates actions like simulate_action, but the descriptions clarify their respective roles well.
All six tools follow a strict verb_noun pattern (simulate_action, inspect_payload_dlp, get_security_posture, enforce_policy, request_confirmation_token, verify_audit_log). The convention is applied uniformly with no deviations.
Six tools is well-scoped for a security guardrail server, with each tool mapping to a discrete responsibility in the pre-execution safety workflow. No tool feels redundant or missing at the count level.
The surface covers a full guardrail lifecycle: simulation, DLP inspection, policy enforcement, step-up approval, posture reporting, and audit verification. Minor gaps exist such as no tool to view/configure policy definitions or revoke issued tokens, but core workflows are covered.