How do I use mcptools?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcptools scan my home network for active hosts" 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.

mcptools

by fb0sh

Overview Schema Related Servers Score Discussions

Python

Hybrid

mcptools

一个通用的 MCP Server，提供开箱即用的实用工具集合，并内置了工具注册系统，方便你快速添加自己的工具。

架构

┌─────────────────────────┐      JSON-RPC over stdio/SSE      ┌──────────────────────┐
│  MCP Client             │ ◄──────────────────────────────►  │  mcptools            │
│                         │                                    │                      │
│  Claude Desktop         │                                    │  MCP Server          │
│  VS Code (Cline)        │                                    │  提供各种工具         │
│  pi / 其他 AI Agent     │                                    │  可扩展注册系统       │
└─────────────────────────┘                                    └──────────────────────┘

mcptools 是 MCP Server，不是 Client。它提供工具（current_time、calculate 等），等待 MCP Client（如 Claude Desktop）来连接和调用。

Related MCP server: nmap-mcp-server

内置工具一览

系统工具

工具	说明
`system_info`	获取系统基本信息（平台、内存、CPU 等）

网络扫描（nmap）

工具	说明
`nmap_scan`	通用 nmap 扫描，支持任意参数
`nmap_quick_scan`	快速扫描 Top 1000 端口
`nmap_service_scan`	扫描端口并探测服务版本（-sV）
`nmap_os_detection`	操作系统检测（-O）
`nmap_comprehensive`	综合扫描：端口 + 服务版本 + OS + 默认脚本（-A）
`nmap_ping_scan`	Ping 扫描（-sn），发现局域网在线主机
`nmap_script_scan`	使用 NSE 脚本扫描（如 --script=vuln）
`nmap_script_list`	列出 NSE 脚本（按类别筛选）
`nmap_script_help`	查看 NSE 脚本的详细帮助
`nmap_udp_scan`	UDP 端口扫描（-sU）
`nmap_traceroute`	路由追踪（--traceroute）
`nmap_firewall_evasion`	防火墙/IDS 规避扫描（分片、诱饵、代理等）
`nmap_scan_json`	执行扫描并返回 JSON 结构化结果
`nmap_scan_to_file`	扫描结果写入文件 → 读取验证 → 再追加
`nmap_scan_diff`	对比两次扫描结果的端口变化
`nmap_help_lookup`	从本地 nmap.help 文件查询 nmap 用法说明

快速开始

1. 安装

cd /Users/fb0sh/Temp/mcptools
python3 -m venv .venv
source .venv/bin/activate
pip install -e .

2. 测试运行

# stdio 模式（默认）
mcptools

# SSE 模式（像传统 C/S）
mcptools --transport sse --port 8080

配置到 MCP Client

方式一：stdio 模式（推荐，Claude 自动管理 Server 生命周期）

Claude Desktop 会自动启动和关闭 mcptools 进程，无需手动干预。

claude_desktop_config.json：

{
  "mcpServers": {
    "mcptools": {
      "command": "/Users/fb0sh/Temp/mcptools/.venv/bin/python",
      "args": ["/Users/fb0sh/Temp/mcptools/mcptools/server.py"]
    }
  }
}

使用绝对路径，不依赖系统 Python 环境。

VS Code (Cline) 的 .vscode/mcp.json：

{
  "servers": {
    "mcptools": {
      "type": "stdio",
      "command": "/Users/fb0sh/Temp/mcptools/.venv/bin/python",
      "args": ["/Users/fb0sh/Temp/mcptools/mcptools/server.py"]
    }
  }
}

方式二：SSE 模式（像传统 Client-Server，需要手动启动）

# 终端 1：先手动启动 Server
mcptools --transport sse --port 8080

// 然后配置 Client 通过地址连接
{
  "mcpServers": {
    "mcptools": {
      "url": "http://localhost:8080/sse"
    }
  }
}

SSE 模式下 Server 独立运行，Client 通过网络连接，适合 Docker 部署或远程访问。

两种模式对比

	stdio	SSE
