发生了什么
Semgrep 的 MCP 能把安全发现和规则上下文带进开发者正在使用的编辑器或 Agent 客户端里。重点不是「Agent 现在能做安全」这种大话，它太含糊。真正有用的是 Agent 不再从一句冷启动提示开始，而是从具体发现、具体规则和项目上下文开始。
所以 Semgrep MCP 更像一块清楚的栈内组件，而不是又一个泛泛的「AI 安全助手」：先跑静态分析，暴露发现项，再让编程 Agent 解释或修补某个具体问题，最后验证发现是否真的被处理。
为什么重要
AI 编码工具里的安全工作经常坏在任务太空。「帮我检查安全问题」很容易生成一段宽泛建议，听起来很认真，实际上很难审。接上 Semgrep 之后，任务会窄一些：规则是什么，文件在哪里，相关代码是哪一段，修复候选长什么样。审阅者也更容易判断这个补丁能不能进。
这不等于安全评审可以取消。它只是让第一轮排查少一点糊状建议。对导航站来说，这个区别要写清楚，因为用户选的不只是模型，还包括喂给模型的证据链。
对站内读者
Semgrep MCP 应该放在 MCP 的 dev 分类里，并和 requesting-code-review、source-verification 互链。它也适合和 GitHub MCP 放在一起看：仓库上下文进来，发现项进来，Agent 生成一个小修复，再留下可审阅的理由。
站内介绍别把它吹成自动安全工程师。更准确的说法是：把静态分析上下文带入 Agent 循环，减少空泛提示，把最后判断留给审阅者。
接下来观察什么
重点看权限边界、仓库作用域、CI 集成，以及客户端能不能把原始 Semgrep 发现和 Agent 提议的修复放在一起展示。链路看得见，团队才好审；如果所有东西都消失在聊天记录里，信任成本反而会变高。