Автор: Or Cohen
Сервер MCP (Model Context Protocol), который оборачивает устаревшую базу данных уязвимостей и предоставляет её в виде инструментов для любого 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 (%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-инструменты у тебя есть для работы с уязвимостями?"
Claude Desktop обнаруживает все 6 инструментов реестра уязвимостей
Related MCP server: pentestMCP
Инструмент | Описание | Основные параметры | Пример запроса |
| Список всех зарегистрированных поставщиков ПО |
| "Покажи мне всех поставщиков открытого ПО" |
| Поиск поставщика по ID или имени |
| "Найди ID поставщика для Linux Kernel" |
| Поиск с гибкими фильтрами |
| "Покажи критические открытые уязвимости" |
| Получение полных данных CVE |
| "Какой CVSS-балл у Log4Shell?" |
| Агрегированная статистика |
| "Сколько уязвимостей по уровню серьезности?" |
| Профиль риска поставщика |
| "Покажи мне профиль риска Microsoft" |
Использует 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, затем вызывает search_vulnerabilities с vendor_id: "V5" и published_after: "2022-01-01".
┌─────────────────┐ ┌──────────────┐ ┌──────────────┐
│ 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 — хранилище данных в оперативной памяти с индексированными картами (Maps) для поиска за O(1). Ничего не знает об MCP.
tools.ts — регистрирует инструменты MCP с использованием высокоуровневого API McpServer. Выполняет преобразование между MCP и репозиторием.
Это означает, что для замены источника данных (файлы → база данных) нужно изменить только parser.ts, без каких-либо изменений на уровне MCP.
Динамический парсинг метаданных — парсер файлов считывает имена столбцов из заголовка # FORMAT: во время выполнения, а не жестко кодирует позиции полей. В сочетании с проверкой версии (# VERSION: 1.0) это гарантирует, что сервер может обнаруживать и предупреждать об изменениях формата без модификации кода.
Паттерн репозитория с индексацией в памяти — данные загружаются один раз при запуске и индексируются в несколько карт (vendorById, vulnByCveId, vulnsByVendor, vulnsBySeverity, vulnsByStatus). Основные операции поиска выполняются за O(1). Отфильтрованные поисковые запросы начинаются с наименьшего индексированного подмножества и пересекаются, что делает комбинированные запросы эффективными даже при больших объемах данных.
Высокоуровневый API McpServer — использует McpServer.registerTool() со схемами Zod для безопасной проверки типов ввода, вместо низкоуровневого класса Server с ручным определением JSON Schema и маршрутизацией запросов.
Гибкий поиск с необязательными фильтрами — search_vulnerabilities принимает все параметры как необязательные, допуская любую комбинацию. Один инструмент обрабатывает запросы от "показать все критические" до "найти CVE для Linux с 2023 года с CVSS выше 8". Результаты всегда сортируются по баллу CVSS (сначала самые высокие), поэтому наиболее серьезные проблемы отображаются первыми.
Обогащенные ответы — get_vulnerability возвращает полный объект поставщика вместе с данными CVE. get_vendor_risk_summary включает список открытых уязвимостей. Это сокращает количество вызовов инструментов, необходимых LLM для ответа на распространенные вопросы.
Строгая типизация — Severity и Status являются типами объединения (union types), производными от массивов as const, с проверками типов во время выполнения (isSeverity, isStatus). Одни и те же массивы-источники истины питают как типы TypeScript, так и валидаторы перечислений Zod.
При работе с исходными файлами данных я обнаружил как минимум одно несоответствие в атрибуции:
CVE-2024-21762 (Fortinet SSL VPN OOB) сопоставлен с поставщиком V4 (Google) в vulnerabilities.db,
хотя это уязвимость Fortinet. Сервер добросовестно возвращает данные в том виде, в котором они хранятся —
исправление исходных данных выходит за рамки уровня запросов "только для чтения". В промышленной системе
я бы добавил этап проверки данных при загрузке, чтобы помечать такие несоответствия для проверки человеком,
возможно, путем перекрестной проверки с API NVD для канонической атрибуции поставщика.
Персистентность SQLite/PostgreSQL — замена хранения в памяти для наборов данных, превышающих доступную оперативную память, с пулом соединений для параллельного доступа.
Пагинация — добавление параметров limit/offset в search_vulnerabilities для больших наборов результатов.
Нечеткий поиск текста — сопоставление по расстоянию Левенштейна в названиях уязвимостей для запросов, устойчивых к опечаткам.
Интеграция с API NVD — автоматическое обновление данных CVE из Национальной базы данных уязвимостей NIST.
Ресурсы MCP — предоставление доступа к необработанным файлам данных как к ресурсам MCP для прямого доступа LLM, когда требуется полнотекстовый контекст.
Структурированное логирование и наблюдаемость — логи в формате 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.