配置写法	`command` + `args`	`url`
谁启动 Server	Claude Desktop 自动管理	你手动启动
生命周期	Claude 管，退出自动关闭	你管，需要 keep-alive
适用场景	本地开发，简单省事	Docker、远程、自定义端口

添加自己的工具

方式一：在 `tools/` 目录下新建文件

# mcptools/tools/weather_tools.py
from mcptools.registry import tool

@tool(name="get_weather", description="查询城市天气")
def get_weather(city: str, days: int = 1) -> str:
    """查询天气

    city: 城市名
    days: 预报天数（默认 1）
    """
    # 你的逻辑...
    return f"{city} 未来 {days} 天天气：晴 ☀️"

保存后自动生效，无需手动注册。

方式二：在任何地方使用装饰器

from mcptools.registry import tool

@tool(name="hello", description="Say hello")
def hello(name: str) -> str:
    return f"Hello, {name}!"

方式三：直接调用注册器

from mcptools.registry import registry

def my_tool(keyword: str) -> list:
    return ["result1", "result2"]

registry.register(my_tool, name="search", description="搜索关键词")

工具函数规则

参数类型注解会自动转为 JSON Schema（FastMCP 自动处理）
函数 docstring 第一行作为描述（如果没传 description）
支持同步和异步函数
参数 ctx 或 context 会被自动注入 FastMCP Context（用于日志、进度报告等）

作为库使用

from mcptools import create_server

# 创建 Server（自动发现 tools/ 下的所有工具）
server = create_server()

# stdio 模式
server.run(transport="stdio")

# 或 SSE 模式
server.run(transport="sse")

项目结构

mcptools/
├── __init__.py          # 包入口，导出 create_server
├── __main__.py          # python -m mcptools 入口
├── registry.py          # 核心：@tool 装饰器 + ToolRegistry 注册器
├── server.py            # FastMCP 服务器 + CLI（支持 stdio/SSE）
└── tools/               # 工具模块目录（自动发现）
    ├── __init__.py
    ├── system_tools.py  # 系统工具（system_info）
    └── nmap_tools.py    # nmap 网络扫描工具集

依赖

Python >= 3.11
mcp（MCP Python SDK，自动安装 FastMCP）
psutil（可选，pip install mcptools[full] 安装，提供更详细的系统信息）

Available Tools

17 tools

nmap_comprehensiveB

综合扫描：端口 + 服务版本 + OS + 默认脚本（-A）

ParametersJSON Schema

Name	Required	Description	Default
`target`	Yes
`sudo`	No
`timeout`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.4/5.0

Behavior3/5

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

