作者：Or Cohen
一个 MCP（模型上下文协议）服务器，它封装了一个遗留漏洞数据库，并将其作为工具暴露给任何兼容 MCP 的 LLM 客户端。它构建在自定义管道分隔数据文件之上的智能访问层，使安全分析师能够使用自然语言查询漏洞。
Node.js 18+
Claude Desktop（或任何兼容 MCP 的客户端）
git clone https://github.com/orcohen5/vulnerability-registry.git
cd vulnerability-registry
npm install
npm run build添加到您的 Claude Desktop 配置中（Windows 上为 %APPDATA%\Claude\claude_desktop_config.json，macOS 上为 ~/Library/Application Support/Claude/claude_desktop_config.json）：
{
"mcpServers": {
"vulnerability-registry": {
"command": "node",
"args": [
"<FULL_PATH>/vulnerability-registry/dist/index.js",
"<FULL_PATH>/vulnerability-registry/data"
]
}
}
}将 <FULL_PATH> 替换为克隆仓库的绝对路径。
重启 Claude Desktop，然后询问：
“你有哪些用于漏洞查询的 MCP 工具？”
Claude Desktop 发现了所有 6 个漏洞注册表工具
Related MCP server: pentestMCP
工具 | 描述 | 关键参数 | 示例查询 |
| 列出所有已注册的软件供应商 |
| “向我展示所有开源供应商” |
| 通过 ID 或名称查找供应商 |
| “查找 Linux Kernel 的供应商 ID” |
| 使用灵活的过滤器进行搜索 |
| “显示严重且未修复的漏洞” |
| 获取完整的 CVE 详情 |
| “Log4Shell 的 CVSS 评分是多少？” |
| 聚合统计信息 |
| “按严重程度划分的漏洞有多少？” |
| 供应商风险概况 |
| “向我展示微软的风险概况” |
使用 search_vulnerabilities，参数为 severity: "critical" 和 status: "open"。
使用 get_vulnerability，参数为 cve_id: "CVE-2021-44228"。
使用 get_vendor_risk_summary，参数为 vendor_id: "V1"。
此查询演示了多工具编排 — Claude 首先调用 list_vendors 将“Linux Kernel”解析为供应商 ID V5，然后使用 vendor_id: "V5" 和 published_after: "2022-01-01" 调用 search_vulnerabilities。
┌─────────────────┐ ┌──────────────┐ ┌──────────────┐
│ Claude Desktop │────▶│ MCP Server │────▶│ Data Files │
│ (MCP Client) │◀────│ (stdio) │◀────│ (.db) │
└─────────────────┘ └──────┬───────┘ └──────────────┘
│
┌──────────┼──────────┐
▼ ▼ ▼
tools.ts repository.ts parser.ts
(MCP layer) (query engine) (file reader)代码库遵循严格的三层分离原则：
parser.ts — 动态读取自定义管道分隔格式。对 MCP 一无所知。
repository.ts — 带有索引 Map 的内存数据存储，用于 O(1) 查找。对 MCP 一无所知。
tools.ts — 使用高级 McpServer API 注册 MCP 工具。在 MCP 和存储库之间进行转换。
这意味着更换数据源（文件 → 数据库）只需更改 parser.ts，而无需对 MCP 层进行任何更改。
动态元数据解析 — 文件解析器在运行时从 # FORMAT: 头部读取列名，而不是硬编码字段位置。结合版本检查 (# VERSION: 1.0)，这确保了服务器可以在不修改代码的情况下检测并警告格式更改。
带有内存索引的存储库模式 — 数据在启动时加载一次，并索引到多个 Map 中 (vendorById, vulnByCveId, vulnsByVendor, vulnsBySeverity, vulnsByStatus)。主要查找操作为 O(1)。过滤搜索从最小的索引子集开始并进行交集运算，即使在大规模数据下也能使组合查询保持高效。
高级 McpServer API — 使用带有 Zod 模式的 McpServer.registerTool() 进行类型安全的输入验证，而不是使用带有手动 JSON Schema 定义和请求路由的低级 Server 类。
带有可选过滤器的灵活搜索 — search_vulnerabilities 接受所有参数作为可选参数，允许任意组合。一个工具即可处理从“显示所有严重漏洞”到“查找 2023 年 CVSS 高于 8 的 Linux CVE”等各种查询。结果始终按 CVSS 评分排序（最高分优先），以便最严重的问题首先显示。
丰富的响应 — get_vulnerability 在返回 CVE 数据时会同时返回完整的供应商对象。get_vendor_risk_summary 包含未修复漏洞的列表。这减少了 LLM 回答常见问题所需的工具调用次数。
严格的类型安全 — Severity 和 Status 是派生自 as const 数组的联合类型，并带有运行时类型保护 (isSeverity, isStatus)。相同的真值数组同时为 TypeScript 类型和 Zod 枚举验证器提供支持。
在使用源数据文件时，我发现至少存在一个归属不一致问题：
CVE-2024-21762 (Fortinet SSL VPN OOB) 在 vulnerabilities.db 中被映射到供应商 V4 (Google)，
尽管这是一个 Fortinet 的漏洞。服务器忠实地返回存储的数据 —
纠正源数据超出了只读查询层的范围。在生产系统中，
我会在加载时添加一个数据验证步骤，以标记此类不一致之处供人工审查，
例如通过交叉引用 NVD API 来获取规范的供应商归属。
SQLite/PostgreSQL 持久化 — 对于超过可用 RAM 的数据集，替换内存存储，并使用连接池进行并发访问。
分页 — 为 search_vulnerabilities 添加 limit/offset 参数，以处理大型结果集。
模糊文本搜索 — 对漏洞标题进行 Levenshtein 距离匹配，以实现容错查询。
NVD API 集成 — 从 NIST 的国家漏洞数据库自动更新 CVE 数据。
MCP 资源 — 将原始数据文件作为 MCP 资源暴露，以便在需要全文上下文时供 LLM 直接访问。
结构化日志记录与可观测性 — 带有相关 ID 的 JSON 格式日志，用于调试工具调用链。
身份验证与速率限制 — 在共享部署场景中保护服务器。
CI/CD 流水线 — GitHub Actions 在每次推送时运行 lint、类型检查和测试。
组件 | 选择 |
语言 | TypeScript (ES2022, Node16 模块) |
MCP SDK |
|
验证 | Zod |
传输 | stdio |
构建 | tsc |
测试 | Vitest |
npm test # Run all tests (30 tests across parser + repository)
npm run build # Compile TypeScript
npm start # Start the MCP server (stdio mode)Get details about a specific vendor by their ID (e.g. 'V1') or by name (case-insensitive partial match, e.g. 'linux' will match 'Linux Kernel Organization'). Use this to find a vendor's ID before querying their vulnerabilities.
| Name | Required | Description | Default |
|---|---|---|---|
| vendor_id | No | Vendor ID, e.g. 'V1', 'V2' | |
| name | No | Full or partial vendor name, case-insensitive |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context about case-insensitive partial matching and the purpose of finding IDs for vulnerability queries, but it does not cover other behavioral aspects like error handling, rate limits, or authentication needs, leaving some gaps in transparency.
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 appropriately sized and front-loaded, with two sentences that efficiently convey the tool's purpose, usage method, and context without any wasted words, making it easy for an agent to parse and understand quickly.
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's moderate complexity (2 parameters, no output schema, no annotations), the description is adequate but has gaps. It explains the purpose and usage well but lacks details on behavioral traits like error responses or performance, which could be important for an agent to invoke it correctly in varied scenarios.
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 description coverage is 100%, so the schema already documents both parameters thoroughly. The description adds minimal value by reinforcing the use of ID or name with examples, but it does not provide additional syntax or format details beyond what the schema specifies, aligning with 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 clearly states the tool's purpose with a specific verb ('Get details') and resource ('about a specific vendor'), and distinguishes it from siblings by mentioning its use for finding vendor IDs before querying vulnerabilities, which differentiates it from tools like 'get_vulnerability' or 'list_vendors'.
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?
The description provides clear context on when to use this tool (to find a vendor's ID before querying vulnerabilities) and how to use it (by ID or name with partial matching), but it does not explicitly state when not to use it or name specific alternatives among the sibling tools, such as 'list_vendors' for broader listings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a comprehensive risk profile for a specific vendor. Shows total vulnerabilities, open vs patched breakdown, severity distribution, highest CVSS score, and lists all currently open vulnerabilities. Ideal for vendor risk assessment.
| Name | Required | Description | Default |
|---|---|---|---|
| vendor_id | Yes | Vendor ID to analyze, e.g. 'V1' for Microsoft |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It describes the output content (risk profile with breakdowns, lists open vulnerabilities) but does not cover other behavioral aspects such as permissions needed, rate limits, error handling, or data freshness. It adequately conveys it's a read operation but lacks deeper context.
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 front-loaded with the core purpose in the first sentence, followed by specific details and usage context in two concise sentences. Every sentence adds value: the first defines the tool, the second enumerates output components, and the third provides usage guidance, with 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 the tool's complexity (risk profiling with multiple metrics) and lack of annotations and output schema, the description does a good job explaining what the tool returns (breakdowns, severity, CVSS score, open vulnerabilities list). However, it could be more complete by detailing the output format or structure, which is missing since there's no output schema.
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 description coverage is 100%, with the parameter 'vendor_id' fully documented in the schema. The description does not add any parameter-specific details beyond what the schema provides (e.g., no examples of valid vendor IDs beyond the schema's 'e.g. 'V1' for Microsoft'), so it meets the baseline for high schema coverage without compensating with extra semantics.
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 specific action ('Get a comprehensive risk profile') and resource ('for a specific vendor'), distinguishing it from siblings like 'get_vendor' (likely basic info) or 'get_vulnerability_stats' (general stats). It explicitly lists the detailed components of the risk profile (vulnerabilities breakdown, severity distribution, etc.), making the purpose highly specific and differentiated.
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?
The description provides clear context for when to use this tool ('Ideal for vendor risk assessment'), which implicitly suggests it's for evaluating vendor security rather than general lookup. However, it does not explicitly state when not to use it or name alternatives (e.g., use 'get_vendor' for basic info, 'search_vulnerabilities' for specific issues), leaving some guidance gaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full details of a specific vulnerability by its CVE ID (e.g. 'CVE-2021-44228') or internal ID (e.g. 'CVE001'). Returns the vulnerability with its associated vendor information.
| Name | Required | Description | Default |
|---|---|---|---|
| cve_id | Yes | CVE identifier, e.g. 'CVE-2021-44228' or internal ID like 'CVE001' |
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 states what the tool returns ('full details' with 'associated vendor information'), but doesn't mention error handling (e.g., what happens if the ID doesn't exist), authentication requirements, rate limits, or whether this is a read-only operation. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
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 perfectly concise with two sentences: the first states the purpose and parameters, the second specifies the return value. Every word earns its place, and information is front-loaded appropriately.
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's moderate complexity (single parameter lookup), 100% schema coverage, but no annotations and no output schema, the description is adequate but incomplete. It covers the basic purpose and return scope, but lacks behavioral details that would be crucial for reliable agent use, especially without annotations.
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%, so the schema already fully documents the single parameter. The description adds minimal value by mentioning both CVE ID and internal ID formats, which the schema also covers. Baseline 3 is appropriate when the schema does the heavy lifting.
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 ('Get full details') and resource ('specific vulnerability'), specifies the lookup method ('by its CVE ID or internal ID'), and distinguishes from siblings like 'search_vulnerabilities' (which likely returns multiple results) and 'get_vulnerability_stats' (which provides aggregated data).
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?
The description implicitly indicates when to use this tool (when you need full details for a specific known vulnerability ID), but doesn't explicitly state when not to use it or name alternatives like 'search_vulnerabilities' for broader queries. The context is clear but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get summary statistics about vulnerabilities. Shows counts by severity, status, vendor, and year, plus CVSS score metrics (average, min, max). Optionally scope stats to a specific vendor.
| Name | Required | Description | Default |
|---|---|---|---|
| vendor_id | No | Optional vendor ID to scope stats, e.g. 'V1' for Microsoft only |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the tool's behavior as a read operation ('Get summary statistics') and scoping capability, but lacks details on permissions, rate limits, data freshness, or output format. It adequately describes what the tool does without contradicting any annotations.
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 efficiently structured in two sentences: the first states the core purpose and detailed metrics, the second adds the optional scoping feature. Every sentence adds value with zero waste, making it front-loaded and appropriately sized for the tool's complexity.
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 annotations and no output schema, the description is complete enough for a simple read tool with one optional parameter. It covers the purpose, scope, and basic usage, but lacks details on output format, error handling, or advanced behavioral traits, which would be beneficial for full contextual understanding.
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%, so the schema already documents the optional 'vendor_id' parameter. The description adds marginal value by mentioning scoping to a vendor, but does not provide additional syntax, format details, or examples beyond what the schema specifies. Baseline 3 is appropriate as the schema does the heavy lifting.
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 specific action ('Get summary statistics') and resource ('about vulnerabilities'), with detailed scope ('counts by severity, status, vendor, and year, plus CVSS score metrics'). It distinguishes from siblings like 'get_vulnerability' (single item) and 'search_vulnerabilities' (filtered search) by focusing on aggregated statistics.
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?
The description provides clear context for usage ('Optionally scope stats to a specific vendor'), but does not explicitly state when not to use it or name alternatives among the sibling tools. It implies usage for aggregated vulnerability data rather than individual records or searches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all registered software vendors in the vulnerability database. Optionally filter by category (e.g. 'Software', 'Open Source').
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Filter by vendor category, e.g. 'Software' or 'Open Source' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions listing 'all registered software vendors' and optional filtering, but doesn't address key behaviors such as pagination, rate limits, authentication requirements, or what happens if no vendors match the filter. This leaves significant gaps for an agent to understand how to interact with the tool effectively.
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 appropriately sized with two sentences that are front-loaded with the core purpose. The first sentence states the main action, and the second adds filtering details without unnecessary elaboration. However, it could be slightly more structured by explicitly separating purpose from parameters.
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's low complexity (1 optional parameter, no output schema, no annotations), the description is moderately complete but lacks depth. It covers the basic purpose and parameter usage but misses behavioral context like response format, error handling, or integration with sibling tools. This makes it adequate but not fully comprehensive for an agent's needs.
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 description adds minimal value beyond the input schema, which already has 100% coverage. It mentions the optional 'category' parameter and provides examples ('Software', 'Open Source'), but doesn't elaborate on semantics like valid categories, case sensitivity, or default behavior when omitted. Since the schema does the heavy lifting, the baseline score of 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 ('List') and resource ('registered software vendors in the vulnerability database'), making the purpose specific and understandable. However, it doesn't explicitly differentiate this tool from its sibling 'get_vendor', which appears to retrieve a single vendor rather than list multiple vendors.
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?
The description implies usage by mentioning optional filtering by category, but it doesn't provide explicit guidance on when to use this tool versus alternatives like 'search_vulnerabilities' or 'get_vendor_risk_summary'. No exclusions or prerequisites are stated, leaving usage context somewhat vague.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search and filter vulnerabilities with flexible criteria. All filters are optional and can be combined. Returns matching vulnerabilities sorted by CVSS score (highest first). Use for questions like 'show critical open vulnerabilities' or 'find CVEs published after 2023'.
| Name | Required | Description | Default |
|---|---|---|---|
| vendor_id | No | Filter by vendor ID, e.g. 'V1' | |
| severity | No | Filter by severity level: critical, high, medium, or low | |
| status | No | Filter by status: open or patched | |
| min_cvss | No | Minimum CVSS score (0.0-10.0) | |
| max_cvss | No | Maximum CVSS score (0.0-10.0) | |
| published_after | No | Show CVEs published after this date (YYYY-MM-DD) | |
| published_before | No | Show CVEs published before this date (YYYY-MM-DD) | |
| keyword | No | Search in CVE title and ID, e.g. 'Log4Shell' or 'CVE-2021' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: all filters are optional and combinable, results are sorted by CVSS score (highest first), and it handles date-based filtering. It doesn't mention pagination, rate limits, or authentication needs, but covers core functionality adequately.
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 perfectly front-loaded with the core purpose in the first sentence, followed by behavioral details and usage examples. Every sentence earns its place with no wasted words, making it highly efficient and easy to parse.
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's complexity (8 parameters, no output schema, no annotations), the description provides good contextual completeness. It covers purpose, behavior, and usage examples, though it doesn't describe the return format or potential limitations. For a search tool with well-documented parameters, this is sufficient but could benefit from output details.
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%, so the baseline is 3. The description adds minimal parameter semantics beyond the schema, only implying flexibility through 'all filters are optional and can be combined'. It doesn't explain parameter interactions or provide additional context beyond what's in the schema descriptions.
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 tool's purpose with specific verbs ('search and filter vulnerabilities') and resource ('vulnerabilities'), distinguishing it from siblings like get_vulnerability (singular retrieval) or get_vulnerability_stats (aggregate statistics). It explicitly mentions flexible criteria and sorting behavior, making the scope unambiguous.
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?
The description provides explicit usage guidance with concrete examples ('show critical open vulnerabilities', 'find CVEs published after 2023'), indicating when to use this tool. It distinguishes from siblings by focusing on filtered searches rather than direct retrieval or statistical summaries, though it doesn't explicitly name alternatives.
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.0get_vendorget_vendor_risk_summaryget_vulnerabilityget_vulnerability_statslist_vendorssearch_vulnerabilitiesScored across 6 tools
Each tool has a clearly distinct purpose with no overlap: get_vendor retrieves vendor details, get_vendor_risk_summary provides risk profiles, get_vulnerability fetches specific vulnerability data, get_vulnerability_stats offers statistical summaries, list_vendors enumerates vendors, and search_vulnerabilities enables filtered searches. The descriptions explicitly differentiate their functions, preventing agent misselection.
All tool names follow a consistent verb_noun pattern using snake_case, with verbs like 'get', 'list', and 'search' clearly indicating actions. This uniformity makes the tool set predictable and easy to navigate, enhancing agent usability without any naming deviations.
With 6 tools, the server is well-scoped for a vulnerability registry, covering core operations such as retrieving vendors and vulnerabilities, assessing risks, and generating statistics. Each tool serves a unique and necessary function, avoiding bloat or gaps for this domain.
The tool set provides comprehensive coverage for querying and analyzing vulnerability data, including CRUD-like operations for vendors and vulnerabilities, risk assessment, and statistical insights. A minor gap exists in the lack of tools for creating, updating, or deleting entries, but this is reasonable for a read-only registry focused on data retrieval and analysis.
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
ZEN SecDB MCP server for CVE intelligence, CVSS/EPSS scoring, advisories, SSVC, and package audits.
MCP server for Pentest-Tools.com: run scans, manage findings and reports via your preffered LLM.
