强大的 MCP（模型上下文协议）服务器，可审核 npm 软件包依赖项是否存在安全漏洞。内置远程 npm 注册表集成，可进行实时安全检查。
🔍 实时安全漏洞扫描
🚀 远程 npm 注册表集成
📊 带有严重程度的详细漏洞报告
🛡️ 支持多种严重程度级别（严重、高、中、低）
📦 兼容 npm/pnpm/yarn 包管理器
🔄 自动修复建议
📋 CVSS 评分和 CVE 参考
要通过Smithery自动安装 Claude Desktop 的安全审计工具：
npx -y @smithery/cli install @qianniuspace/mcp-security-audit --client claude将 MCP 配置添加到 Cline /Cursor：
{
"mcpServers": {
"mcp-security-audit": {
"command": "npx",
"args": ["-y", "mcp-security-audit"]
}
}
}克隆存储库：
git clone https://github.com/qianniuspace/mcp-security-audit.git
cd mcp-security-audit安装依赖项并构建：
npm install
npm run build将 MCP 配置添加到 Cline /Cursor：
{
"mcpServers": {
"mcp-security-audit": {
"command": "npx",
"args": ["-y", "/path/to/mcp-security-audit/build/index.js"]
}
}
}Related MCP server: audit-mcp-cli
该工具提供详细的漏洞信息，包括严重程度、修复建议、CVSS 分数和 CVE 参考。
{
"content": [{
"vulnerability": {
"packageName": "lodash",
"version": "4.17.15",
"severity": "high",
"description": "Prototype Pollution in lodash",
"cve": "CVE-2020-8203",
"githubAdvisoryId": "GHSA-p6mc-m468-83gw",
"recommendation": "Upgrade to version 4.17.19 or later",
"fixAvailable": true,
"fixedVersion": "4.17.19",
"cvss": {
"score": 7.4,
"vector": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N"
},
"cwe": ["CWE-1321"],
"url": "https://github.com/advisories/GHSA-p6mc-m468-83gw"
},
"metadata": {
"timestamp": "2024-04-23T10:00:00.000Z",
"packageManager": "npm"
}
}]
}{
"content": [{
"vulnerability": null,
"metadata": {
"timestamp": "2024-04-23T10:00:00.000Z",
"packageManager": "npm",
"message": "No known vulnerabilities found"
}
}]
}作为开发参考，请查看public目录中的示例响应文件：
Severity-response.json ：发现漏洞时的示例响应（从 npm audit API 响应转换而来）
no-Severity-response.json ：未发现漏洞时的示例响应（从 npm audit API 响应转换而来）
注意：上面显示的示例响应是从原始 npm audit API 响应转换而来的，旨在提供更结构化的格式。原始 npm audit API 响应包含其他元数据，并且结构可能有所不同。
欢迎贡献代码！请阅读我们的贡献指南，详细了解我们的行为准则以及提交 Pull Request 的流程。
该项目根据 MIT 许可证获得许可 - 有关详细信息，请参阅LICENSE文件。
ESX（ qianniuspace@gmail.com ）
Audit specific dependencies for vulnerabilities
| Name | Required | Description | Default |
|---|---|---|---|
| dependencies | Yes | Dependencies object from package.json |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It fails to mention whether the operation is read-only, requires network access, or what happens with the dependencies data.
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 one sentence, no unnecessary words. It is concise but slightly under-informative for its brevity.
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 minimal description leave the return value and behavior undocumented. The nested object type is not elaborated.
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 a clear description for the parameter. The tool description adds no additional semantic value 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 clearly states it audits dependencies for vulnerabilities, using a verb-object structure. However, without sibling tools, differentiation is not necessary.
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 the tool, prerequisites, or alternatives. The description assumes the agent knows the context.
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.
v1.0.0audit_nodejs_dependenciesScored across 1 tool
With only one tool, there is no possibility of confusion between tools. The tool's purpose is clearly stated in its name and description, making it unambiguous.
A single tool name follows a clear verb_noun pattern (audit_nodejs_dependencies) which is consistent with typical MCP naming conventions. There are no other names to compare, but the pattern is clear.
Having only one tool is extremely thin for a security audit server. Auditing dependencies likely requires supporting operations like resolving dependency trees, checking for updates, or generating reports, which are missing.
The server's purpose appears to be auditing Node.js dependencies, but it only offers a single operation that audits dependencies without coverage for other lifecycle steps like viewing audit results, fixing vulnerabilities, or scanning different scopes.
Detect malicious or vulnerable npm packages: registry search, OSV.dev and GitHub advisory lookups
Provide AI-powered real-time analysis and intelligence on NPM packages, including security, depend…
Query OSV.dev for package vulnerabilities and batch-audit dependency lists via MCP.
Dive into the world of npm with our NPM Package Info MCP. Access crucial metadata about any npm