The description discloses that the tool uses the -A option, which enables OS detection, version detection, script scanning, and traceroute. However, with no annotations, it fails to mention potential intrusiveness, network impact, or privileges required (though sudo param is present). Some behavioral context is added, but gaps remain.

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 a single clear sentence, achieving high conciseness with no filler. It could be slightly more structured (e.g., listing key features), but it efficiently conveys the core purpose.

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 the complexity of a comprehensive nmap scan and the presence of an output schema, the description is too brief. It omits critical context about execution time, potential side effects, and output structure. The tool is significantly under-described for its scope.

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 coverage is 0%, and the description does not explain any parameters, including 'target', 'sudo', or 'timeout'. While 'target' is somewhat obvious, 'sudo' and 'timeout' lack context (e.g., why sudo is needed or timeout's purpose). The description adds no meaning beyond the raw schema.

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?

Description clearly states it performs a comprehensive scan including port, service version, OS detection, and default scripts (-A). This directly differentiates it from siblings like nmap_os_detection or nmap_service_scan, providing a specific verb and scope.

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 implies this is the all-in-one scan tool but does not explicitly state when to use it versus alternatives like nmap_quick_scan or nmap_service_scan. No exclusions or context for when not to use it are provided, leaving the agent to infer.

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

nmap_firewall_evasionC

防火墙/IDS 规避扫描（分片、诱饵、代理、MAC 伪造等）

ParametersJSON Schema

Name	Required	Default
`target`	Yes
`technique`	No	fragment
`decoy_count`	No
`proxy`	No
`spoof_mac`	No
`source_port`	No
`sudo`	No
`timeout`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

The description mentions evasion techniques but does not disclose behavioral traits such as speed impact, potential blocking, or dependency on sudo. No annotations are provided to compensate.

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

Conciseness3/5

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

The description is a single sentence, which is concise but overly brief given the 8 parameters. It lacks structure and context, though it is not verbose.

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?

For a tool with 8 parameters, no schema descriptions, and no annotations, the description is insufficient. It does not explain parameter behavior, output format, or prerequisites, leaving significant gaps.

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?

With 0% schema description coverage, the description must explain parameters. It only hints at techniques (fragment, decoy, proxy, MAC) but does not describe 'source_port', 'timeout', 'sudo', or the 'technique' enum values. Parameter semantics are largely missing.

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 is for firewall/IDS evasion scanning and lists specific techniques (fragmentation, decoys, proxies, MAC spoofing). This distinguishes it from other nmap scan tools like nmap_quick_scan or nmap_scan.

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 is provided on when to use this tool versus alternatives. There is no mention of prerequisites, when not to use it, or which sibling tools to use instead.

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

nmap_help_lookupC

从本地 nmap.help 文件中查询 nmap 用法说明

ParametersJSON Schema

Name	Required	Description	Default
`keyword`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.6/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It only states the source file but does not mention read-only nature, authentication needs, or whether modifications occur. The tool is likely harmless, but it is not explicitly clarified.

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

Conciseness3/5

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

The description is a single sentence, which is concise, but it lacks necessary details. It is appropriately front-loaded but under-specified for a useful tool definition.

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 one parameter, no annotations, and an existing output schema (unseen), the description should explain what the tool returns and how the keyword is used. It does not address response format, error handling, or whether partial matches are supported.

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?

With 0% schema description coverage, the description should add meaning to the 'keyword' parameter. It only says 'keyword' without explaining its format, allowed values, or how it is matched. The description adds minimal value beyond the parameter name.

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

Purpose4/5

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

The description clearly states the tool queries nmap usage instructions from a local help file, using the verb 'query' and specifying the resource ('nmap.help file'). It distinguishes itself from sibling scan and script tools by focusing on help lookup.

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 like nmap_script_help or nmap_script_list. The description does not mention context, prerequisites, or exclusions.

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

nmap_os_detectionC

操作系统检测扫描（-O）

ParametersJSON Schema

Name	Required	Description	Default
`target`	Yes
`sudo`	No
`timeout`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.4/5.0

Behavior2/5

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

No annotations provided, and the description only mentions the -O flag without explaining behavioral traits like requiring root privileges (implied by sudo parameter), network latency, or packet crafting. The description does not disclose that OS detection is a more invasive scan.

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

Conciseness2/5

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

The description is extremely short but fails to provide sufficient information for a tool with 3 parameters. It is under-specified rather than concise.

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 the complexity of OS detection scanning, the description is incomplete. It does not discuss output format (even though an output schema exists), potential errors, timeouts, or limitations. The agent lacks context for effective use.

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

Parameters1/5

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

Schema description coverage is 0%, meaning no parameter descriptions are provided in the schema. The tool description does not compensate by explaining the parameters (target, sudo, timeout), leaving the agent with no information about their semantics.

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

Purpose4/5

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

The description clearly states the tool performs OS detection using the -O flag. However, it does not differentiate from sibling tools like nmap_comprehensive which also may include OS detection.

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 vs alternatives such as nmap_service_scan or nmap_comprehensive. No exclusions or prerequisites mentioned.

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

nmap_ping_scanB

Ping 扫描（-sn），发现局域网在线主机

ParametersJSON Schema

Name	Required	Description	Default
`target`	No		192.168.1.0/24
`timeout`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3/5.0

Behavior3/5

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

With no annotations, the description must carry the burden of behavioral disclosure. It informs that this is a ping-only scan, but does not mention potential permission requirements, scope limitations, or that it only identifies live hosts without port information.

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?

A single sentence that efficiently conveys the core function. It is front-loaded with key information, but lacks any additional structure (e.g., bullet points or sections) that could improve readability.

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

Completeness3/5

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), the description may not need to detail return values. However, it provides no context about expected output, behavior on failure, or integration with other nmap tools, making it moderately complete.

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%, so the description should explain parameters. It does not mention what target or timeout mean beyond their names and defaults. The target's default suggests a subnet format, but no explicit format or range guidance is given.

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

