# MCP Server Integration in dcg: How to Run Destructive Command Guard as an MCP Server

> Integrate Destructive Command Guard as an MCP server using STDIO RPC. Query command safety engine with check_command, scan_file, and explain_pattern tools for AI agents. Reduce CLI overhead.

- Repository: [Jeff Emanuel/destructive_command_guard](https://github.com/Dicklesworthstone/destructive_command_guard)
- Tags: how-to-guide
- Published: 2026-07-16

---

**Destructive Command Guard (dcg) can run as an MCP (Model Context Protocol) server via STDIO-based RPC, exposing three tools—`check_command`, `scan_file`, and `explain_pattern`—that let AI agents and external tools query its command safety engine without CLI overhead.**

The Dicklesworthstone/destructive_command_guard repository provides a robust MCP server integration that transforms dcg from a standalone CLI tool into a queryable service. By implementing the Model Context Protocol, dcg exposes its destructive command detection engine through a standardized interface, enabling seamless integration with AI agents, editors, and automated pipelines. This mode eliminates the need to spawn full CLI processes or parse terminal output, offering direct programmatic access to command evaluation and file scanning capabilities.

## What is the dcg MCP Server?

The MCP server implementation in [`src/mcp.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/mcp.rs) wraps dcg’s core evaluation logic in an asynchronous RPC interface. When started via `run_mcp_server()`, the server initializes a Tokio runtime and creates a `DcgMcpServer` instance that advertises its capabilities through the MCP **initialize** payload. Unlike the standard CLI hook protocol designed for Claude Code, this integration targets direct programmatic access, allowing clients to send JSON-RPC requests over standard input/output streams.

The architecture uses `StdioTransport` for communication and offloads expensive operations to a dedicated blocking worker thread. This design ensures that lightweight operations remain responsive even during intensive file system analysis, as validated by the test `blocking_scan_worker_does_not_starve_lightweight_checks`.

## Available MCP Tools and Capabilities

The server registers three primary tools that map directly to dcg’s core functionality:

### check_command

The `check_command` tool evaluates a single shell command against dcg’s policy engine. It accepts a JSON payload with a `"command"` string and returns a `CheckCommandResponse` containing:

- `allowed`: Boolean indicating policy compliance
- `decision`: Either `"allow"` or `"deny"`
- `reason`, `rule_id`, `pack_id`, `severity`: Metadata for denied commands
- `allowlist`: Optional details when an allow-list override applies

Behind the scenes, this tool invokes `evaluate_command` from [`src/evaluator.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/evaluator.rs), running the same analysis pipeline used by the CLI.

### scan_file

The `scan_file` tool performs recursive scanning of files or directories for destructive commands. It accepts a `"path"` parameter and executes the scanning logic from [`src/scan.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/scan.rs) (`scan_paths`) on a blocking thread via `run_blocking_scan`. The tool returns a complete `ScanReport` JSON object, making it suitable for CI pipelines or pre-commit hooks that need to validate entire codebases.

### explain_pattern

The `explain_pattern` tool provides human-readable documentation for specific rule IDs. By querying the global `REGISTRY` defined in [`src/packs/mod.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/packs/mod.rs), it extracts the stored reason, severity, and optional explanation for patterns like `core.git:reset-hard`, returning an `ExplainPatternResponse` that helps users understand why certain commands trigger safety violations.

## Starting the MCP Server

To launch the server programmatically, call the `run_mcp_server` entry point. This function builds a multi-threaded Tokio runtime and blocks until the server terminates:

```rust
use dcg::mcp;

fn main() -> Result<(), Box<dyn std::error::Error>> {
    // Blocks the current process and listens on stdin/stdout
    mcp::run_mcp_server()
}

```

The underlying `run_mcp_server_async` function constructs the transport layer using `server_runtime::create_server` and manages the async event loop. Configuration and allow-list data are loaded from [`src/config.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/config.rs), ensuring the server respects the same policies as the CLI version.

## Client Integration Examples

You can interact with the dcg MCP server using any MCP-compatible client. The following example uses the `rust-mcp-sdk` to query the server:

```rust
use rust_mcp_sdk::client::McpClient;
use serde_json::json;

#[tokio::main]
async fn main() -> anyhow::Result<()> {
    // Connect via stdio – server must already be running
    let client = McpClient::connect_stdio().await?;

    // Check a single command
    let check = client
        .call_tool("check_command", json!({ "command": "git reset --hard" }))
        .await?;
    println!("Safety check: {}", check);

    // Scan a directory
    let scan = client
        .call_tool("scan_file", json!({ "path": "./src" }))
        .await?;
    println!("Scan results: {}", scan);

    // Explain a rule
    let explain = client
        .call_tool("explain_pattern", json!({ "rule_id": "core.git:reset-hard" }))
        .await?;
    println!("Rule explanation: {}", explain);

    Ok(())
}

```

For AI agent integration, query the `check_command` tool before executing user-provided shell commands:

```rust
// Pseudo-code for AI agent integration
let command = get_user_command();
let result = mcp_client
    .call_tool("check_command", json!({ "command": command }))
    .await?;

if result["allowed"].as_bool().unwrap_or(false) {
    execute_shell(command);
} else {
    display_warning(result["reason"], result["explanation"]);
}

```

## Summary

- **MCP server mode** transforms dcg into a queryable service via STDIO-based RPC, implemented in [`src/mcp.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/mcp.rs).
- **Three core tools** expose dcg’s functionality: `check_command` for single-command evaluation, `scan_file` for recursive directory scanning, and `explain_pattern` for rule documentation.
- **Async architecture** uses Tokio for request handling with blocking worker threads for expensive scans, ensuring responsive lightweight checks.
- **Direct integration** allows AI agents and automation tools to check command safety without spawning CLI processes or parsing text output.

## Frequently Asked Questions

### How do I start the dcg MCP server from my application?

Import the `dcg::mcp` module and call `run_mcp_server()`. This function creates a multi-threaded Tokio runtime and blocks on `run_mcp_server_async()`, which initializes the `StdioTransport` and begins listening for MCP requests on standard input/output.

### What is the difference between check_command and scan_file?

`check_command` evaluates a single shell command string against dcg’s policy using `evaluate_command`, returning an immediate allow/deny decision. `scan_file` recursively analyzes a filesystem path using `scan_paths`, running on a blocking thread to prevent starvation of lightweight requests, and returns a comprehensive `ScanReport`.

### Can I use the MCP server with AI agents like Claude or custom LLM tools?

Yes. The MCP protocol enables any compatible client—including AI agents—to call dcg’s tools directly. Agents can invoke `check_command` before executing user code, or use `explain_pattern` to provide human-readable safety explanations when blocking dangerous operations.

### Where does the MCP server load its destructive pattern rules?

The server consults the global `REGISTRY` defined in [`src/packs/mod.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/packs/mod.rs), which contains all loaded rule packs. Configuration and allow-list overrides are handled by the logic in [`src/config.rs`](https://github.com/Dicklesworthstone/destructive_command_guard/blob/main/src/config.rs), ensuring the MCP server respects the same policies as the command-line interface.