Skip to main content
Glama
deenesjakoruzh
12211725-star

Hospital WAF MCP

by 12211725-star
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Hybrid

MCP-сервер системы управления WAF для больниц

Python License MCP

English | 中文

MCP-сервер межсетевого экрана веб-приложений (WAF) для больниц, предоставляющий ИИ-ассистентам возможности обнаружения WAF-правил. Поддерживает обнаружение SQL-инъекций, XSS, инъекций команд, обхода путей, а также содержит встроенные специализированные правила для больничных сценариев.

✨ Функциональные особенности

  • 🔒 Обнаружение SQL-инъекций — распознавание распространенных паттернов атак SQLi (UNION-инъекции, слепые булевы инъекции, слепые временные инъекции, инъекции на основе ошибок)

  • 🎯 Обнаружение XSS-атак — обнаружение отраженных/хранимых XSS (теги script, обработчики событий, JS URI)

  • ⚡ Обнаружение инъекций команд — распознавание атак на выполнение системных команд Unix/Windows

  • 📁 Обнаружение обхода путей — обнаружение атак типа «обход каталогов» и обходов с использованием кодирования

  • 🏥 Специализированные больничные правила — охват распространенных паттернов уязвимостей в HIS/PACS/LIS/RIS

  • 🔄 Горячая перезагрузка правил — нет необходимости перезапускать службу после изменения правил

  • 🧪 Самотестирование — встроенный движок для проверки возможностей с помощью примеров атак

  • ⚡ Легковесность — чистый движок регулярных выражений на Python, без внешних зависимостей

Related MCP server: Smart EHR MCP Server

🚀 Быстрый старт

1. Установка

# 克隆仓库
git clone https://github.com/12211725-star/hospital-waf-mcp.git
cd hospital-waf-mcp

# 安装依赖
pip install -r requirements-mcp.txt

2. Интеграция в MCP-клиент

Добавьте в файл конфигурации MCP-клиента:

{
  "mcpServers": {
    "hospital-waf-mcp": {
      "command": "python",
      "args": ["-m", "waf_mcp"],
      "env": {
        "WAF_MCP_LOG_LEVEL": "INFO"
      }
    }
  }
}

Использование Docker

{
  "mcpServers": {
    "hospital-waf-mcp": {
      "command": "docker",
      "args": ["run", "--rm", "-i", "hospital-waf-mcp"],
      "env": {
        "WAF_MCP_LOG_LEVEL": "INFO"
      }
    }
  }
}

Удаленное развертывание через Streamable HTTP

export WAF_MCP_TRANSPORT=http
export WAF_MCP_HOST=0.0.0.0
export WAF_MCP_PORT=8000
python -m waf_mcp

Эндпоинт MCP: http://<host>:8000/mcp Проверка работоспособности: GET /health

📖 Использование

Обнаружение SQL-инъекций

В Claude / Cursor / других MCP-клиентах:

请帮我检测这个请求是否有安全问题：
URL: https://example.com/search?q=1' OR '1'='1

ИИ вызовет инструмент waf_check_request и вернет:

[
  {
    "rule_id": "sqli-001",
    "category": "SQL Injection",
    "severity": "high",
    "matched": "1' OR '1'='1",
    "description": "检测到 SQL 注入特征"
  }
]

Обнаружение XSS-атак

检测这个 POST 请求的 body：
<script>alert('xss')</script>

Просмотр статистики правил

当前 WAF 引擎加载了多少规则？

🎯 Руководство по промптам

Сценарии оценки безопасности

我需要对一个请求进行安全检测，
URL 是 https://hospital.example.com/api/patient?id=1 UNION SELECT，
请帮我分析是否存在攻击特征。

Сценарии обслуживания правил

我刚刚更新了 WAF 规则文件，
请帮我重新加载规则并确认加载成功。

Сценарии проверки движка

请运行 WAF 引擎自检测试，
确认 SQL 注入和 XSS 检测功能正常。

Сценарии анализа логов

帮我检测这个可疑请求的完整参数：
URL: https://api.hospital.com/query
Method: POST
Body: {"filter": "'; DROP TABLE users; --"}
Headers: {"Content-Type": "application/json"}

🛠️ Список инструментов

Инструмент

Описание

Параметры

waf_check_request

Проверка запроса WAF