Purpose4/5

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

Description clearly states the tool performs a ping scan using -sn to discover online hosts in a LAN. This is specific enough to understand its purpose, though it does not explicitly distinguish from similar siblings like nmap_quick_scan or nmap_comprehensive.

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 is provided on when to use this tool versus alternatives such as nmap_comprehensive or nmap_service_scan. The description does not mention limitations, prerequisites, or typical use cases.

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

nmap_quick_scanB

快速扫描常用端口（Top 1000 端口）

ParametersJSON Schema

Name	Required	Description	Default
`target`	Yes
`sudo`	No
`timeout`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. It only states 'quick scan of top 1000 ports' without disclosing scan type, privileges needed (though 'sudo' param exists), or potential intrusiveness.

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 that is front-loaded, efficient, and contains no extraneous information.

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

Completeness3/5

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

Given the tool's simplicity and existence of output schema, the description is minimally adequate but lacks behavioral details and parameter context.

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 coverage is 0% (no parameter descriptions in schema). Description provides no parameter details beyond tool-level purpose. Baseline of 4 for zero parameters is not met as description fails to compensate.

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 verb 'scan' and specifies resource 'common ports' with scope 'Top 1000 ports'. It distinguishes from sibling tools like nmap_comprehensive (full scan) and nmap_service_scan (service version detection).

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 vs alternatives. Siblings include many nmap variants (e.g., nmap_comprehensive, nmap_service_scan), but the description does not contrast them.

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

nmap_scanC

执行 nmap 扫描，支持任意 nmap 参数

ParametersJSON Schema

Name	Required	Description	Default
`target`	Yes
`options`	No
`timeout`	No
`sudo`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.1/5.0

Behavior2/5

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

With no annotations, the description bears full responsibility for behavioral disclosure. It mentions 'supports arbitrary nmap parameters' but fails to warn about potential risks like long scan times, network impact, or the need for careful parameter selection. The sudo parameter hints at permission requirements, but the description does not address this.

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

Conciseness2/5

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

The description is a single sentence, which is concise but under-specified. It sacrifices necessary detail for brevity, resulting in a description that fails to convey critical information about parameters or usage context.

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 the presence of 4 parameters, many sibling tools, and an output schema, the description lacks completeness. It does not describe the output format, potential side effects, or how this tool relates to the broader set of nmap tools, leaving significant gaps for an agent to safely and effectively use it.

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

Parameters1/5

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

The input schema has 4 parameters with 0% description coverage, yet the tool description adds no explanation for any parameter. The phrase 'supports arbitrary nmap parameters' vaguely addresses the 'options' parameter, but 'target', 'timeout', and 'sudo' are completely undocumented, leaving the agent with no semantic guidance beyond the schema's names.

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

Purpose3/5

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

The description '执行 nmap 扫描' (Execute nmap scan) provides the basic action and resource, but it is too generic. With many sibling tools offering specialized scans (e.g., nmap_quick_scan, nmap_service_scan), the description does not differentiate this tool as the general-purpose option.

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 is given on when to use this tool versus its specialized siblings. For example, an agent would not know whether to choose this generic scan over nmap_quick_scan or nmap_service_scan for a given task.

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

nmap_scan_diffC

对比两次扫描结果的端口变化

ParametersJSON Schema

Name	Required	Default
`target`	Yes
`options`	No	-T4 --open
`sudo`	No
`timeout`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.4/5.0

Behavior2/5

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

The description does not explain how the tool obtains or compares scan results, nor does it describe the output format, despite an output schema existing. No annotations are provided to fill the gap.

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

Conciseness3/5

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

The description is a single sentence, which is concise but too short to convey necessary details.

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 the tool has 4 parameters, no parameter descriptions, and no annotations, the description is insufficient for an agent to correctly invoke it. The existence of an output schema is not leveraged.

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

