作成者: Or Cohen
レガシーな脆弱性データベースをラップし、MCP対応のLLMクライアント向けツールとして公開するMCP (Model Context Protocol) サーバーです。カスタムのパイプ区切りデータファイルに対するスマートなアクセスレイヤーとして構築されており、セキュリティアナリストが自然言語で脆弱性を照会できるようにします。
Node.js 18以上
Claude Desktop (またはその他のMCP対応クライアント)
git clone https://github.com/orcohen5/vulnerability-registry.git
cd vulnerability-registry
npm install
npm run buildClaude Desktopの設定ファイル (%APPDATA%\Claude\claude_desktop_config.json (Windowsの場合)、~/Library/Application Support/Claude/claude_desktop_config.json (macOSの場合)) に以下を追加します。
{
"mcpServers": {
"vulnerability-registry": {
"command": "node",
"args": [
"<FULL_PATH>/vulnerability-registry/dist/index.js",
"<FULL_PATH>/vulnerability-registry/data"
]
}
}
}<FULL_PATH> をクローンしたリポジトリの絶対パスに置き換えてください。
Claude Desktopを再起動し、次のように尋ねてください。
"脆弱性に関するMCPツールには何がありますか？"
6つの脆弱性レジストリツールを認識したClaude Desktop
Related MCP server: pentestMCP
ツール | 説明 | 主要パラメータ | クエリ例 |
| 登録されているすべてのソフトウェアベンダーを一覧表示 |
| "オープンソースのベンダーをすべて見せて" |
| IDまたは名前でベンダーを検索 |
| "Linux KernelのベンダーIDを探して" |
| 柔軟なフィルターで検索 |
| "深刻な未解決の脆弱性を表示して" |
| CVEの詳細情報を取得 |
| "Log4ShellのCVSSスコアは？" |
| 統計を集計 |
| "深刻度別の脆弱性件数は？" |
| ベンダーのリスクプロファイル |
| "Microsoftのリスクプロファイルを表示して" |
severity: "critical" および status: "open" を指定して search_vulnerabilities を使用します。
cve_id: "CVE-2021-44228" を指定して get_vulnerability を使用します。
vendor_id: "V1" を指定して get_vendor_risk_summary を使用します。
このクエリはマルチツールオーケストレーションを示しています。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)コードベースは厳格な3層分離に従っています。
parser.ts — カスタムのパイプ区切り形式を動的に読み取ります。MCPについては何も知りません。
repository.ts — O(1)ルックアップ用のインデックス付きMapを備えたインメモリデータストアです。MCPについては何も知りません。
tools.ts — 高レベルの McpServer APIを使用してMCPツールを登録します。MCPとリポジトリの間で変換を行います。
つまり、データソースを（ファイルからデータベースへ）変更する場合、parser.ts を変更するだけで済み、MCPレイヤーへの変更は不要です。
動的なメタデータ解析 — ファイルパーサーは、フィールド位置をハードコーディングするのではなく、実行時に # FORMAT: ヘッダーから列名を読み取ります。バージョンチェック (# VERSION: 1.0) と組み合わせることで、コードを変更することなく形式の変更を検出し、警告することができます。
インメモリインデックスを備えたリポジトリパターン — データは起動時に一度読み込まれ、複数のMap (vendorById, vulnByCveId, vulnsByVendor, vulnsBySeverity, vulnsByStatus) にインデックス化されます。主要なルックアップはO(1)です。フィルタリングされた検索は、最小のインデックス付きサブセットから開始して交差させるため、大規模なデータでも複合クエリを効率的に実行できます。
高レベルの McpServer API — 手動のJSONスキーマ定義やリクエストルーティングを行う低レベルの Server クラスではなく、型安全な入力検証のためにZodスキーマを備えた McpServer.registerTool() を使用しています。
オプションフィルターによる柔軟な検索 — search_vulnerabilities はすべてのパラメータをオプションとして受け入れるため、あらゆる組み合わせが可能です。「深刻なものをすべて表示」から「2023年以降のCVSS 8以上のLinux CVEを検索」まで、1つのツールで処理できます。結果は常にCVSSスコア順（高い順）にソートされるため、最も深刻な問題が最初に表示されます。
リッチなレスポンス — get_vulnerability はCVEデータとともに完全なベンダーオブジェクトを返します。get_vendor_risk_summary には未解決の脆弱性リストが含まれます。これにより、LLMが一般的な質問に答えるために必要なツール呼び出しの回数が削減されます。
厳格な型安全性 — Severity と Status は as const 配列から派生したユニオン型であり、実行時の型ガード (isSeverity, isStatus) を備えています。同じ信頼できる情報源（ソース・オブ・トゥルース）の配列が、TypeScriptの型とZodの列挙型バリデーターの両方に供給されます。
ソースデータファイルを操作する際、少なくとも1つの帰属の不整合を確認しました。
CVE-2024-21762 (Fortinet SSL VPN OOB) は vulnerabilities.db 内でベンダー V4 (Google) にマッピングされていますが、これはFortinetの脆弱性です。サーバーは保存されているデータを忠実に返します。ソースデータの修正は、読み取り専用クエリレイヤーの範囲外です。本番システムであれば、ロード時にデータ検証ステップを追加し、NVD APIと照合して正規のベンダー帰属を確認するなど、人間によるレビューのために不整合をフラグ立てします。
SQLite/PostgreSQLの永続化 — 利用可能なRAMを超えるデータセットのためにインメモリストレージを置き換え、同時アクセス用に接続プールを導入します。
ページネーション — 大規模な結果セットのために search_vulnerabilities に limit/offset パラメータを追加します。
あいまい検索 — タイプミスを許容するクエリのために、脆弱性タイトルに対してレーベンシュタイン距離マッチングを導入します。
NVD API統合 — NISTのNational Vulnerability Databaseからの自動CVEデータ更新。
MCPリソース — 全文コンテキストが必要な場合に備え、生のデータファイルをMCPリソースとして公開します。
構造化ログと可観測性 — ツール呼び出しチェーンをデバッグするための相関ID付きのJSON形式ログ。
認証とレート制限 — 共有デプロイメントシナリオでサーバーを保護します。
CI/CDパイプライン — プッシュごとにlint、型チェック、テストを実行するGitHub Actions。
コンポーネント | 選択 |
言語 | TypeScript (ES2022, Node16 modules) |
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.