url: URL запроса, method: HTTP-метод, headers: заголовки запроса, body: тело запроса, cookies: Cookie

waf_rule_stats

Статистика правил

Нет параметров

waf_reload_rules

Горячая перезагрузка правил

Нет параметров

waf_run_self_tests

Самотестирование

Нет параметров

📖 Переменные окружения

Переменная

Описание

Значение по умолчанию

WAF_MCP_TRANSPORT

Протокол передачи (stdio/http/sse)

stdio

WAF_MCP_HOST

Адрес прослушивания HTTP

127.0.0.1

WAF_MCP_PORT

Порт прослушивания HTTP

8000

WAF_MCP_LOG_LEVEL

Уровень логирования

INFO

WAF_RULES_FILE

Путь к файлу правил

waf_mcp/rules/waf_rules.mcp.json

📋 Возможности обнаружения

Обнаружение SQL-инъекций

Тип риска

Уровень серьезности

Условие обнаружения

UNION-инъекция

High

UNION SELECT и т.д.

Слепая булева инъекция

High

Булевы выражения AND/OR

Слепая временная инъекция

High

SLEEP/BENCHMARK и т.д.

Инъекция на основе ошибок

High

EXTRACTVALUE/UPDATEXML и т.д.

Стековые запросы

High

Несколько SQL-запросов, разделенных точкой с запятой

Обнаружение XSS

Тип риска

Уровень серьезности

Условие обнаружения

Тег script

High

Инъекция тега <script>

Обработчик событий

High

onclick/onerror и т.д.

JavaScript URI

Medium

Протокол javascript:

SVG-инъекция

Medium

<svg onload> и т.д.

Обнаружение инъекций команд

Тип риска

Уровень серьезности

Условие обнаружения

Инъекция команд Unix

Critical

;