Parameters1/5

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

Schema description coverage is 0%, and the description adds no meaning to any of the four parameters (target, options, sudo, timeout).

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

Purpose4/5

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

The description clearly states that the tool compares port changes between two scan results, which distinguishes it from other nmap tools that perform single scans.

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 is provided on when to use this tool versus alternatives, or what prerequisites are needed (e.g., prior scan results).

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

nmap_scan_jsonC

执行扫描并返回 JSON 结构化结果（适合程序化使用）

ParametersJSON Schema

Name	Required	Default
`target`	Yes
`options`	No	-T4 --open
`sudo`	No
`timeout`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.5/5.0

Behavior1/5

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

No annotations exist, and the description provides no behavioral details (e.g., network activity, potential destructiveness, timeouts, or root privileges). It only describes the output format, failing to disclose operational characteristics.

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

Conciseness3/5

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

The description is a single sentence, which is concise but lacks structure. It front-loads the core action but omits any additional detail, making it minimally adequate.

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 the tool has 4 parameters, no annotations, and many siblings, the description is too sparse. It does not explain that this is the JSON variant of nmap_scan, typical usage patterns, or performance implications, leaving significant gaps for an AI agent.

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

Parameters1/5

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

Schema description coverage is 0%, and the description adds no meaning to any of the four parameters. The schema has titles but no descriptions, and the tool description does not elaborate on targets, options, sudo, or timeout.

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 scans using nmap and returns JSON-structured output, suitable for programmatic use. This distinguishes it from sibling tools like nmap_scan (likely text output) or nmap_scan_to_file (file output).

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 does not mention prerequisites, situational context, or when not to use it, leaving the agent to infer from the name and purpose.

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

nmap_scan_to_fileC

扫描结果写入文件 → 读取验证 → 再追加（写入→check→再写入）

ParametersJSON Schema

Name	Required	Default
`target`	Yes
`options`	No	-T4 --open
`label`	No
`sudo`	No
`timeout`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.7/5.0

Behavior3/5

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

The description discloses a non-trivial workflow (write → check → append), which adds behavioral context beyond the tool name. However, it omits important details such as file path, overwrite behavior, permission requirements, or potential side effects. Without annotations, more transparency would be beneficial.

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

Conciseness3/5

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

The description is very short (one line), which is concise but lacks essential information about parameters and usage. It front-loads the workflow but sacrifices completeness.

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 the tool has 5 parameters, a required input, and an output schema, the description fails to cover what the parameters do or when to use the tool. The output schema existence mitigates missing return value info, but overall the description is insufficient for effective tool selection and invocation.

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

Parameters1/5

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

Schema description coverage is 0%, and the description does not explain any of the 5 parameters (target, options, label, sudo, timeout). Users cannot infer their meaning or usage from the description alone.

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

Purpose4/5

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

The description 'write scan results to file → read verification → append again' clearly conveys a multi-step process involving writing, checking, and appending to a file. It distinguishes from sibling tools that output to stdout or specific formats (e.g., nmap_scan_json, nmap_quick_scan) by emphasizing file I/O with verification.

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 is provided on when to use this tool versus siblings. For example, it does not explain when to prefer this over nmap_scan or nmap_scan_json, nor does it mention prerequisites or typical use cases.

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

nmap_script_helpC

查看 NSE 脚本的详细帮助

ParametersJSON Schema

Name	Required	Description	Default
`script_name`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.4/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention what happens if the script name is invalid, whether network access is required, or how the help is formatted. The description is insufficient for understanding behavioral traits.

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

Conciseness3/5

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

The description is a single short sentence, which is concise but lacking in detail. It is not overly verbose, but the brevity sacrifices clarity and completeness.

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 the tool has one parameter and no annotations, the description is insufficient. It does not explain the output format (despite an output schema existing) or provide enough context for an AI agent to use the tool correctly without additional information.

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

Parameters1/5

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

The schema has one parameter with 0% description coverage, and the description does not explain what 'script_name' should be (e.g., format, examples). The description fails to add meaning beyond the schema, which is unacceptable given the low coverage.

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

