dcg MCP服务器使用指南：把扫描能力暴露给你的LLM代理-编程实验室

dcg MCP服务器使用指南：把扫描能力暴露给你的LLM代理

【免费下载链接】destructive_command_guardThe Destructive Command Guard (dcg) is for blocking dangerous git and shell commands from being executed by agents.项目地址: https://gitcode.com/GitHub_Trending/de/destructive_command_guard

dcg MCP服务器是 Destructive Command Guard（dcg）内置的 Model Context Protocol 服务，一条命令即可把它变成 AI 代理可调用的安全工具：在执行前拦截危险命令、扫描文件中的破坏性操作、并解释每一条命中规则。相比传统的 shell hook 方式，MCP 模式让 LLM 代理直接获得结构化的 JSON 判定结果，无需解析终端输出，是连接任意支持 MCP 的客户端（Claude Code、Cursor、Codex CLI 等）与 dcg 50+ 安全规则包的最短路径。

为什么用 MCP 模式，而不是 Hook？

dcg 最常见的用法是作为 Agent 的 PreToolUse hook：命令被拦截后才报错。而dcg mcp-server把同一套评估引擎（src/evaluator.rs）封装成了 MCP 工具，区别在于：

维度	Hook 模式	MCP 服务器模式
交互方式	代理执行命令 → dcg 被动拦截	代理主动调用工具查询
输出	终端面板 + JSON	纯结构化 JSON 工具响应
适用场景	兜底防线	执行前预检、批量审计、问答解释

两种模式可以叠加：MCP 让代理"提前知道危险"，Hook 负责"最后一道闸"。MCP 服务器实现位于 src/mcp.rs，基于rust-mcp-sdk通过 stdio 通信，无网络端口暴露，安全模型见 docs/security-model.md。

快速启动：一条命令开启 MCP 服务器

确保已安装 dcg（可参考 install.sh），然后启动服务器：

dcg mcp-server

该子命令在 src/cli.rs 中定义，启动后 dcg 加载 src/config.rs 中的配置（默认~/.config/dcg/config.toml）并等待 MCP 握手。在支持 MCP 的客户端里，只需在配置中加入：

{ "mcpServers": { "dcg": { "command": "dcg", "args": ["mcp-server"] } } }

Windows 原生环境的 stdio 握手兼容性由专项测试脚本 scripts/win_mcp_stdio.ps1 在每次构建中验证，可以放心用于 PowerShell 启动场景。

三大核心工具：check_command、scan_file、explain_pattern

连接成功后，代理会看到 dcg 暴露的 3 个工具（工具清单见 src/mcp.rs）：

1. check_command —— 执行前预检命令

传入待执行的命令字符串，返回该命令在 dcg 策略下的完整判定。响应包含allowed、decision（allow/deny/ask/warn/log/indeterminate）、rule_id、severity、explanation等字段，结构定义见 src/mcp.rs。

例如对git reset --hard HEAD~5的判定会命中 core git 规则包，返回allowed: false并附带"建议先 git stash"的说明——代理可据此自动改道或向用户发起确认。

🛡️ 值得注意的安全细节：当引擎无法确定风险（indeterminate）时，MCP 模式永远不会报告为允许（见 src/mcp.rs），即"不确定就拦住"，这是 fail-closed 设计。

2. scan_file —— 扫描文件与目录

传入路径即可对整个文件或目录做破坏性命令审计，复用与 CI 扫描模式（dcg scan）相同的引擎 src/scan.rs。默认参数经过调优：单文件最大 1MB、最多 100 条发现（src/mcp.rs），保证响应速度。扫描在独立 worker 线程执行，不会拖慢同时进行的轻量check_command调用（有专门的回归测试保证，见 src/mcp.rs）。

典型用法：让代理在修改脚本前调用scan_file，一次性拿到所有潜在危险点及其所在行，而不是逐条执行试错。

3. explain_pattern —— 解释规则，消除"黑盒感"

每条拦截都对应一个rule_id（格式为pack:pattern）。把这个 id 传给explain_pattern，即可返回规则的严重级别、拦截原因与完整解释（实现见 src/mcp.rs）。

这让 LLM 可以用自己的语言向用户解释"为什么被拦"，例如"kubernetes.kubectl包中的该规则会阻止删除命名空间"，而不是甩出一段错误码。

如何配置更严格的策略

MCP 服务器与 CLI 共用同一套配置，你不需要为代理单独维护一份规则：

启用更多规则包：在config.toml的[packs] enabled中加入database.postgresql、cloud.aws、containers.docker等，完整列表见 docs/packs/README.md；
按代理定制：[agents.***]段可以为不同代理设置extra_packs与additional_allowlist，例如给高信任代理放宽白名单（说明见 README 的 Agent-Specific Profiles 小节）；
查看可用包：运行dcg packs获取当前构建中所有包与类别 ID。

MCP 判定还会尊重策略模式：warn/log模式下命中的规则会计为允许但携带 mode 字段，代理可据此自行决定是否提示用户（契约定义在 src/mcp.rs）。

典型工作流示例

一个"先问再跑"的代理循环大致是：

代理拟定命令 → 调用check_command预检；
若allowed: true→ 正常执行；
若allowed: false→ 调用explain_pattern获取原因，转述给用户或自动换用安全替代命令；
修改仓库文件后 → 调用scan_file做整体审计，确认没有引入新的破坏性命令。

这样即使某次 hook 未被配置，代理侧也具备了完整的安全自查能力。

小结

dcg 的 MCP 服务器模式把"危险命令拦截 + 文件扫描 + 规则解释"三合一地交给你的 LLM 代理：一个check_command完成执行前预检，一个scan_file完成批量审计，一个explain_pattern让每一次拦截都变得可解释。配合 50+ 开箱即用的安全规则包和 fail-closed 的不确定处理策略，它能让任何支持 MCP 的 AI 编码代理在动手之前，先学会对危险命令说"不"。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考