작성자: 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와 저장소 간의 변환을 수행합니다.
즉, 데이터 소스를 교체(파일 → 데이터베이스)하더라도 MCP 계층을 전혀 변경하지 않고 parser.ts만 변경하면 됩니다.
동적 메타데이터 파싱 — 파일 파서가 필드 위치를 하드코딩하는 대신 런타임에 # FORMAT: 헤더에서 열 이름을 읽습니다. 버전 확인(# VERSION: 1.0)과 결합하여 서버가 코드 수정 없이 형식 변경을 감지하고 경고할 수 있도록 합니다.
메모리 내 인덱싱을 사용하는 저장소 패턴 — 데이터는 시작 시 한 번 로드되어 여러 Map(vendorById, vulnByCveId, vulnsByVendor, vulnsBySeverity, vulnsByStatus)에 인덱싱됩니다. 기본 조회는 O(1)입니다. 필터링된 검색은 가장 작은 인덱싱된 하위 집합에서 시작하여 교차하므로 대규모 데이터에서도 결합된 쿼리가 효율적입니다.
상위 수준 McpServer API — 수동 JSON 스키마 정의 및 요청 라우팅이 포함된 하위 수준 Server 클래스 대신, 유형 안전 입력 유효성 검사를 위해 Zod 스키마와 함께 McpServer.registerTool()을 사용합니다.
선택적 필터를 사용한 유연한 검색 — search_vulnerabilities는 모든 매개변수를 선택 사항으로 허용하여 모든 조합을 가능하게 합니다. 하나의 도구가 "모든 심각한 항목 표시"부터 "CVSS 8 이상인 2023년 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의 National Vulnerability Database에서 CVE 데이터를 자동으로 업데이트합니다.
MCP 리소스 — 전체 텍스트 컨텍스트가 필요할 때 LLM이 직접 액세스할 수 있도록 원시 데이터 파일을 MCP 리소스로 노출합니다.
구조화된 로깅 및 관찰 가능성 — 도구 호출 체인을 디버깅하기 위해 상관관계 ID가 포함된 JSON 형식 로그를 사용합니다.
인증 및 속도 제한 — 공유 배포 시나리오에서 서버를 보호합니다.
CI/CD 파이프라인 — 모든 푸시 시 린트, 유형 검사 및 테스트를 실행하는 GitHub Actions를 구축합니다.
구성 요소 | 선택 |
언어 | 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.