Purpose4/5

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

The description clearly states that the tool retrieves detailed help for NSE scripts. The verb and resource are specific, but it does not differentiate from sibling tools like nmap_script_list or nmap_script_scan, which are closely related.

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?

The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. It simply states the action without context.

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

nmap_script_listC

列出 NSE 脚本（按类别筛选）

ParametersJSON Schema

Name	Required	Description	Default
`category`	No
`search`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.7/5.0

Behavior2/5

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

No annotations exist, so description bears full burden. It does not disclose read-only nature, output format, or any limitations. The minimal description lacks behavioral details.

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?

Single concise sentence. While efficient, it is in Chinese and could be more informative in English. No wasted words.

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?

Despite having an output schema, the description does not explain return values or parameter details. Given sibling tools' complexity, this listing tool is simple but lacks completeness in user guidance.

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%. Description mentions 'filter by category' but does not explain the 'search' parameter or provide default behavior. Parameter semantics are insufficiently explained.

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

Purpose4/5

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

Description clearly states 'List NSE scripts' with filtering by category. While it distinguishes from siblings like nmap_script_scan and nmap_script_help, it does not explicitly contrast them.

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. Sibling tools like nmap_script_scan imply different use cases, but no explicit when-to-use or when-not-to-use is provided.

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

nmap_script_scanC

使用 NSE 脚本扫描（如 --script=vuln,default）

ParametersJSON Schema

Name	Required	Default
`target`	Yes
`scripts`	No	default
`ports`	No
`sudo`	No
`timeout`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.2/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It does not mention any side effects, permissions, safety, or what the tool does beyond scanning. This is a significant gap for a tool with no annotations.

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

Conciseness3/5

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

The description is very short (one sentence), which is concise, but it is under-specified and lacks important information. It is front-loaded but not effectively.

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, 0% schema coverage, no annotations, and an output schema present but unmentioned, the description fails to cover return values or parameter details. It is incomplete for the tool's complexity.

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

Parameters1/5

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

Schema description coverage is 0%, meaning no parameter descriptions exist in the schema. The tool description does not describe any of the 5 parameters (target, scripts, ports, sudo, timeout) beyond a vague script example. No meaning is added beyond the parameter names.

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

Purpose3/5

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

The description states '使用 NSE 脚本扫描' (use NSE script scanning) and gives an example of script categories. It indicates the tool runs NSE scripts but does not explicitly mention scanning a target, leaving ambiguity. The purpose is somewhat clear but not fully specified.

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?

The description provides no guidance on when to use this tool versus sibling tools like nmap_quick_scan or nmap_comprehensive. It lacks context on when script scanning is appropriate or alternatives.

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

nmap_service_scanC

扫描端口并探测服务版本（-sV）

ParametersJSON Schema

Name	Required	Default
`target`	Yes
`ports`	No	22,80,443,8080,3306,5432,6379,27017
`sudo`	No
`timeout`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.6/5.0

Behavior2/5

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

With no annotations, the description bears full responsibility for behavioral disclosure. It does not mention potential side effects (e.g., network probing, need for sudo), performance considerations, or output format. The description is too terse to inform the agent of behavioral traits beyond the basic scan action.

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

Conciseness3/5

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

The description is a single short sentence, which is concise and front-loads the purpose. However, it may be too brief to be effective, sacrificing completeness for brevity. It earns a baseline score for being minimally adequate.

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

Completeness1/5

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

Given the tool has 4 parameters, numerous siblings, and no annotations, the description is severely incomplete. It does not cover parameter details, usage context, or behavioral aspects. The existence of an output schema does not compensate for the lack of explanatory content.

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

Parameters1/5

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

Schema description coverage is 0%, yet the description adds no meaning to parameters like target, ports, sudo, or timeout. It only reiterates the tool's overall function without explaining how to configure the scan, leaving the agent to infer parameter usage from names and defaults alone.

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 explicitly states 'scan ports and detect service version (-sV)', clearly identifying the tool's specific action and resource. The mention of the nmap flag -sV distinguishes it from sibling tools like nmap_scan or nmap_os_detection.

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?

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, limitations, or situations where another tool would be preferable, leaving the agent without contextual decision support.

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

