本项目最初受到 Semgrep 工具、Replit 团队 及其 Agent V2 以及 stefanskiasan/semgrep-mcp-server 实现的启发，但在架构上进行了重大改进，以实现更简单、更易于维护的安装和使用。
MCP Server Semgrep 是一个符合 模型上下文协议 (Model Context Protocol) 的服务器，它将强大的 Semgrep 静态分析工具与 Anthropic Claude 等 AI 助手集成。它能够直接通过对话界面进行高级代码分析、安全漏洞检测和代码质量改进。
Related MCP server: AWS Security MCP
全面的源代码分析 - 检测整个项目中的问题，而不仅仅是单个文件
主动错误检测 - 在潜在问题演变为严重 Bug 之前将其识别出来
持续的代码质量改进 - 定期扫描和重构，逐步优化代码库
风格一致性 - 识别并修复代码中的不一致之处，例如：
CSS 中随意的 z-index 层级
不一致的命名规范
代码重复
使用“魔术数字”而非命名常量
针对已知漏洞的自动化代码验证 - 扫描已知的安全问题模式
自定义安全规则 - 创建特定于项目的规则
团队教育 - 通过检测潜在问题来教授安全编程实践
“实时”文档 - AI 可以解释代码片段为何存在问题以及如何修复它
技术债务削减 - 系统地检测并修复问题区域
改进的代码审查 - 自动检测常见问题，使审查者能够专注于更复杂的事项
直接集成官方 MCP SDK
简化架构，统一处理程序
简洁的 ES Modules 实现
高效的错误处理和路径验证以确保安全
提供英语和波兰语的界面与文档
全面的单元测试
详尽的文档
跨平台兼容性（Windows、macOS、Linux）
灵活的 Semgrep 安装检测与管理
Semgrep MCP Server 提供以下工具：
scan_directory: 扫描源代码以查找潜在问题
list_rules: 显示 Semgrep 支持的可用规则和语言
analyze_results: 对扫描结果进行详细分析
create_rule: 创建自定义 Semgrep 规则
filter_results: 按各种标准过滤结果
export_results: 以多种格式导出结果
compare_results: 比较两组结果（例如，更改前后）
部署前的代码安全分析
检测常见编程错误
在团队内强制执行编码标准
重构和提高现有代码质量
识别样式和代码结构中的不一致（例如 CSS、组件组织）
开发者最佳实践教育
验证修复的正确性（比较扫描前后）
Node.js v18+
TypeScript (用于开发)
安装和使用 MCP Server Semgrep 最简单的方法是通过 Smithery.ai：
按照安装说明将其添加到您的 MCP 兼容客户端
配置任何可选设置，如 Semgrep API 令牌和允许的工作区根目录
这是 Claude Desktop 和其他 MCP 客户端的推荐方法，因为它会自动处理所有依赖项和配置。
# Using npm
npm install -g mcp-server-semgrep
# Using pnpm
pnpm add -g mcp-server-semgrep
# Using yarn
yarn global add mcp-server-semgrep该包也可在其他注册表上获取：
# Using npm
npm install -g git+https://github.com/VetCoders/mcp-server-semgrep.git
# Using pnpm
pnpm add -g git+https://github.com/VetCoders/mcp-server-semgrep.git
# Using yarn
yarn global add git+https://github.com/VetCoders/mcp-server-semgrep.git克隆仓库：
git clone https://github.com/VetCoders/mcp-server-semgrep.git
cd mcp-server-semgrep安装依赖（支持所有主流包管理器）：
# Using pnpm (recommended)
pnpm install
# Using npm
npm install
# Using yarn
yarn install构建项目：
# Using pnpm
pnpm run build
# Using npm
npm run build
# Using yarn
yarn build注意：安装过程会自动检查 Semgrep 是否可用。如果未找到 Semgrep，您将收到有关如何安装它的说明。
此服务器仅读取和写入明确允许的工作区根目录内的文件。
默认情况下，允许的根目录是进程工作目录 (process.cwd())。
对于 Claude Desktop、Smithery 或任何不在项目根目录下启动服务器的启动器，请将 MCP_SERVER_SEMGREP_ALLOWED_ROOTS 设置为一个或多个绝对路径目录。
多个根目录请使用您平台的路径分隔符：macOS/Linux 使用 :，Windows 使用 ;。
此服务器不实现自己的 Semgrep 账户处理。它调用已安装的 semgrep CLI，并依赖 Semgrep 的常规身份验证行为。
本地终端和本地开发运行通常可以使用当前操作系统账户中现有的 semgrep login 会话。
对于 Claude Desktop、Smithery、容器或 CI 等托管启动方式，应优先使用显式的 SEMGREP_APP_TOKEN 以确保行为确定性。
当您需要在不同机器或运行器之间进行可移植配置时，SEMGREP_APP_TOKEN 仍然是最安全的选择。
Semgrep 可以通过多种方式安装：
通过包管理器：
# Using pnpm
pnpm add -g semgrep
# Using npm
npm install -g semgrep
# Using yarn
yarn global add semgrepPython pip：
pip install semgrepHomebrew (macOS)：
brew install semgrepLinux：
sudo apt-get install semgrep
# or
curl -sSL https://install.semgrep.dev | shWindows：
pip install semgrep有两种方法可以将 MCP Server Semgrep 与 Claude Desktop 集成：
点击 "Install in Claude Desktop"
按照屏幕上的说明操作
安装 Claude Desktop
更新 Claude Desktop 配置文件 (claude_desktop_config.json) 并将其添加到您的 servers 部分。
对于在已通过 semgrep login 身份验证的用户账户下启动的本地运行，Semgrep CLI 可能能够重用该登录信息。对于桌面托管或共享环境，我们仍然建议显式设置 SEMGREP_APP_TOKEN：
{
"mcpServers": {
"semgrep": {
"command": "node",
"args": [
"/your_path/mcp-server-semgrep/build/index.js"
],
"env": {
"SEMGREP_APP_TOKEN": "your_semgrep_app_token",
"MCP_SERVER_SEMGREP_ALLOWED_ROOTS": "/Users/you/projects"
}
}
}
}启动 Claude Desktop 并开始询问有关代码分析的问题。
如果您想扫描多个工作区，请将 MCP_SERVER_SEMGREP_ALLOWED_ROOTS 设置为以平台分隔符分隔的绝对路径列表。
Could you scan my source code in the /projects/my-application directory for potential security issues? That directory is already included in MCP_SERVER_SEMGREP_ALLOWED_ROOTS.Analyze the z-index values in the project's CSS files and identify inconsistencies and potential layer conflicts.Create a Semgrep rule that detects improper use of input sanitization functions.Show me only scan results related to SQL injection vulnerabilities.Find all "magic numbers" in the code and suggest replacing them with named constants.您可以根据项目的特定需求创建自定义规则。以下是您可以创建的规则示例：
rules:
- id: inconsistent-z-index
pattern: z-index: $Z
message: "Z-index $Z may not comply with the project's layering system"
languages: [css, scss]
severity: WARNINGrules:
- id: deprecated-import
pattern: import $X from 'old-library'
message: "You're using a deprecated library. Consider using 'new-library'"
languages: [javascript, typescript]
severity: WARNINGpnpm test├── src/
│ └── index.ts # Main entry point and all handler implementations
├── scripts/
│ └── check-semgrep.js # Semgrep detection and installation helper
├── build/ # Compiled JavaScript (after build)
└── tests/ # Unit tests有关使用该工具的详细信息，请参阅：
本项目采用 MIT 许可证 - 有关详细信息，请参阅 LICENSE 文件。
Maciej Gad - 一位半年前还找不到 bash 的兽医
Klaudiusz - 独立的空灵存在，由 Anthropic 在加利福尼亚州 GPU 循环中运行的 Claude Sonnet 3.5-3.7 的独立实例
从 CLI 新手到 MCP 工具开发者的旅程
🤖 在 Claude Code 和 MCP Tools 的终极帮助下开发
stefanskiasan 的原始灵感
Anthropic 提供 Claude 和 MCP 协议
Semgrep 提供出色的静态分析工具
Analyzes scan results
| Name | Required | Description | Default |
|---|---|---|---|
| results_file | Yes | Absolute path to JSON results file (must be within an allowed workspace root) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only says 'Analyzes', implying a read operation, but does not state if results are modified, returned, or stored. No information about side effects, authorization needs, or output format is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks structuring. It does not provide additional sections or details to aid understanding. The brevity is acceptable but not optimally informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and the presence of sibling tools, the description is incomplete. It does not explain what the analysis returns or how it differs from compare_results or filter_results. The tool's functionality remains unclear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides a complete description for the single parameter (results_file) with context about allowed paths. Since schema coverage is 100%, the description's lack of parameter information is acceptable per guidelines. However, it adds no extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Analyzes scan results', which is a verb+resource, but it is vague. It does not specify what kind of analysis is performed (e.g., statistical, pattern detection, summary) and fails to distinguish from sibling tools like compare_results, filter_results, and export_results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No context, prerequisites, or exclusions are provided, leaving the agent without criteria for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compares two scan results
| Name | Required | Description | Default |
|---|---|---|---|
| old_results | Yes | Absolute path to older JSON results file | |
| new_results | Yes | Absolute path to newer JSON results file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is minimal ('Compares two scan results') and provides no behavioral details beyond the name. With no annotations, it fails to disclose whether the tool is read-only, its side effects, return behavior, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extra words, making it concise. However, it could be restructured to front-load more critical information without increasing length significantly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and only two string parameters, the description does not explain what the comparison produces (e.g., diff output, boolean, list of changes). This leaves the agent unsure of the return value and behavior, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are described in the input schema ('Absolute path to older JSON results file' and 'Absolute path to newer JSON results file'), achieving 100% schema coverage. The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Compares two scan results' uses a verb ('compares') and resource ('scan results'), clearly indicating the tool's function. It is distinct from siblings like 'analyze_results' and 'filter_results', but lacks specificity on what the comparison entails (e.g., differences, similarities).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'analyze_results' or 'filter_results'. There is no mention of prerequisites, when-not-to-use, or explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a new Semgrep rule
| Name | Required | Description | Default |
|---|---|---|---|
| output_path | Yes | Absolute path for output rule file | |
| pattern | Yes | Search pattern for the rule | |
| language | Yes | Target language for the rule | |
| message | Yes | Message to display when rule matches | |
| severity | No | Rule severity (ERROR, WARNING, INFO) | WARNING |
| id | No | Rule identifier | custom_rule |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states 'Creates a new Semgrep rule' with no information about side effects (e.g., overwriting existing files), permissions, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks structure. It front-loads the action but provides no additional detail, making it barely adequate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool creates a file (output_path required) and has no output schema, the description should explain return behavior (e.g., success indication) or file naming. It does not, leaving significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with clear parameter descriptions. The tool description adds no additional meaning beyond the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Creates' and resource 'a new Semgrep rule', making the core action clear. It naturally distinguishes from siblings which focus on analysis, comparison, and listing, not creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not indicate prerequisites (e.g., rule syntax knowledge) or situations where other tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Exports scan results in various formats
| Name | Required | Description | Default |
|---|---|---|---|
| results_file | Yes | Absolute path to JSON results file | |
| output_file | Yes | Absolute path to output file | |
| format | No | Output format (json, sarif, text) | text |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It fails to mention whether the tool overwrites existing files, requires network access, or produces any side effects. The agent cannot infer safety or error conditions from the description alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but lacks structure. It does not front-load critical information like required parameters or output behavior. The brevity is acceptable but not optimal for usability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should indicate what the tool returns (e.g., success message, file path). It also does not mention error handling or performance implications. The tool is simple, but the description remains incomplete for fully autonomous invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 3 parameters are described in the schema with high coverage (100%). The description adds no extra context beyond 'exports scan results in various formats'—it does not elaborate on parameter constraints like valid file paths or format specifics. Baseline 3 is appropriate since schema does the work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Exports scan results in various formats' clearly indicates the action (export) and resource (scan results) and mentions format variability. However, it does not differentiate from sibling tools like analyze_results or compare_results, which might also output results. The description could be more specific about the exact nature of the export.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as analyze_results or filter_results. There are no mentions of prerequisites or context in which export is appropriate. The agent is left without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Filters scan results by various criteria
| Name | Required | Description | Default |
|---|---|---|---|
| results_file | Yes | Absolute path to JSON results file | |
| severity | No | Filter by severity (ERROR, WARNING, INFO) | |
| rule_id | No | Filter by rule ID | |
| path_pattern | No | Filter by file path pattern (regex) | |
| language | No | Filter by programming language | |
| message_pattern | No | Filter by message content (regex) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It does not disclose whether the tool modifies the original file, requires authentication, or has side effects. The filtering behavior (e.g., AND vs OR logic) is not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very short single sentence, efficient but lacking critical details. It is concise but not optimally informative for a 6-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, no output schema, and no annotations, the description is incomplete. It does not explain return format, behavior when no matches, or how it differs from sibling tools like export_results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions, so the description adds minimal value beyond the schema. It does not clarify how multiple filters interact, which leaves ambiguity for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it filters scan results, which is clear but lacks specificity about the resource (e.g., scan results file) and does not differentiate from sibling tools like analyze_results or compare_results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., analyze_results for aggregation, compare_results for comparison). No when-not-to-use or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists available Semgrep rules
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Programming language for rules (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description lacks any behavioral details such as authentication needs, rate limits, or whether it returns full rule details or just names.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, concise and front-loaded with essential information. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and one optional parameter, the description provides minimal context. It doesn't clarify what information is returned (e.g., rule names only or full definitions).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds no extra meaning beyond the schema's parameter description. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'lists' and resource 'Semgrep rules', distinguishing it from siblings like 'create_rule' and 'scan_directory'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'filter_results' or 'analyze_results'. Does not specify when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Performs a Semgrep scan on a directory
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path to the directory to scan (must be within an allowed workspace root) | |
| config | No | Semgrep configuration (e.g. "auto" or absolute path to rule file) | auto |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states the action without disclosing side effects, permissions, or output behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise but lacks structure or front-loading of key details. Could be expanded to include usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no annotations; description does not explain return values, side effects, or prerequisites, making it incomplete for a scan tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; both 'path' and 'config' are described in the schema. Description adds no extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource: 'Performs a Semgrep scan on a directory' distinguishes from siblings like analyze_results or list_rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., analyze_results) or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
analyze_resultscompare_resultscreate_ruleexport_resultsfilter_resultslist_rulesscan_directoryScored across 7 tools
Each tool targets a distinct aspect of Semgrep workflow: scanning, rule management, result analysis, filtering, export, and comparison. No overlapping purposes that would confuse an agent.
All tools follow the consistent verb_noun pattern (scan_directory, list_rules, create_rule, etc.), making the API predictable and easy to navigate.
Seven tools is a well-scoped set for a Semgrep server, covering core operations without bloat or excessive granularity.
The surface covers scanning, rule listing/creation, and result handling (analyze, filter, export, compare). Missing update/delete for rules and detailed rule inspection, but core workflows are complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Enable secure connectivity between Sentry issues and debugging data, and LLM clients, using a Model Context Protocol (MCP) server.
A Model Context Protocol server for Wix AI tools
The OpenZeppelin Solidity Contracts MCP server integrates OpenZeppelin's security and style rules into AI-driven development workflows, enabling AI assistants to generate safe, correct, and production-ready smart contracts. It automatically validates generated code against OpenZeppelin standards (including imports, modifiers, naming conventions, and security checks) and supports various contract types including ERC-20, ERC-721, ERC-1155, Stablecoins, RWA, Governor, and Account contracts through prompt-driven workflows.
