bash-vet-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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 |
|---|---|
| vet_commandA | Vet a single shell command for destructive patterns BEFORE execution. Detects rm -rf nested in chains, package-manager glob removal (apt remove 'nvidia'), dd/mkfs/wipefs filesystem destruction, chmod 777 on system paths, curl|bash network-exfil, chained shutdown/reboot, git destructive ops (push --force, reset --hard), and DROP DATABASE / TRUNCATE via cli. Returns verdict (CLEAN / CAUTION / REVIEW / BLOCK / UNVERIFIED), risk_score (0-100), and per-finding rule_id + severity + recommendation. Sub-second, local, no API key. Use inline before approving any agent-proposed command. |
| vet_command_chainA | Vet a chained / multi-statement shell command — same rules as |
| list_detection_rulesA | Return the catalog of every detection rule the scanner applies — rule_id, severity, pattern_kind, description, example_match. Use this to audit coverage, document detection scope to your compliance/security team, or build a custom allowlist. 30 rules across 8 families: DESTRUCTIVE / PACKAGE / PRIVILEGED / SHUTDOWN / EXFIL / DATABASE / GIT / SUSPICIOUS. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| vet-this-command | Vet the most recent shell command in the conversation, explain each finding's risk, and recommend a specific action — refuse, sandbox-test, edit, or proceed with caveats. |
| audit-script | Audit a multi-line shell script line by line — calls vet_command on every non-trivial line and produces a per-line risk report. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| Demo: clean command | Sample input demonstrating a CLEAN verdict (no destructive patterns) |
| Demo: dangerous command | Sample input with package-glob removal + chained reboot + curl|bash — demonstrates a BLOCK verdict |
| Demo: sneaky chained command | Sample input mimicking the r/LocalLLaMA failure mode — benign-looking lede + rm -rf with env-var nested deep in the chain. Demonstrates chain-mode escalation. |
TDQS
Scored across 3 tools
Each tool has a distinct purpose: listing rules, vetting a single command, and vetting a chained command. Even vet_command and vet_command_chain are clearly differentiated by their handling of single vs. multi-statement commands.
All tool names follow a consistent verb_noun snake_case pattern (list_detection_rules, vet_command, vet_command_chain), making them predictable and easy to understand.
With 3 tools, the server is well-scoped for its purpose of vetting bash commands. Each tool serves a clear and necessary function without redundancy.
The tool set covers the core operations: inspecting available rules, vetting a single command, and vetting a chained command. There are no obvious gaps for the stated use case of inline command safety checks.