nmap_tracerouteC

路由追踪（--traceroute）

ParametersJSON Schema

Name	Required	Description	Default
`target`	Yes
`sudo`	No
`timeout`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.1/5.0

Behavior1/5

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

With no annotations, the description carries full burden for behavioral disclosure. It merely restates the tool's name and technique, offering no information about permissions, side effects, or output behavior.

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

Conciseness2/5

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

While extremely short, the description is under-specified and does not earn its place. Conciseness is negative here because critical information is omitted.

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

Completeness1/5

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

Given the three parameters and presence of an output schema, the description is completely inadequate. It provides no context about return values or how the tool behaves, making it difficult for an agent to use correctly.

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

Parameters1/5

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

Schema description coverage is 0%, and the description adds no explanation of the three parameters (target, sudo, timeout). Their semantics are entirely left to inference from parameter names and defaults.

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

Purpose4/5

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

The description explicitly states the tool performs route tracking using nmap's --traceroute option, which clearly identifies its purpose. However, it does not elaborate on the scope or distinguish it beyond the option flag.

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 is provided on when to use this tool versus the many sibling nmap tools (e.g., nmap_quick_scan, nmap_service_scan). There are no when-to-use or when-not-to-use instructions.

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

nmap_udp_scanC

UDP 端口扫描（-sU），探测 UDP 服务

ParametersJSON Schema

Name	Required	Default
`target`	Yes
`ports`	No	53,67,68,123,137,161,162,500,514,520,1900,5353
`sudo`	No
`timeout`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.4/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It mentions using the -sU flag and probing UDP services, but lacks details on required permissions (though sudo parameter hints at root), timeouts, impact (non-destructive), or output. For a security scanning tool, more transparency is expected.

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

Conciseness3/5

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

The description is extremely short (single sentence), which is concise but overly vague. It could be expanded with key parameter details while remaining succinct. It is front-loaded with the purpose, but the lack of structure harms clarity.

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 the tool has four parameters, no annotations, and an output schema (though not shown), the description is insufficient. It does not explain what the output might be, how to interpret results, or the significance of the sudo and timeout parameters. The brevity leaves significant gaps.

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

Parameters1/5

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

With 0% schema description coverage, the description should explain parameters. It does not mention any of the four parameters (target, ports, sudo, timeout) beyond what is in the schema. This is a critical gap, leaving the agent without guidance on port formats or default behavior.

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

Purpose4/5

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

The description clearly states that the tool performs UDP port scanning (-sU) and probes UDP services. It is specific about the resource (UDP ports) and the action (scan). However, it does not explicitly distinguish from sibling tools like nmap_service_scan, which might also involve UDP, but the focus on UDP ports is clear.

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 (e.g., nmap_service_scan or nmap_comprehensive). No prerequisites, exclusions, or contextual hints are provided. The agent is left to infer usage solely from the tool name and brief description.

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

system_infoB

获取系统基本信息

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are present, so the description bears full responsibility for behavioral disclosure. It only states 'get basic system info' without mentioning whether the operation is read-only, destructive, or requires any permissions. The output schema exists but is not described here.

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 a single, clear sentence that states the tool's purpose succinctly. It is appropriately sized and front-loaded, with no wasted words.

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

Completeness3/5

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

Given the tool's simplicity (no parameters), the description is adequate but vague. It does not specify what 'basic system information' includes (e.g., OS, hardware, uptime). The presence of an output schema may compensate, but without seeing it, the description lacks full context.

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, and the schema coverage is 100% by default. The description adds no parameter information, which is acceptable since there are none to describe.

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

Purpose4/5

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

The description '获取系统基本信息' (get basic system info) clearly indicates the tool's purpose of retrieving system-level information. It implicitly distinguishes from the nmap-focused sibling tools, which are network scanning tools.

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?

No explicit guidance on when to use this tool versus alternatives is provided. The sibling tools are all nmap-related, so the context implies use for system info rather than network scanning, but explicit instructions are missing.

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. Dates show when Glama detected each change.

