SCA-Triage MCP Server enables AI assistants to perform deep, context-efficient security audits of Java/Spring projects using ripgrep.
Search for multiple custom patterns or built-in vulnerability profiles in one efficient ripgrep pass, grouped by pattern/file with line numbers and snippets.
Analyze project structure by parsing pom.xml / build.gradle(.kts) to extract Java, Spring Boot, Spring Framework versions, dependencies, and config files.
Assess whether vulnerable components are actually used, grouping hits by architectural layer and flagging controller/web usages as [HIGH] for exploitability triage.
Optionally use ast-grep to filter false positives found inside comments or string literals.
Ignore build/service directories and support MCP clients via stdio, SSE, Streamable HTTP, Docker Compose, Open WebUI, and Cline.
Provides security auditing tools for Java/Spring projects, including multi-pattern vulnerability searches, project structure analysis, and usage triage.
Analyzes Spring Boot projects by extracting Spring Boot versions, dependencies, and configuration files for security assessment.
Searches Spring Security configuration patterns such as SecurityFilterChain, permitAll, csrf().disable, and @PreAuthorize to identify insecure settings.
Click on "Deploy 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., "@SCA-Triage MCP Server audit this Spring Boot project for deserialization and SSRF sinks"
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-сервер (Model Context Protocol) для ИИ-ассистентов (Cline, Claude
Desktop, Cursor и др.), выполняющий глубокий аудит безопасности Java/Spring
проектов с помощью утилиты ripgrep (rg).
Сервер предоставляет три инструмента, которые позволяют ИИ находить опасные sink-методы, инвентаризировать зависимости и оценивать реальную эксплуатируемость уязвимых компонентов — не перегружая контекст.
search_multi_patterns — многоуровневый поискИщет список конкретных строк/методов/регулярок или готовый профиль
уязвимостей (например, deserialization) за один эффективный проход через
ripgrep (множественные -e). Результаты группируются по паттерну и файлу с
номерами строк и фрагментами кода.
Аргументы:
patterns (list[str], опционально) — конкретные строки, методы, регурярки.
profile (string, опционально) — профиль безопасности (см. ниже).
path (string, опционально, по умолчанию .) — поддиректория для сужения.
max_matches (int, по умолчанию 500) — лимит суммарных совпадений.
analyze_project_structure — обзор проектаНаходит и разбирает pom.xml / build.gradle(.kts), извлекает версии Java,
Spring Boot, Spring Framework, ключевые зависимости (со scope и версией)
и конфигурационные файлы (application.yml, application.properties).
Аргументы: project_root (string).
analyze_vulnerability_usage — аудит применимостиПроверяет реальную затронутость проекта: ищет импорты/вхождения уязвимых
компонентов и группирует их по архитектурным слоям (Controller, Service,
Repository, Test и т.д.), помечая вхождения в контроллеры как
[HIGH] (потенциально доступные извне).
Аргументы:
components (list[str] или string) — FQCN или ключевые слова.
project_root (string, опционально, по умолчанию .).
max_matches (int, опционально).
Отсеивание ложных срабатываний. Если установлен ast-grep, совпадения,
найденные ripgrep внутри комментариев/строковых литералов, отбрасываются
перед финальной категоризацией, что повышает точность триажа.
Related MCP server: Security-Use MCP Server
search_multi_patterns)Профиль | Что ищет |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Объединение всех профилей (широкий скан) |
Профили можно комбинировать с явным списком patterns — они объединяются и
дедуплицируются.
ripgrepОС | Команда |
macOS (Homebrew) |
|
Debian / Ubuntu / Kali |
|
Fedora |
|
Arch |
|
Windows (Chocolatey) |
|
Проверка:
rg --version # e.g. ripgrep 15.2.0ast-grep для отсеивания ложных срабатыванийast-grep (бинарник sg) используется в analyze_vulnerability_usage для
отбрасывания совпадений, найденных ripgrep внутри комментариев и строковых
литералов — это снижает число ложных срабатываний. Это опциональный
бинарник, который ставится так же, как ripgrep. Без него сервер работает
как раньше, полагаясь только на ripgrep.
ОС / менеджер | Команда |
macOS (Homebrew) |
|
Linux (cargo) |
|
Linux / Windows / macOS (npm) |
|
Nix |
|
Скачать бинарник вручную | см. GitHub Releases |
Проверка:
ast-grep --version # или: sg --versionВажно (Linux). В Linux команда
sgуже занята системной утилитойsetgroupsиз пакетаutil-linux(/usr/bin/sg). Поэтому на Linux рекомендуется использовать полное имяast-grep, либо убедиться, что каталог с ast-grep-бинарником (например~/.cargo/bin) идёт раньше/usr/binвPATH. Сервер умеет распознавать системныйsgи в этом случае корректно откатывается к ripgrep. В Docker-образе ast-grep кладётся в/usr/local/bin(перекрывает/usr/bin/sg).
Требуется Python 3.10+.
cd sca-triage-mcp
# (рекомендуется) изолированное окружение
python3 -m venv .venv
source .venv/bin/activate # Windows: .venv\Scripts\activate
pip install -r requirements.txt # или: pip install mcpВажно. На некоторых дистрибутивах (Kali, Debian 12+) системный Python
защищён PEP 668. Используйте venv (как выше) или флаг
--break-system-packages.
python server.py # запуск в режиме stdio (MCP-клиенты подключаются сами)Начиная с MCP SDK 2.x сервер поддерживает нативный HTTP-транспорт
(Streamable HTTP) прямо из server.py — отдельный REST-мост больше не нужен.
Open WebUI подключается как к обычному MCP-серверу по HTTP.
python server.py --transport streamable-http --port 8000
# слушает на http://127.0.0.1:8000, endpoint: /mcpДля доступа извне (например, если Open WebUI запущен в Docker):
python server.py --transport streamable-http --host 0.0.0.0 --port 8000В Open WebUI добавьте сервер (User settings → Tools, или раздел MCP-серверов
конфигурации) с URL http://<host>:8000/mcp (тип — MCP поверх HTTP/SSE).
Поддерживаются как Streamable HTTP (/mcp), так и legacy SSE.
Дополнительные флаги:
Флаг | Назначение |
| транспорт (по умолчанию |
| адрес для HTTP-транспортов (по умолчанию |
| порт (по умолчанию |
| путь endpoint'а (по умолчанию |
| отвечать JSON вместо SSE (без request back-channel) |
| отключить управление сессиями |
python server.py --transport sse --port 8000
# endpoint: /sse (сообщения — /messages/)curl -X POST http://127.0.0.1:8000/mcp \
-H 'Content-Type: application/json' \
-H 'Accept: application/json, text/event-stream' \
-d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-03-26","capabilities":{},"clientInfo":{"name":"curl","version":"1"}}}'Ответ содержит mcp-session-id, который нужно передавать в заголовке
mcp-session-id для последующих запросов (tools/list, tools/call).
Замечание о
webui_proxy.py. Скриптwebui_proxy.py(чистый REST-мост на stdlib + OpenAPI-схема) остался в репозитории как альтернатива для сред, где нужен именно HTTP/REST без SSE. При использовании нативного транспорта он не требуется.
Безопасность. HTTP-транспорт не выполняет аутентификации и открывает аудит файловой системы сервера. Запускайте его на локальном хосте (
127.0.0.1) либо за обратным прокси с авторизацией.
Рецепт «под ключ» для Open WebUI — docker-compose.yml поднимает наш сервер в
режиме streamable-http и (опционально) сам Open WebUI в общей docker-сети.
docker compose up -d --buildСервис | Что делает |
| наш MCP-сервер (Streamable HTTP, |
| UI на |
Проекты монтируются из хостового каталога ${SCA_PROJECTS_DIR:-~/projects}
в /projects:ro внутри контейнера. В запросах передавайте
project_root="/projects/<имя-подкаталога>".
Подключение в Open WebUI:
Тип — MCP (Streamable HTTP).
URL — http://sca-triage:8000/mcp (по имени сервиса внутри docker-сети).
Если пробросили порт на хост — http://localhost:8000/mcp.
Параметры запуска задаются переменными окружения: SCA_TRANSPORT,
SCA_HOST, SCA_PORT, SCA_MCP_PATH (алиас SCA_STREAMABLE_HTTP_PATH).
В Cline нажмите кнопку MCP Servers в правом верхнем углу и добавьте новый сервер, либо отредактируйте файл конфигурации вручную.
Файл cline_mcp_settings.json обычно лежит в одном из мест:
~/.cline/cline_mcp_settings.json
~/.config/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json
Добавьте следующую секцию (укажите абсолютные пути):
{
"mcpServers": {
"sca-triage": {
"command": "/absolute/path/to/sca-triage-mcp/.venv/bin/python",
"args": [
"/absolute/path/to/sca-triage-mcp/server.py"
],
"env": {},
"disabled": false,
"alwaysAllow": [
"search_multi_patterns",
"analyze_project_structure",
"analyze_vulnerability_usage"
]
}
}
}Windows — используйте путь к
python.exeвнутриvenv:C:\\path\\to\\sca-triage-mcp\\.venv\\Scripts\\python.exe
Перезапустите Cline / переподключите сервер. В списке инструментов должны
появиться search_multi_patterns, analyze_project_structure и
analyze_vulnerability_usage.
Просканируй проект в /home/user/my-api на уязвимости десериализации
(профиль deserialization) и покажи все опасные sink-методы.search_multi_patterns(profile="deserialization", path="/home/user/my-api")Проанализируй структуру проекта /home/user/my-api: версии Java, Spring Boot,
ключевые зависимости и конфиги.analyze_project_structure(project_root="/home/user/my-api")Проверь, реально ли используется XStream (CVE-2021-21341) в проекте, и насколько
он доступен извне.analyze_vulnerability_usage(
components=["com.thoughtworks.xstream.XStream"],
project_root="/home/user/my-api"
)Результат покажет, в каких слоях встречается компонент, и пометит [HIGH],
если он используется в Controller/Web/REST слоях (доступен извне), или
[LOW] — если только внутри служб/тестов.
Найди вхождения Runtime.getRuntime().exec, ProcessBuilder и Class.forName.search_multi_patterns(
patterns=["Runtime.getRuntime().exec", "ProcessBuilder", "Class.forName"],
path="/home/user/my-api"
)sca-triage-mcp/
├── server.py # главный MCP-сервер (3 инструмента)
├── profiles.py # профили и наборы паттернов уязвимостей
├── rg_runner.py # обёртка над ripgrep (subprocess + парсинг --json)
├── project_analyzer.py # разбор pom.xml / build.gradle и конфигов
├── webui_proxy.py # HTTP/REST мост для Open WebUI (без зависимостей)
├── requirements.txt # зависимости (mcp)
├── pyproject.toml # метаданные пакета
├── cline_mcp_settings.example.json # пример конфигурации для Cline
└── README.md # эта документацияОдин проход rg. Все паттерны передаются в один вызов ripgrep через
несколько -e (для литералов — --fixed-strings, для регулярных — обычный
режим). Это в разы быстрее, чем последовательные запуски.
Машиночитаемый вывод. Используется rg --json с парсингом событий
match, поэтому не нужно разбирать хрупкий текстовый вывод.
Игнорирование служебных каталогов. target/, build/, .gradle/,
.mvn/, .idea/, bin/, .git/, node_modules/, а также бинарные
артефакты (*.class, *.jar, *.zip, …) исключаются из поиска.
Компактный вывод. Результаты группируются по паттерну → файлу → строке
(с лимитами max_matches и обрезкой длинных строк), чтобы не перегружать
контекст ИИ.
Понятные ошибки. При отсутствии rg сервер возвращает инструкцию по
установке; неверный профиль/путь — внятное сообщение с перечнем доступных
профилей.
Отсеивание ложных срабатываний через ast-grep. Используется в
analyze_vulnerability_usage: для каждого файла, где ripgrep нашёл вхождение,
дополнительно запускается sg --lang java --pattern ... --json (строго
файл-за-файлом, с таймаутом 2 с) и совпадения внутри комментариев/строковых
литералов отбрасываются. Если ast-grep недоступен или превысил таймаут,
сервер корректно откатывается к ripgrep (без падений).
Классификация слоёв по коду. Слой файла определяется не только по пути, но
и по содержимому: если файл содержит Spring-аннотации веб-слоя
(@RestController, @Controller, @RequestMapping, @GetMapping,
@PostMapping, @PutMapping, @DeleteMapping, а также Spring Security
@PreAuthorize/@Secured/@PostAuthorize и GraphQL/WebFlux
@QueryMapping/@SchemaMapping), он принудительно относится к
controller и получает флаг [HIGH] — даже если в пути нет слова controller
(например, корневой App.java). Файлы читаются безопасно (utf-8,
errors="replace", лимит размера) с LRU-кэшем по (путь, mtime, размер).
Инструмент предназначен для легитимного аудита безопасности собственных или авторизованных проектов. Использование для несанкционированного тестирования запрещено и регулируется применимым законодательством.
Analyze a Java/Spring project: locate pom.xml / build.gradle(.kts), extract Java, Spring Boot and Spring Framework versions, list key dependencies with versions/scopes, and surface configuration files (application.yml / application.properties).
| Name | Required | Description | Default |
|---|---|---|---|
| project_root | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It does reveal the concrete behavior (locate build files, extract versions, list dependencies, surface config files), which implies a read-only inspection pass, but it never states that it is non-mutating, what happens on a non-Java project, or how failures are reported.
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?
A single front-loaded sentence that leads with the verb and scope before listing outputs; every clause adds a concrete artifact. It is dense but nothing is wasted, though the run-on listing makes it slightly harder to scan than a short bulleted form.
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?
With no output schema, the description must convey return content, and it does so by enumerating exactly what is extracted. The remaining gap is input semantics (project_root) and edge-case behavior for non-Java projects, which keeps it short of full completeness.
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?
There is one required parameter, project_root, with 0% schema description coverage, and the description never mentions it. It doesn't clarify whether the value is an absolute path, a relative path, or a project directory containing the build file, leaving the only input ambiguous.
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 pairs a specific verb ("Analyze") with a specific resource ("Java/Spring project") and enumerates the exact artifacts it inspects and extracts: pom.xml/build.gradle(.kts), Java/Spring Boot/Spring Framework versions, dependencies with scopes, and config files. That level of specificity clearly separates it from search_multi_patterns and analyze_vulnerability_usage, though it never names those siblings explicitly.
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?
Usage is implied by the scope: the tool is for Java/Spring projects and is the entry point for understanding build setup. There is no explicit "use this when..." statement, no exclusion for non-Java projects, and no routing guidance to the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Assess whether vulnerable components are actually used in a project. For each component, search imports/usages (FQCN or artifact keywords), group hits by architectural layer (controller/service/test/...), and flag externally-reachable usages to help estimate real exploitability. Layers are resolved from file paths AND file contents: any file declaring @RestController/@Controller/@RequestMapping/@GetMapping/@PostMapping/@PutMapping/@DeleteMapping is treated as a controller ([HIGH]) even when its path has no web/controller token. project_root must be an absolute path to the target project.
| Name | Required | Description | Default |
|---|---|---|---|
| components | Yes | ||
| max_matches | No | ||
| project_root | No | . |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the internal procedure (search imports/usages using FQCN or artifact keywords, group by layer, flag externally reachable hits), the layer-resolution heuristic including annotation-based controller detection marked [HIGH], and the absolute-path requirement. It stops short of stating read-only safety, performance characteristics, or the shape of the returned grouping.
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?
Front-loaded with the purpose, then the per-component procedure, then the layer heuristic caveat. Dense but every sentence carries information; the detailed @RestController/@Controller/@GetMapping enumeration is the only part that runs long relative to its 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?
No output schema exists, and the description compensates by explaining that results are grouped by layer and flagged for external reachability with [HIGH] markers, giving an agent a usable mental model of the return value. The unmentioned max_matches cap and the lack of any hint about result volume are the remaining 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 description coverage is 0% across 3 parameters, so the description must compensate. It clarifies 'components' (FQCN or artifact keywords) and imposes an absolute-path constraint on project_root, but max_matches (default 800) is never mentioned, leaving one parameter entirely undocumented.
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?
States a specific verb+resource: assesses whether vulnerable components are actually used, by searching imports/usages and grouping hits by architectural layer. The scope is narrow enough that an agent can distinguish it from generic siblings like search_multi_patterns without opening a schema.
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 purpose sentence implies when to use it (exploitability triage of known-vulnerable components), but there is no explicit when-not guidance and no mention of the sibling alternatives such as search_multi_patterns for raw pattern hunting. Usage must be inferred from context rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a single, efficient ripgrep pass over a Java/Spring project for a list of patterns or a named security profile (e.g. 'deserialization'). Returns matches grouped by pattern and file with line numbers and code snippets. Build/service dirs (target/, build/, .gradle/, .mvn/, .idea/, bin/) are always ignored.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | . | |
| profile | No | ||
| patterns | No | ||
| max_matches | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does well: it discloses the single-pass efficiency model, the grouped return shape with line numbers and snippets, and the always-ignored build directories. It stops short of stating read-only semantics explicitly or covering error/limit behavior, but the core operational traits are visible.
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?
Three tight sentences, front-loaded with the action and scope, followed by return behavior and the directory-ignore rule. There is no filler, and each sentence adds distinct information.
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?
Without an output schema or annotations, the description usefully explains the return format and ignored directories. However, it leaves significant gaps around path scoping, max_matches behavior, supported profile values, and whether patterns are regex or literal, so an agent still lacks some information needed to invoke it optimally.
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 0%, so the description must compensate for all four parameters. It clarifies that 'patterns' is a list and that 'profile' is a named security profile with an example, but it never mentions 'path' or 'max_matches', leaving half the parameters undocumented in both schema and prose.
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 states a specific verb and resource: run a single ripgrep pass over a Java/Spring project for patterns or a named security profile. It is clear what the tool does, but it does not explicitly distinguish itself from siblings like analyze_vulnerability_usage, leaving some ambiguity about when raw pattern search is preferable to vulnerability analysis.
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 naming inputs ('a list of patterns or a named security profile'), but it provides no explicit when-to-use guidance, no exclusions, and no comparison to the available sibling tools. The agent must infer the selection context.
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.0analyze_project_structureanalyze_vulnerability_usagesearch_multi_patternsScored across 3 tools
Each tool has a distinct role: raw pattern search, project metadata extraction, and vulnerability-usage assessment. There is mild overlap between search_multi_patterns and analyze_vulnerability_usage, since the latter performs import/usage searches internally, but the descriptions make the boundary clear (generic grep vs. component-level exploitability triage).
All three names follow a consistent snake_case verb_noun pattern (search_multi_patterns, analyze_project_structure, analyze_vulnerability_usage). Two share the 'analyze_' prefix on distinct objects, which reads predictably.
Three well-scoped, non-trivial tools fit a focused SCA triage workflow without bloat. It is on the lean side, but each tool earns its place rather than being a thin single-purpose wrapper.
The surface covers search, build-file/dependency discovery, and usage-based exploitability assessment, but there is no way to match discovered dependencies against a vulnerability database/CVE feed, nor to emit a structured triage report or read an arbitrary file. An agent would hit dead ends when the actual CVE-to-dependency correlation is needed.
Zero-config MCP security scanner for AI-generated apps. 25K+ vulnerability patterns.
Security scanner for AI-written code: SAST, secrets, dependencies, IaC, containers and DAST.
Deep security scans of repos you own from your editor: dependency CVEs, SAST, git-history secrets.
Threat modeling, code/cloud/pipeline scanning, shadow-AI discovery, compliance checks and fixes.