Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@bdu-fstec-mcp найди уязвимость BDU:2024-01187"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP-сервер, дающий Claude (и любому MCP-клиенту) доступ к БДУ ФСТЭК — российской базе данных угроз безопасности информации. Работает без геоблокировки: снимок хранится в публичном зеркале как готовая SQLite-база и раздаётся через raw.githubusercontent.com.
bdu.fstec.ru геоблокирует всё, что не Россия: Claude Cloud, GitHub Actions ubuntu-latest, AWS, GCP — туда не попадут.
В российской ИБ-compliance (152-ФЗ, 187-ФЗ, ГОСТ Р 57580) ключевой идентификатор уязвимости — BDU:YYYY-NNNNN, не CVE.
В awesome-mcp-servers до сих пор нет MCP для БДУ.
Related MCP server: NVD MCP Server
Четыре инструмента поверх 86 664 записей (снимок 18.04.2026, источник обновлён 31.12.2025):
search_bdu_vulnerabilities — поиск с ранжированием по FTS5 и фильтрами:
полнотекстовый запрос с корректной токенизацией кириллицы;
min_cvss, min_severity (низкий/средний/высокий/критический);
year (год обнаружения);
vendor (подстрока имени вендора);
has_exploit (только уязвимости с известным эксплойтом).
get_bdu_vulnerability — полная запись по идентификатору БДУ.
find_bdu_by_cve — обратный маппинг CVE → БДУ.
get_bdu_stats — статистика снимка и проверка актуальности.
Операция | Время (86k записей) |
Холодный старт (скачать ~50 МБ SQLite + распаковать) | 5–10 с, один раз |
Последующие старты | <50 мс |
| 1–20 мс |
Фильтр-only ( | <5 мс (composite-индексы) |
| 1–5 мс |
| <5 мс |
FTS5 — unicode61 remove_diacritics 2 с BM25-ранжированием, snippet-подсветкой через «…». Запросы на русском автоматически превращаются в префиксный поиск с обрезкой последних двух букв для простой морфологии (инъекция → инъекц*), так что склонения и падежи находятся.
pip install bdu-fstec-mcpИли локально:
git clone https://github.com/velvetway/bdu-fstec-mcp
cd bdu-fstec-mcp
pip install -e .В ~/.claude/settings.json:
{
"mcpServers": {
"bdu-fstec": { "command": "bdu-fstec-mcp" }
}
}bdu-fstec-mcp # запустить stdio-сервер (по умолчанию)
bdu-fstec-mcp run # то же самое
bdu-fstec-mcp stats # показать статистику локального снимка
bdu-fstec-mcp refresh # принудительно перекачать свежий снимокПеременная | По умолчанию | Описание |
| адрес в зеркале | URL к |
| адрес в зеркале | URL к |
|
| Каталог локального кэша. |
|
| После скольких дней предупреждать о старом снимке. |
|
| Таймаут HTTP-запросов (с). |
Я: Что есть у ФСТЭК по CVE-2024-1086?
Claude (вызывает
find_bdu_by_cve("CVE-2024-1086")):Найдена 1 запись БДУ — BDU:2024-01187, use-after-free в
nft_verdict_init()ядра Linux, CVSS 7.8. Подтверждена производителем, эксплойт существует. Затронуты Astra Linux Special Edition 1.7, РЕД ОС 7.3, Альт 8 СП и ещё 10 дистрибутивов.
Я: Критические уязвимости Astra Linux за 2025 год, где есть эксплойт.
Claude (вызывает
search_bdu_vulnerabilities(query="Astra Linux", min_severity="критический", year=2025, has_exploit=true)):Найдено 4 результата…
src/bdu_fstec_mcp/
__init__.py пакетные константы
_config.py конфигурация через env
_cli.py CLI-обёртка (run/refresh/stats)
cache.py скачивание и staleness-проверка снимка
store.py SQLite+FTS5 запросы и DTO-гидратация
models.py неизменяемые dataclass-модели
formatters.py pretty-print для LLM
server.py MCP stdio-сервер и диспетчер туловДанные живут в отдельном репозитории bdu-fstec-mirror. MCP их только читает.
pip install -e '.[dev]'
pytest # 35 тестов, <1 сПокрыты: FTS5-экранирование, фильтры, маппинг CVE→БДУ, скачивание и fallback кэша, staleness-проверки, форматтеры.
Данные БДУ — публичная информация, размещённая ФСТЭК России на https://bdu.fstec.ru.
Проект не аффилирован с ФСТЭК России.
Код — MIT. Данные остаются собственностью ФСТЭК России.
При ссылке на результаты указывайте источник.
velvetway/minreestr-mcp — MCP для поиска российского ПО в каталоге Минцифры / каталогпо.рф.
velvetway/bdu-fstec-mirror — зеркало БДУ, источник данных для этого MCP.
Обратный маппинг международного CVE-идентификатора в российские записи БДУ. Полезно для cross-reference международных advisory ↔ локальных compliance-документов (187-ФЗ, ГОСТ Р 57580, паспорта КИИ). Одному CVE может соответствовать несколько записей БДУ (разные пакеты, ОС, версии). Read-only. Регистр CVE нечувствителен. Если соответствия нет — возвращает сообщение, что запись отсутствует.
| Name | Required | Description | Default |
|---|---|---|---|
| cve_id | Yes | Идентификатор CVE (case-insensitive). Формат: CVE-YYYY-NNNN или более длинный. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, idempotent. Description adds case-insensitivity, multiplicity of matches, and behavior when no match is found, exceeding the annotation baseline.
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?
Four sentences, no redundancy. Front-loaded with primary purpose. Every sentence adds value without fluff.
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?
For a simple tool with one parameter and no output schema, the description covers input format, case-insensitivity, multiplicity, and edge-case behavior (no match). No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a thorough description, pattern, and examples. The description adds case-insensitivity and contextual usage, but the schema already defines the parameter well.
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?
Description explicitly states the tool performs reverse mapping from CVE to Russian БДУ records. It provides context for cross-referencing international advisories with local compliance documents, clearly distinguishing it from siblings like get_bdu_stats or search_bdu_vulnerabilities.
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?
Description specifies when to use (for cross-reference between CVE and БДУ) and notes that one CVE may map to multiple records. It does not explicitly mention when not to use, but the context of siblings provides alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Метаданные текущего локального снимка БДУ: общее число записей, диапазон идентификаторов BDU:2014-00001 → BDU:YYYY-NNNNN, дата снимка в зеркале, последнее обновление источника. Автоматически проверяет, не устарел ли локальный кэш относительно зеркала (при наличии сетевого доступа) и советует запустить bdu-fstec-mcp refresh, если снимок старше порога (по умолчанию 30 дней). Нет побочных эффектов.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and no destruction. The description adds specific behavior: automatic network check and advisory to refresh if snapshot is older than 30 days, and explicitly states no side effects.
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 informative but somewhat verbose. It effectively conveys purpose and behavior in a few sentences, but could be slightly more concise.
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?
Despite no output schema, the description explains what the tool returns (total records, ID range, snapshot dates). It also covers the automatic check behavior, making it complete for a zero-parameter tool.
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 input schema has no parameters, so the description cannot add meaning beyond schema. Baseline score of 4 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 it returns metadata of the current local BDU snapshot, including total records, ID range, and dates. This distinguishes it from sibling tools that focus on individual vulnerabilities or search.
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 includes context about automatic cache staleness check and advice to run refresh if outdated. However, it does not explicitly compare to siblings or state when to use this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Возвращает полную запись БДУ по идентификатору BDU:YYYY-NNNNN (например, BDU:2024-01187). Включает заголовок, описание, CVSS (оба вектора и балл), уровень опасности ФСТЭК, все связанные CVE, CWE, список уязвимого ПО с вендорами и версиями, дату обнаружения / публикации / последнего обновления, рекомендованное решение, статус эксплойта, статус исправления, источники и URL карточки на bdu.fstec.ru. Read-only. Если идентификатор не найден — сообщение об отсутствии; допускает ввод без префикса BDU: (добавляется автоматически).
| Name | Required | Description | Default |
|---|---|---|---|
| bdu_id | Yes | Идентификатор БДУ. Принимаются форматы `BDU:2024-01234`, `bdu:2024-01234`, или просто `2024-01234`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, idempotentHint. The description adds useful behavioral context: full record content, error handling, auto-prefix addition, and that it's read-only. No contradictions.
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 main action and includes all necessary details without redundancy. Every sentence adds value.
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?
Despite no output schema, the description thoroughly explains what the tool returns (headers, CVSS, severity, CVE, CWE, vulnerable software, dates, solution, exploit status, sources, URL). Also covers error case. Fully complete for a fetch-by-ID tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with description. The description adds value beyond schema: explains format variants (with/without BDU:), examples, and automatic prefix addition. This clarifies parameter meaning further.
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 returns a full BDU record by identifier, with specific format BDU:YYYY-NNNNN, and lists many fields. It distinguishes from siblings like search_bdu_vulnerabilities.
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: read-only, accepts identifier with or without prefix, and returns an error if not found. It implicitly tells when to use this tool (fetch by ID) versus others, but lacks explicit 'use this instead of X' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Поиск уязвимостей в БДУ ФСТЭК (Банк данных угроз безопасности информации России) по полнотекстовому запросу с FTS5-ранжированием (BM25) и опциональным фильтрам. Индекс содержит ~86 000 записей: заголовок, описание, уязвимое ПО, вендор, CVE-идентификаторы. Все результаты read-only (локальная SQLite-копия), без побочных эффектов и сетевых запросов. Пустой query + фильтры → сортировка по CVSS DESC. Возвращает до 100 результатов с идентификатором БДУ, оценкой CVSS, списком ПО, ссылкой на bdu.fstec.ru и сниппетом с подсветкой матча. Применение: поиск аналога CVE в российской БД, подбор уязвимостей по вендору (Astra Linux, ЛК, Positive Technologies и т.д.), фильтрация для моделей угроз 187-ФЗ / ГОСТ Р 57580. Ошибки: недоступность зеркала при первом запуске — сообщение с рекомендацией bdu-fstec-mcp refresh.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Полнотекстовый запрос (русский или английский). Токены автоматически превращаются в префиксный поиск с обрезкой окончания для кириллицы, так что «инъекция» находит «инъекции» и «инъекцией». Примеры: «SQL injection», «Astra Linux kernel», «OpenSSL heap overflow», «CVE-2024-1086». | |
| limit | No | Максимум записей в выдаче, 1–100. Увеличение не замедляет запрос. | |
| min_cvss | No | Минимальная базовая оценка CVSS. Используй 7.0 для «высоких», 9.0 для «критических». Диапазон 0–10. | |
| min_severity | No | Минимальный уровень опасности по ФСТЭК. Если нужны только критические — используй «критический». | |
| year | No | Календарный год обнаружения уязвимости (по идентификатору BDU:YYYY-NNNNN). | |
| vendor | No | Фрагмент имени вендора (case-insensitive подстрока). «Астра» → найдёт всё от РусБИТех-Астра и т.п. | |
| has_exploit | No | true → только уязвимости, для которых ФСТЭК подтвердила существование эксплойта. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly=true. Description adds that results are from a local SQLite copy with no side effects or network requests, and mentions error handling for mirror unavailability. Adds value beyond 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?
Description is comprehensive but verbose, containing multiple use cases and error info in one block. Could be more concise by separating into sections. Still front-loaded with main purpose.
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?
Despite no output schema, the description specifies return fields (BDU ID, CVSS, software list, link, snippet) and result limits. Covers error cases and usage context. Complete for a search tool with 7 params.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and description enriches each parameter with examples, tokenization details, and practical advice (e.g., 'критический' for critical severity). Significantly adds meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches the Russian БДУ ФСТЭК vulnerability database with full-text search and optional filters. It distinguishes from siblings by focusing on general search rather than CVE-specific lookup or stats.
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?
Provides explicit use cases like searching for CVE analogues and filtering for threat models, and mentions empty query behavior. Does not directly compare to sibling tools but gives enough context for appropriate use.
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.
v0.1.0find_bdu_by_cveget_bdu_statsget_bdu_vulnerabilitysearch_bdu_vulnerabilitiesScored across 4 tools
Each tool has a distinct purpose: CVE lookup, metadata retrieval, single record by BDU ID, and full-text search. No overlap in functionality or input parameters.
Tool names mix verbs (find, get, search) and vary in specificity (one uses 'by_cve' suffix). While readable, the pattern is not uniform; singular/plural inconsistency ('vulnerability' vs 'vulnerabilities').
Four tools for a specialized vulnerability database is well-scoped: covers essential queries (CVE, ID, search, stats) without unnecessary bloat.
Primary lookup methods are covered (by CVE, ID, full-text search, stats). Minor gap: no dedicated 'list all' tool, but search with empty query fills this partially. Read-only surface is comprehensive.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server giving Claude AI access to 22+ NYC public-record databases for real estate due diligence
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
MEOK MCP Hardening MCP — automated security red-team for any MCP server. Maps OWASP LLM Top 10