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., "@hospital-vuln-scanner-mcp Quickly scan 192.168.1.100 for vulnerabilities"
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.
English | 中文
医院漏洞扫描 MCP 服务器，为 AI 助手提供医疗信息系统真实安全扫描能力。支持端口扫描、漏洞检测、医疗系统识别、合规报告生成等 14 个工具。
🔍 真实漏洞扫描 — 支持 quick/standard/deep 三种模式，自动调用 nmap/nuclei 或 Python 回退
🏥 医疗系统识别 — 自动识别 HIS/PACS/LIS/RIS/EMR 等医疗信息系统
🌐 网络发现 — 网络资产发现和端口扫描
📊 报告生成 — 支持 PDF/HTML/JSON/CSV 格式报告
🔐 合规检查 — 符合等保 2.0 要求
⚡ 零依赖运行 — 无需安装 nmap/nuclei，Python 原生扫描也能用
Related MCP server: security-framework-mcp
# 使用 uvx（推荐）
uvx hospital-vuln-mcp
# 或使用 pip
pip install hospital-vuln-mcp在 MCP 客户端配置文件中添加：
{
"mcpServers": {
"hospital-vuln-mcp": {
"command": "uvx",
"args": ["hospital-vuln-mcp"],
"env": {
"HOSPITAL_VULN_MCP_LOG_LEVEL": "INFO"
}
}
}
}{
"mcpServers": {
"hospital-vuln-mcp": {
"command": "docker",
"args": ["run", "--rm", "-i", "hospital-vuln-mcp"],
"env": {
"HOSPITAL_VULN_MCP_LOG_LEVEL": "INFO"
}
}
}
}hospital-vuln-mcp --transport http --host 0.0.0.0 --port 8000# 安装 nmap（端口扫描增强）
# macOS
brew install nmap
# Ubuntu/Debian
sudo apt install nmap
# Windows
choco install nmap
# 安装 nuclei（漏洞扫描增强）
go install -v github.com/projectdiscovery/nuclei/v3/cmd/nuclei@latest💡 提示：不安装也能用，会自动降级到 Python 原生扫描。
在 Claude / Cursor / 其他 MCP 客户端中：
请帮我扫描 192.168.1.100 这台服务器AI 会调用 start_scan 工具，返回：
{
"task_id": "abc123",
"status": "completed",
"open_ports": [
{"port": 22, "service": "SSH"},
{"port": 3306, "service": "MySQL"},
{"port": 8080, "service": "HTTP-Alt"}
],
"vulnerabilities": [
{"title": "MySQL 服务暴露", "severity": "medium"}
]
}对 10.0.0.50 进行深度扫描快速扫描 www.example.com扫描 192.168.1.1 的 22,80,443,3306 端口识别 192.168.1.100 运行的医疗系统类型发现 192.168.1.0/24 网段的活跃主机我需要对一台新上线的 HIS 系统进行安全评估，
目标 IP 是 192.168.1.200，请帮我进行标准扫描并生成报告。请帮我巡检内网 10.0.0.0/24 网段的医疗系统安全状况。我需要为等保测评准备安全扫描报告，
请对目标系统进行深度扫描并导出合规报告。发现 192.168.1.50 可能有安全风险，
请立即进行快速扫描帮我排查问题。帮我盘点医院网络中的所有医疗信息系统，
识别系统类型和开放端口。工具 | 描述 | 参数 |
| 启动漏洞扫描 |
|
| 查询扫描状态 |
|
| 列出扫描历史 |
|
| 取消扫描 |
|
工具 | 描述 | 参数 |
| 列出漏洞 |
|
| 获取漏洞详情 |
|
| 更新漏洞状态 |
|
工具 | 描述 | 参数 |
| 网络发现 |
|
| 端口扫描 |
|
| 医疗系统识别 |
|
工具 | 描述 | 参数 |
| 生成报告 |
|
| 列出报告 |
|
工具 | 描述 |
| 漏洞统计分析 |
| 系统状态（含 nmap/nuclei 可用性） |
start_scan()
│
├── 检测 nmap → 有则用于端口扫描
│ └── 无 → Python socket 多线程扫描
│
├── 检测 nuclei → 有则用于漏洞扫描
│ └── 无 → 内置规则检测常见漏洞
│
└── 返回结果即使没有 nuclei，也能检测以下常见风险：
风险类型 | 严重程度 | 检测条件 |
MySQL 服务暴露 | Medium | 3306 端口开放 |
Redis 未授权访问 | High | 6379 端口开放 |
MongoDB 未授权访问 | High | 27017 端口开放 |
RDP 远程桌面暴露 | High | 3389 端口开放 |
SMBv1 协议风险 | High | 445 端口开放 |
PHPInfo 信息泄露 | Medium | HTTP 响应含 phpinfo |
目录遍历风险 | Medium | HTTP 响应含 "Index of" |
通过 HTTP Banner 和页面特征识别：
系统类型 | 关键词 |
HIS | 医院信息系统、门诊、住院、挂号、处方 |
PACS | 影像、DICOM、放射、PACS |
LIS | 检验、实验室、生化、免疫 |
RIS | 放射信息系统、影像诊断 |
EMR | 电子病历、病程记录 |
变量 | 说明 | 默认值 |
| 日志级别 |
|
| 扫描超时（秒） |
|
| 最大并发扫描数 |
|
git clone https://github.com/12211725-star/hospital-vuln-mcp.git
cd hospital-vuln-mcp
pip install -e ".[dev]"
# 运行测试
pytest
# 本地运行
python -m hospital_vuln_mcp🔧 API 改进: scan_host_ports 的 ports 参数从字符串改为数组
🔧 API 改进: identify_medical_systems 新增可选 ports 参数
🐛 修复 AI 助手调用时参数名不匹配导致的验证错误
🐛 关键修复: nmap/nuclei 路径检测改为延迟检测（每次扫描时检测）
🐛 修复 nmap/nuclei 路径检测，新增多路径搜索
🔧 对齐魔搭 MCP 开发规范
📝 新增 .env.example 文件
🐛 改回 stdio 协议（与魔搭官方一致）
🐛 README 添加 env 字段
🐛 mcp.json name 与 PyPI 包名一致
🐛 修复魔搭 README 格式
🐛 修复 README 中 PyPI 包名错误
🔧 GitHub 仓库名改为 hospital-vuln-scanner-mcp
📝 更新 README，添加使用方法和提示词指南
📝 添加扫描引擎说明和内置规则文档
📝 添加医疗系统指纹识别说明
✨ 新增真实扫描能力（nmap/nuclei 自动检测）
✨ 新增 Python 原生端口扫描回退
✨ 新增医疗系统指纹识别
✨ 新增内置漏洞检测规则
🐛 修复扫描任务永远卡在 running 的问题
🎉 初始版本
✨ 14 个 MCP 工具
✨ 魔搭 MCP 广场上架
MIT License
取消正在运行的扫描任务
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | 要取消的扫描任务ID |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only states 'cancel' without disclosing side effects (e.g., whether partial results are discarded), authorization needs, or idempotency. The description is too minimal for a mutation tool.
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 a single concise sentence that is front-loaded and to the point. However, it could be slightly expanded to include key usage hints without becoming verbose.
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 simplicity and the presence of an output schema (not shown but indicated true), the description is minimally adequate. However, it lacks usage context and does not explain the cancellation process or return behavior.
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 has 100% coverage (task_id described as '要取消的扫描任务ID'), so the description adds no additional meaning. Baseline 3 is appropriate since the schema already documents the parameter.
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 action: '取消正在运行的扫描任务' (Cancel a running scan task). It uses a specific verb 'cancel' and resource 'scan task', distinguishing it from siblings like start_scan or get_scan_status.
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?
No usage guidelines are provided. The description does not indicate when to use this tool vs. alternatives (e.g., checking scan status first with get_scan_status), nor does it specify prerequisites or when cancellation might fail.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
网络发现 - 扫描本地网络设备和医疗系统
发现指定网段内的网络设备，识别开放端口和医疗系统类型。
| Name | Required | Description | Default |
|---|---|---|---|
| cidr | No | 目标网段，如：192.168.1.0/24 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions 'scan' which implies active network probing, but does not explicitly disclose potential network impact, permission requirements, or rate limits. With no annotations, more detail would improve 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 concise with two sentences and a markdown header. It is front-loaded and avoids unnecessary detail, though the header adds minimal overhead.
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 simple input (single CIDR param) and the presence of an output schema, the description sufficiently explains the tool's basic function. However, it could mention what types of medical systems are identified or how comprehensive the port scan is.
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% as the single parameter 'cidr' has a description in the schema. The tool description adds no extra meaning beyond that, so 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 that the tool scans network devices and medical systems, identifying open ports and system types. However, it does not differentiate from the sibling tool 'identify_medical_systems', which overlaps in functionality.
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?
No guidance is provided on when to use this tool versus alternatives like 'start_scan', 'scan_host_ports', or 'identify_medical_systems'. The description only states what it does.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
生成扫描报告
根据扫描结果生成专业的安全扫描报告。
vulnerability: 漏洞详情报告
compliance: 合规性检查报告
executive: 管理层摘要报告
pdf: PDF文档（推荐）
html: 网页格式
json: JSON数据
csv: CSV表格
| Name | Required | Description | Default |
|---|---|---|---|
| scan_id | Yes | 扫描任务ID | |
| report_type | No | 报告类型: vulnerability/compliance/executive | vulnerability |
| format | No | 报告格式: pdf/html/json/csv |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should disclose behavioral traits. It only states the function without mentioning side effects, permissions, or whether the report is generated instantly or asynchronously. It lacks essential behavioral 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 concise, uses headings and lists for clarity, and front-loads the core purpose. Every section adds value without unnecessary filler.
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 presence of an output schema, the description does not need to explain return values. However, it lacks context about prerequisites (e.g., scan completion), behavior (synchronous vs asynchronous), and any constraints. It covers the basics but is not fully complete.
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%, so baseline is 3. The description lists report types and formats in a structured way, but this largely repeats the schema descriptions. It adds minimal additional 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 generates a security scan report based on scan results, and lists report types and formats. It distinguishes from siblings like list_reports and start_scan, but could be more explicit about the distinction.
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 no guidance on when to use this tool versus alternatives (e.g., list_reports). It does not mention prerequisites (e.g., scan must be complete) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
查询扫描任务状态和结果
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | 扫描任务ID，由start_scan返回 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It indicates a read operation (query) but does not mention other traits like idempotency, rate limits, or error conditions.
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, concise sentence in Chinese efficiently conveys the tool's purpose without waste. Ideal for a simple tool.
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 tool with one parameter and an output schema, the description is minimally adequate. It lacks details on typical workflow (e.g., polling behavior) and prerequisites, but the output schema addresses return values.
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 100% coverage with a clear description for task_id. The tool description adds no extra meaning beyond the schema, achieving baseline score.
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 action (query) and resource (scan task status and results). It is specific and distinguishes from sibling tools like start_scan, cancel_scan, and list_scans.
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 context that the parameter task_id is returned by start_scan implies usage after a scan is started, but no explicit when-to-use or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取系统运行状态和扫描引擎信息
返回 MCP 服务器状态、扫描引擎可用性和运行环境信息。
Returns: JSON格式的系统状态
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It details the returned data: MCP server status, scan engine availability, and runtime environment, and notes the JSON format. This provides adequate transparency for a read-only status tool.
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 clear and structured with separated Chinese and English sections, though slightly verbose. Every sentence adds value. Could be more concise, but not overly long.
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 zero parameters and an output schema (implied), the description covers the purpose and return data thoroughly. No gaps identified for a simple status endpoint.
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 are no parameters, so the schema covers 100% of interface details. The description does not need to add param semantics. Baseline 4 applies.
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 explicitly states it retrieves system status and scan engine information, including MCP server status, engine availability, and runtime environment. This clearly distinguishes it from sibling tools like start_scan or list_vulnerabilities, which focus on specific actions or data types.
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 this tool is for checking system health and engine status, but does not explicitly state when to use it versus alternatives. Given the sibling tools are all action-oriented or data-specific, the context makes usage clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
获取漏洞详细信息
| Name | Required | Description | Default |
|---|---|---|---|
| vuln_id | Yes | 漏洞ID |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, authentication requirements, or error handling for invalid IDs. It only states what the tool does, not its side effects or constraints.
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 very concise with one short sentence, no wasted words. However, it is minimally structured; it could benefit from a more complete sentence structure.
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 that an output schema exists, the description does not need to explain return values. The single parameter is fully documented, and the tool's purpose is clear. It is nearly complete for a simple lookup 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 description coverage is 100% for the single parameter, so the baseline is 3. The description does not add meaning beyond the schema, but it is consistent.
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 retrieves detailed vulnerability information, distinguishing it from sibling tools like list_vulnerabilities (which lists summaries) and update_vulnerability_status (which modifies 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?
No guidance is provided on when to use this tool versus alternatives; it simply describes the action without context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
漏洞统计分析
统计漏洞数量、按严重程度和状态分布。
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | 统计周期：today/week/month/all | all |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; description only mentions basic functionality (counts, distributions). No disclosure of authentication needs, read-only nature, or performance characteristics.
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?
Very concise with a clear title and a single functional sentence. Every sentence contributes, though structure could be enhanced with bullets.
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?
Adequate for a simple stats tool with output schema. However, missing detail on how the 'period' parameter affects the output.
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%, but description adds no information about the 'period' parameter beyond what schema already provides. Baseline 3 would require at least minimal mention.
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 clearly states it provides vulnerability statistics (counts, distribution by severity and status), distinguishing it from siblings like get_vulnerability (single vuln) and list_vulnerabilities (detailed list).
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?
No explicit guidance on when to use this vs other tools like list_vulnerabilities or generate_report. Implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
识别医疗系统类型
通过端口扫描、服务指纹和 HTTP 响应特征识别目标系统的医疗系统类型。
HIS: 医院信息系统
PACS: 影像归档和通信系统
LIS: 实验室信息系统
RIS: 放射信息系统
EMR: 电子病历系统
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | 目标IP或URL | |
| ports | No | 指定扫描端口列表，如 [80, 443, 3306]；不填则扫描常见端口 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries burden. It explains the tool performs port scanning, service fingerprinting, and HTTP response analysis, but does not disclose potential intrusiveness, rate limits, or prerequisites. Only partial behavioral disclosure.
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 well-structured with clear sections (功能说明, 支持的系统类型). Each sentence is informative and no redundancy. Efficient for the information provided.
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 an output schema present, the description need not detail return format. It covers input purpose and supported system types. Remains complete enough for a scanning 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%, so parameters are documented in schema. Description adds context about scanning common ports when ports not specified, but does not add syntax or format details beyond schema. Baseline 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 tool identifies medical system types via port scanning, service fingerprinting, and HTTP response features. It lists five specific system types (HIS, PACS, LIS, RIS, EMR), distinguishing it from sibling tools like scan_host_ports or discover_network.
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?
No explicit guidance on when to use this tool versus alternatives. Sibling tools include general network discovery and vulnerability scanning, but no comparison or selection criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
列出生成的报告
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 返回结果数量限制 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully bears the burden of explaining behavior. It only states the action without disclosing any behavioral traits such as authentication requirements, rate limits, or side effects. The agent cannot assess safety or scope.
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 very brief (four characters in Chinese), but it is not appropriately informative. While concise, it sacrifices helpfulness. It is front-loaded but lacks structure or explanatory 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?
Given the simplicity of the tool (one parameter, output schema exists), the description is still incomplete. It does not explain the scope of 'reports', ordering, filtering, or the purpose of the parameter. The agent lacks sufficient context to use the tool effectively.
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 covers 100% of parameters with descriptions for 'limit' (default 20, integer). The description adds no additional meaning beyond what the schema already provides, meeting the baseline for high schema 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 indicates that the tool lists generated reports. It uses a specific verb and resource, but does not differentiate from sibling tools like list_scans or list_vulnerabilities, which have similar structures.
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?
No guidance is provided on when to use this tool versus alternatives. The description lacks context about appropriate use cases or exclusion criteria, leaving the agent to infer from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
列出扫描任务历史
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 返回结果数量限制，默认20 | |
| status | No | 按状态筛选：all/running/completed/cancelled/failed | all |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'list history'. It does not disclose behavioral traits such as pagination, sorting, or data freshness. The description fails to compensate for missing 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 a single concise phrase, no fluff. It is appropriately sized for a simple list tool.
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 low complexity, complete schema coverage, and presence of output schema, the description is minimally adequate but lacks context about output content and edge cases.
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% (both 'limit' and 'status' are described). The description adds no additional meaning beyond the schema, so baseline 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 '列出扫描任务历史' translates to 'List scan task history', clearly indicating a list operation on scan tasks. It is distinct from siblings like 'start_scan' and 'cancel_scan'.
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?
No guidance on when to use this tool versus alternatives. Implied usage is for viewing scan history, but no explicit context or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
列出发现的漏洞
获取漏洞列表，支持按严重程度和状态筛选。
| Name | Required | Description | Default |
|---|---|---|---|
| severity | No | 严重程度筛选: critical/high/medium/low/info | |
| status | No | 状态筛选: open/fixed/accepted/false_positive | |
| limit | No | 返回结果数量限制，默认50 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates the tool returns a list and supports filtering, but with no annotations, it fails to disclose other behavioral traits like pagination (limit parameter is mentioned only in schema), default ordering, or what happens when no results are found. The existence of an output schema partially compensates.
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 very brief (two lines) and front-loaded with the core purpose. It is efficient, though it could include a brief note about the output without becoming verbose.
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 list tool with 3 optional parameters and an output schema, the description is sufficient but lacks details on pagination, sorting, or the structure of results. It does not guide the agent on how to interpret the response, though the output schema may fill this gap.
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 clear descriptions for each parameter (severity, status, limit). The description merely restates the filtering capability without adding new meaning, so baseline 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 that the tool lists vulnerabilities and supports filtering by severity and status. It uses specific verb '列出' (list) and resource '漏洞' (vulnerabilities), distinguishing it from sibling tools like 'get_vulnerability' which likely retrieves a single record.
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?
No guidance is provided on when to use this tool versus alternatives. It does not mention when not to use it, such as for retrieving a single vulnerability (use get_vulnerability) or statistics (get_vuln_stats).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
端口扫描 - 真实检测主机开放的端口和服务
对目标主机进行端口扫描，识别开放的端口和运行的服务。 如果系统安装了 nmap 会自动使用，否则使用 Python socket 扫描。
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | 目标主机IP或域名 | |
| ports | No | 端口列表，如 [22, 80, 443]；不填则扫描常见端口 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals a key behavioral trait: if nmap is installed it will be used, otherwise Python socket scanning. This is useful for understanding performance and reliability. Without annotations, it provides adequate transparency, though it could mention potential intrusiveness or rate limiting.
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 relatively concise with two sentences plus a header. It front-loads the purpose and includes relevant detail. A bit more structure could help, but it is efficient.
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 simple tool with 2 parameters and an output schema, the description covers main behavior (scan method, default ports). It does not need to explain return values because the output schema exists. It is complete enough for an agent to use.
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 both parameters. The description adds that leaving 'ports' empty scans common ports, which is helpful but not essential. It does not add syntax or format details 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 performs port scanning to detect open ports and services on a host. It distinguishes from sibling tools like 'discover_network' by focusing specifically on host ports and providing detail about scanning method (nmap vs socket). The title and description are aligned.
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 does not explicitly state when to use this tool versus alternatives like 'start_scan' or 'discover_network'. It lacks guidance on prerequisites, limitations, or scenarios where the tool is appropriate or not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
启动漏洞扫描任务
对指定目标启动安全漏洞扫描，支持快速、标准和深度三种模式。 扫描会真实探测目标主机的端口、服务和漏洞。
quick: 快速扫描，常用端口 + 基础识别，约 10-30 秒
standard: 标准扫描，扩展端口 + 漏洞检测，约 30-120 秒
deep: 深度扫描，全端口 + nuclei 漏洞扫描，约 2-5 分钟
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | 扫描目标，支持IP、域名、URL或CIDR格式，如：192.168.1.1 或 192.168.1.0/24 | |
| scan_type | No | 扫描类型：quick(快速)/standard(标准)/deep(深度) | quick |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses that the scan '真实探测' (actually probes) target hosts, implying active scanning. It details what each scan type does (ports, services, vulnerabilities) and approximate durations. No annotations provided, so description carries full burden; it addresses this reasonably well.
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 well-structured with sections, bullet points, and bold labels. It is informative without being verbose. Every sentence adds value. However, it is bilingual (Chinese primary) which may slightly reduce conciseness for English agents.
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 presence of an output schema (not shown but indicated), the description does not need to explain return values. It covers the action, parameters, and scan types adequately. However, it lacks guidance on prerequisites or potential side effects (e.g., network impact).
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?
Input schema has 100% coverage, so baseline is 3. Description adds significant value by explaining each scan_type value (quick, standard, deep) with details on port ranges, vulnerability checks, and time estimates, which goes beyond the schema's simple enum labels.
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 clearly states it starts a vulnerability scan on a target, with three specific scan modes (quick, standard, deep). It distinguishes from siblings like scan_host_ports (which focuses only on ports) and list_scans (which lists scans). The verb '启动' (start) and resource '漏洞扫描任务' (vulnerability scan task) are specific.
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 provides detailed guidance on when to use each scan type (quick for fast checks, standard for vulnerability detection, deep for full coverage) with approximate durations. However, it does not explicitly state when not to use this tool or mention alternatives like scan_host_ports for pure port scanning.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
更新漏洞处理状态
更新漏洞的处理状态，用于漏洞修复跟踪。
open: 未修复
fixed: 已修复
accepted: 已接受风险
false_positive: 误报
| Name | Required | Description | Default |
|---|---|---|---|
| vuln_id | Yes | 漏洞ID | |
| status | Yes | 新状态: open/fixed/accepted/false_positive | |
| comment | No | 备注说明 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses allowed statuses and their meanings, but does not mention side effects, permissions, error handling, or reversibility. Minimal but not misleading.
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?
Concise with front-loaded title and structured sections (功能说明, 状态说明). No unnecessary sentences, though could be further streamlined.
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?
Adequate for a simple status update: describes purpose and allowed statuses. Lacks details on output, error conditions, or prerequisites. Output schema exists but description doesn't leverage it.
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%, but description adds value by explaining status meanings (open=fixed, etc.) beyond the schema's simple descriptions. The comment parameter is well-covered by 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?
Description clearly states the tool updates vulnerability processing status for fix tracking, with specific verb and resource. It distinguishes from sibling tools like list_vulnerabilities or get_vulnerability by focusing on mutation.
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?
Implied usage via 'for vulnerability fix tracking', but no explicit when to use, alternatives, or prerequisites. Siblings include related tools, but no guidance on when to update vs list or scan.
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. Dates show when Glama detected each change.
v0.1.0cancel_scandiscover_networkgenerate_reportget_scan_statusget_system_statusget_vuln_statsget_vulnerabilityidentify_medical_systemslist_reportslist_scanslist_vulnerabilitiesscan_host_portsstart_scanupdate_vulnerability_statusEach tool has a clear, distinct purpose (e.g., start_scan vs. get_scan_status, list_vulnerabilities vs. get_vulnerability). There is no ambiguity between tools.
All tool names follow a consistent verb_noun snake_case pattern (e.g., cancel_scan, discover_network, generate_report). No mixing of conventions.
14 tools are well-scoped for a vulnerability scanner covering scanning, vulnerability management, network discovery, and reporting. No unnecessary tools.
Covers the core lifecycle (scan, report, vuln management) well. Minor gap: absence of a tool to retrieve report content (only list and generate). Overall, very thorough.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
Free, read-only security scanner for remote MCP servers, before you connect them.
Scans remote MCP servers for protocol, security, and TLS issues; exposes scan tools via MCP.
Scan any MCP server for tool-poisoning, security, auth & license. Trust score before install.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/12211725-star/hospital-vuln-scanner-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