& $ ` конвейерные соединения

Инъекция команд Windows

Critical

&

^ соединения команд

Опасные команды

Critical

cat/ls/wget/curl и т.д.

Обнаружение обхода путей

Тип риска

Уровень серьезности

Условие обнаружения

Обход каталогов

High

../ обход пути

Обход через URL-кодирование

High

%2e%2e/ и т.д.

Обход через двойное кодирование

High

%252e%252e/ и т.д.

Специализированные больничные сценарии

Тип системы

Ключевые слова

HIS

Больничная информационная система, амбулатория, стационар, регистратура

PACS

Изображения, DICOM, радиология

LIS

Анализы, лаборатория, биохимия

RIS

Радиологическая информационная система, диагностика изображений

EMR

Электронная медицинская карта, записи о ходе лечения

🔧 Разработка

git clone https://github.com/12211725-star/hospital-waf-mcp.git
cd hospital-waf-mcp
pip install -e .

# 运行测试
python scripts/run_functional_tests.py

# 本地运行
python -m waf_mcp

📁 Структура проекта

hospital-waf-mcp/
├── waf_mcp/                  # MCP 服务包
│   ├── __init__.py
│   ├── __main__.py
│   ├── config.py
│   ├── server.py
│   ├── version.py
│   ├── waf_engine.py
│   └── rules/
│       └── waf_rules.mcp.json
├── scripts/                  # 脚本工具
├── modelscope.yaml           # 魔搭配置
├── mcp.json                  # MCP 元数据
├── mcp_config.json           # MCP 客户端配置
├── pyproject.toml            # Python 项目配置
└── README.md

📄 Лицензия

MIT License

🔗 Ссылки

Available Tools

4 tools
waf_check_requestB

对 HTTP 请求做 WAF 规则检测，返回命中的告警列表（无命中则为空列表）。url 建议包含完整查询串。

ParametersJSON Schema
NameRequiredDescriptionDefault
urlNo
methodNoGET
headersNo
bodyNo
cookiesNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the full burden. It discloses that the tool returns an alert list (or empty list) and implies it is a read-only check. However, it does not mention side effects, authentication needs, or rate limits. The behavioral coverage is adequate but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very short (two sentences) and front-loaded with the main purpose. It contains no unnecessary words. However, it could be improved by structuring parameter details more clearly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 5 parameters, no schema descriptions, no annotations, and an output schema (not detailed), the description is incomplete for an AI agent to use correctly. It lacks parameter explanations and does not cover how to structure requests. The url tip is helpful but insufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, yet the description only elaborates on one parameter: 'url 建议包含完整查询串'. It does not explain the meaning or expected format of method, headers, body, or cookies. The description adds little beyond the schema property names, leaving the agent to infer common HTTP semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's action: '对 HTTP 请求做 WAF 规则检测' (perform WAF rule detection on HTTP request) and specifies the output: '返回命中的告警列表' (return list of matching alerts). It distinguishes itself from sibling tools (waf_reload_rules, waf_rule_stats, waf_run_self_tests) which focus on rule management.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes a usage tip: 'url 建议包含完整查询串' (url is recommended to include full query string), but does not explicitly state when to use this tool vs alternatives or provide any exclusions. The context implies it is for checking a single request, but guidance is minimal.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

waf_reload_rulesA

重新从磁盘加载 WAF_RULES_FILE（或默认 rules/waf_rules.mcp.json）并编译。用于修改规则文件后无需重启 MCP。

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.3/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It discloses the reload and compile actions but lacks detail on potential side effects (e.g., whether it is safe to call mid-operation, impacts on in-flight requests). The presence of an output schema suggests return values are documented elsewhere.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences in Chinese, efficiently stating the action and purpose with no superfluous words. It is front-loaded and to the point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of the tool (no parameters, output schema exists), the description covers what it does, the file involved, and the reason to use it. It is sufficiently complete for an agent to select and invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so schema coverage is 100%. The description adds no parameter information, but the baseline for no parameters is 4. No additional semantics needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's action: reload the WAF rules file from disk and compile, with the specific purpose of avoiding MCP restart after rule modifications. It distinguishes itself from sibling tools (check, stats, self-tests) by focusing on reloading.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly indicates when to use: after modifying rule files. However, it does not provide exclusions or mention alternatives, but the context is clear given sibling tool purposes.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

waf_rule_statsA

返回当前已加载规则的统计：含 rules_file、compiled_rules、compile_failed、compile_errors（截断）及分类计数。

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, but the description mentions that compile_errors are truncated, which is a useful behavioral detail. However, it lacks further info on side effects or prerequisites.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence is front-loaded with purpose and lists key fields, no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters and presence of output schema, the description adequately covers the tool's purpose and notes the truncation of compile_errors.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so schema coverage is 100%. The description does not need to add parameter info; baseline for 0 params is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it returns statistics of currently loaded rules and lists specific fields (rules_file, compiled_rules, etc.), distinguishing it from sibling tools like waf_check_request or waf_reload_rules.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives; it only describes what it does without context for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

waf_run_self_testsA

运行内置 SQLi/XSS/命令注入/路径遍历样例，用于快速验证引擎是否检出攻击。

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the transparency burden. It states the action and purpose but omits details on return format, side effects (e.g., alerts, logs), or whether it alters state. Neither destructive nor read-only hint provided.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, efficient, and front-loaded with the verb '运行'. Every word earns its place with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters and an existing output schema, the description covers the core purpose. It could briefly indicate output (e.g., pass/fail), but remains sufficiently complete for a test tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has zero parameters, so there is nothing to explain. Baseline for 0 params is 4 per guidelines.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool runs built-in attack samples (SQLi, XSS, etc.) to verify engine detection, with a specific verb and resource. It distinguishes from sibling tools like waf_check_request (single request check) and waf_reload_rules (rules reload).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase '快速验证' implies quick testing, but lacks explicit guidance on when to use vs alternatives or any exclusions. No when-not-to-use or prerequisites mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 4 tool updatesv1.0.0
    • First observedwaf_check_request
    • First observedwaf_reload_rules
    • First observedwaf_rule_stats
    • First observedwaf_run_self_tests
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4/5.0

Scored across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: checking requests, reloading rules, viewing statistics, and running self-tests. No two tools overlap in functionality.

Naming Consistency5/5

All tool names follow a consistent 'waf_verb_noun' pattern using snake_case, with clear and descriptive verbs (check, reload, rule_stats, run_self_tests).

Tool Count5/5

With 4 tools, the set is well-scoped for a WAF server, covering essential operations without being unnecessarily large or too minimal.

Completeness4/5

The tools cover the main use cases (request checking, rule management, statistics, testing). Minor gaps exist, such as no tool for individually viewing or modifying specific rules, but core workflows are supported.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers