guardian-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| GUARDIAN_MAX_BYTES | No | If the total size of files to delete exceeds this value (in bytes, ~1GB), confirmation is required. | 1000000000 |
| GUARDIAN_MAX_FILES | No | If the number of files to delete exceeds this value, confirmation is required. | 100 |
| GUARDIAN_PROTECTED_PATHS | No | Comma-separated list of absolute paths. These paths and their subpaths are always blocked from deletion/overwrite. |
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": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| safe_deleteA | Delete a file or directory, but only after checking it against system-critical paths, user-protected paths, and blast-radius limits. Deletes are recoverable: the target is moved to a quarantine folder (~/.guardian-mcp/trash) instead of being unlinked. If the target is large, call again with confirm:true after reviewing the size warning. |
| safe_writeA | Write content to a file, refusing system-critical or user-protected paths. If the file already exists, requires overwrite:true and automatically backs up the previous version to the quarantine folder first. |
| safe_executeA | Run a shell command after screening it for known-catastrophic patterns (rm -rf, DROP DATABASE, disk format, fork bombs, etc.), regardless of what path or table it targets. This is a pattern-based safety net, not a sandbox. |
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 3 tools
Each tool targets a distinct action (delete, write, execute) on a different resource type. The safe_ prefix unifies them without blurring boundaries; no two tools could be mistaken for one another.
All tools follow a consistent verb_noun pattern (safe_delete, safe_write, safe_execute) with the same prefix. Predictable and readable.
Only three tools covering delete, write, and execute. This is thin for a safety layer that would typically also cover safe_read, safe_list, or safe_move; the scope feels underdeveloped rather than tightly focused.
Covers three destructive operations but lacks read, list, or move/rename guards, which are common file operations. No API to inspect quarantine, restore files, or configure protected paths, creating dead ends for recovery workflows.