17 tool updatesv1.0.0Jun 18, 2026
- First observednmap_comprehensive
- First observednmap_firewall_evasion
- First observednmap_help_lookup
- First observednmap_os_detection
- First observednmap_ping_scan
- First observednmap_quick_scan
- First observednmap_scan
- First observednmap_scan_diff
- First observednmap_scan_json
- First observednmap_scan_to_file
- First observednmap_script_help
- First observednmap_script_list
- First observednmap_script_scan
- First observednmap_service_scan
- First observednmap_traceroute
- First observednmap_udp_scan
- First observedsystem_info

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

C2.9/5.0

Disambiguation5/5

Each nmap tool has a clearly distinct purpose, e.g., comprehensive, OS detection, ping scan, script scan, etc. Even similar-sounding tools like nmap_scan vs nmap_quick_scan are differentiated by descriptions. Only system_info stands apart but does not cause confusion.

Naming Consistency3/5

All nmap tools follow a 'nmap_' prefix convention, but the naming pattern after the prefix is inconsistent: some use adjectives (comprehensive, quick), others nouns (scan, os_detection), and one uses a phrase (scan_to_file). Additionally, system_info breaks the pattern entirely.

Tool Count4/5

17 tools for nmap scanning is well-scoped, covering a wide range of scan types and utilities without being excessive. A few tools could be merged (e.g., nmap_scan and nmap_scan_json), but overall the count is appropriate for the domain.

Completeness4/5

The nmap tool surface is remarkably complete, covering basic scans, OS detection, service version, UDP, traceroute, NSE scripts, output to JSON/file, and comparison. The inclusion of system_info seems out-of-place but does not detract from nmap coverage. Minor gaps like custom timing profiles are covered by the generic nmap_scan.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

test-mcp B
dev.riskprofiler
An MCP server that provides a hello tool
11
staging-mcpOAuth
dev.riskprofiler
An MCP server that provides a hello tool
1
mcpcheck B
io.github.joeyough
Scan any MCP server for tool-poisoning, security, auth & license. Trust score before install.
Penetration Testing Security
21
ScanMalware.com URL Scanner C
com.scanmalware.mcp
MCP server for ScanMalware.com URL scanning, malware detection, and analysis.
Security Web Scraping App Automation
1282

Related MCP Servers

Enterprise MCP Server
Developer Tools Autonomous Agents
jimestesblog
F
license
Not graded
quality
D
maintenance
A highly configurable, deployment-ready MCP server with modular architecture for dynamic tool loading and external package support.
Updated a year ago (2025-10-02 09:59 UTC)
1
-
nmap-mcp-server
jarrodcoulter
A
license
Not graded
quality
D
maintenance
An MCP server that provides Nmap scanning tools such as ping, port scans, service discovery, and SMB share enumeration, running inside a Docker container for isolation.
Updated a year ago (2025-04-07 11:51 UTC)
7
MIT
AIX MCP Server
Developer Tools
easyzoom
A
license
Not graded
quality
C
maintenance
An extensible MCP server with a plugin system, proxy forwarding, web dashboard, and service registry for managing MCP tools and services.
Updated 4 months ago (2026-04-29 05:45 UTC)
1
MIT
nmap-mcp
Penetration Testing Networking & Infrastructure
schwarztim
A
license
A
quality
F
maintenance
A Model Context Protocol (MCP) server that provides comprehensive network scanning capabilities using nmap.
Updated 4 months ago (2026-05-09 05:03 UTC)
11
1
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/fb0sh/mcptools'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

mcptools

架构

内置工具一览

系统工具

网络扫描（nmap）

快速开始

1. 安装

2. 测试运行

配置到 MCP Client

方式一：stdio 模式（推荐，Claude 自动管理 Server 生命周期）

方式二：SSE 模式（像传统 Client-Server，需要手动启动）

两种模式对比

添加自己的工具

方式一：在 tools/ 目录下新建文件

方式二：在任何地方使用装饰器

方式三：直接调用注册器

工具函数规则

作为库使用

项目结构

依赖

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

方式一：在 `tools/` 目录下新建文件