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., "@nmap-mcp discover live hosts in 192.168.1.0/24"
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.
nmap-mcp is a production-ready Model Context Protocol (MCP) server that wraps Nmap, the industry-standard network scanner, to enable AI agents to perform automated network security assessments. Built by Vorota AI, it provides 6 scanning tools, 9 scan types, and 6 timing templates -- making it the most comprehensive Nmap integration for AI-powered security workflows available today.
Build and run nmap-mcp with Docker (includes Nmap):
docker build -t nmap-mcp https://github.com/vorotaai/nmap-mcp.git
docker run --rm -i nmap-mcpThen add to any MCP client:
{
"mcpServers": {
"nmap-mcp": {
"command": "docker",
"args": ["run", "--rm", "-i", "nmap-mcp"]
}
}
}Related MCP server: nmap-mcp
nmap-mcp from Vorota AI exposes 6 specialized scanning tools to any MCP-compatible AI agent:
Port Scanning -- TCP Connect, SYN stealth, UDP, FIN, XMAS, NULL, and ACK scan types with configurable port ranges and timing templates (T0 through T5).
Host Discovery -- Ping-sweep an entire subnet to find live hosts before deeper scanning.
Service Detection -- Identify running services and their exact versions on open ports with adjustable probe intensity (0-9).
OS Fingerprinting -- Determine operating systems through TCP/IP stack analysis.
Vulnerability Scanning -- Run Nmap Scripting Engine (NSE) scripts in safe categories to detect known vulnerabilities.
Quick Scan -- Fast top-N port scan with aggressive timing for rapid reconnaissance.
All tools include built-in input validation, network size limits, and timeout enforcement to prevent misuse.
For a thorough AI-powered security assessment, nmap-mcp tools are designed to be used in sequence:
Discover Hosts -- Use discover-hosts to find live targets on the network.
Quick Scan -- Run quick-scan on discovered hosts for a fast overview of open ports.
Port Scan -- Use scan-ports with specific scan types for deeper port analysis.
Detect Services -- Run detect-services on open ports to identify software versions.
Detect OS -- Use detect-os to fingerprint the operating system (requires root).
Scan Vulnerabilities -- Run scan-vulnerabilities to check for known security issues.
AI agents like Claude, Cursor, and VS Code Copilot can orchestrate this entire workflow automatically in a single conversation.
docker build -t nmap-mcp https://github.com/vorotaai/nmap-mcp.gitRequires Python 3.10+, Nmap on PATH, and uv:
git clone https://github.com/vorotaai/nmap-mcp.git
cd nmap-mcp
uv sync --all-groups
nmap-mcpnmap-mcp is compatible with all major MCP clients: Claude Desktop, Claude Code, Cursor, VS Code Copilot, Windsurf, and Cline.
First, build the Docker image:
docker build -t nmap-mcp https://github.com/vorotaai/nmap-mcp.gitAdd to your Claude Desktop configuration file (claude_desktop_config.json):
{
"mcpServers": {
"nmap-mcp": {
"command": "docker",
"args": ["run", "--rm", "-i", "nmap-mcp"]
}
}
}claude mcp add nmap-mcp -- docker run --rm -i nmap-mcp
Or add manually to your Cursor MCP settings (.cursor/mcp.json):
{
"mcpServers": {
"nmap-mcp": {
"command": "docker",
"args": ["run", "--rm", "-i", "nmap-mcp"]
}
}
}Add to your VS Code settings (.vscode/mcp.json):
{
"servers": {
"nmap-mcp": {
"command": "docker",
"args": ["run", "--rm", "-i", "nmap-mcp"]
}
}
}Use the same server configuration as Claude Desktop above. Refer to your client's documentation for the config file location.
Tool | Description | Key Parameters | Root Required |
| Port scan with configurable scan type, port range, and timing |
| Some types |
| Find live hosts on a network using ping scan (-sn) |
| No |
| Identify services and versions on open ports (-sV) |
| No |
| OS fingerprinting via TCP/IP stack analysis (-O) |
| Yes |
| Run NSE vulnerability detection scripts in safe categories |
| No |
| Fast top-N port scan with aggressive timing |
| No |
The scan-ports tool supports 7 scan types, each suited for different scenarios:
Scan Type | Flag | Root Required | Description |
|
| No | Full TCP handshake; reliable but detectable |
|
| Yes | SYN stealth scan; fast and less detectable |
|
| Yes | UDP port scan; slower but finds UDP services |
|
| Yes | FIN scan; stealthy, bypasses some firewalls |
|
| Yes | XMAS scan; sets FIN, PSH, URG flags |
|
| Yes | NULL scan; sends no flags |
|
| Yes | ACK scan; maps firewall rulesets |
Template | Name | Use Case |
T0 | Paranoid | IDS evasion |
T1 | Sneaky | IDS evasion |
T2 | Polite | Reduced bandwidth usage |
T3 | Normal | Default speed |
T4 | Aggressive | Fast, reliable networks |
T5 | Insane | Fastest, may lose accuracy |
nmap-mcp is configured through environment variables:
Variable | Default | Description |
|
| Path to the Nmap binary |
|
| Maximum scan duration in seconds |
|
| Maximum number of target hosts per scan (max /24 subnet) |
|
| Logging level (DEBUG, INFO, WARNING, ERROR) |
Example with custom configuration via Docker:
{
"mcpServers": {
"nmap-mcp": {
"command": "docker",
"args": [
"run", "--rm", "-i",
"-e", "NMAP_SCAN_TIMEOUT=120",
"-e", "NMAP_MAX_TARGETS=128",
"-e", "FASTMCP_LOG_LEVEL=ERROR",
"nmap-mcp"
]
}
}
}Authorization is required. nmap-mcp is a security tool that performs network scanning. You must ensure:
You have explicit authorization to scan any target network or host.
You comply with all applicable laws and organizational policies.
You use this tool only in environments where you have permission to conduct security assessments.
nmap-mcp by Vorota AI implements multiple layers of security to prevent misuse:
Input validation -- All inputs are validated against a set of forbidden characters (;, |, &, $, `, (, ), {, }, <, >, newlines) to prevent command injection attacks.
Network size limits -- Scans are limited to a maximum of 256 hosts by default (equivalent to a /24 subnet). This is configurable via NMAP_MAX_TARGETS.
Restricted NSE categories -- Only safe script categories are allowed: auth, default, discovery, safe, version, and vuln. Dangerous categories like exploit, dos, and intrusive are blocked.
Configurable timeouts -- All scans have a configurable timeout with a hard maximum of 600 seconds to prevent runaway processes.
No shell execution -- All Nmap commands are executed using Python's subprocess module with argument lists, never through a shell. This eliminates shell injection vectors entirely.
nmap-mcp is a Model Context Protocol (MCP) server built by Vorota AI that enables AI agents to perform Nmap network scans. It wraps the full power of Nmap -- port scanning, host discovery, service detection, OS fingerprinting, and vulnerability scanning -- into 6 structured tools that AI assistants like Claude, Cursor, and VS Code Copilot can call directly.
Build the nmap-mcp Docker image and configure it as an MCP server in your AI client (Claude Desktop, Claude Code, Cursor, VS Code, Windsurf, or Cline). Once connected, you can ask the AI to scan networks, detect services, fingerprint operating systems, and find vulnerabilities using natural language. The AI agent will call the appropriate nmap-mcp tools and interpret the results for you.
Yes. nmap-mcp includes multiple safety mechanisms: input validation to prevent command injection, network size limits to avoid scanning overly broad ranges, restricted NSE script categories that exclude dangerous scripts, configurable timeouts, and no shell execution. However, network scanning itself requires authorization -- always ensure you have permission before scanning any target.
nmap-mcp works with all MCP-compatible clients, including Claude Desktop, Claude Code, Cursor, VS Code (via GitHub Copilot), Windsurf, and Cline. Any client that supports the Model Context Protocol's stdio transport can connect to nmap-mcp.
Contributions are welcome. To set up the development environment:
git clone https://github.com/vorotaai/nmap-mcp.git
cd nmap-mcp
uv sync --all-groupsuv run pytestuv run ruff check .
uv run ruff format .Please open an issue or pull request on GitHub for bugs, feature requests, or improvements.
This project is licensed under the Apache License 2.0.
Copyright (c) Vorota AI
Detect the operating system of a target host.
Uses nmap TCP/IP stack fingerprinting (-O) to identify the target's operating system. NOTE: This typically requires elevated privileges (root/sudo).
IMPORTANT: Only scan targets you are authorized to scan.
Returns: ScanResult with OS detection matches for the target host.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target to scan: IP address or hostname. Single host only. | |
| timeout | No | Maximum scan duration in seconds. Default: 600. |
| Name | Required | Description |
|---|---|---|
| command | Yes | The nmap command that was executed (sanitized) |
| hosts | No | Results per host |
| scan_stats | No | Scan statistics |
| raw_output | No | Raw nmap output text |
| warnings | No | Scan warnings |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Absent annotations, the description carries the full burden. It discloses use of nmap -O, required root/sudo, and authorization necessity. It does not detail network impact or side effects, but covers critical safety and behavioral traits 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?
The description is concise with three short paragraphs: clear purpose, usage details, and return type. Every sentence contributes meaningfully without redundancy.
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 (2 params, 1 required, no enums, output schema exists), the description covers target type, timeout, privileges, and authorization. The output schema handles return value detail, so no gaps remain.
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 the schema already documents both parameters. The description does not add additional meaning beyond what the schema provides, resulting in a baseline score of 3.
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 'Detect the operating system of a target host' using nmap TCP/IP fingerprinting, with a specific verb and resource. It distinguishes from sibling tools like detect-services or scan-ports by focusing solely on OS detection.
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 notes elevated privileges and authorization requirements, providing clear context for safe usage. However, it does not explicitly compare to sibling tools or state when not to use this tool, though it implies its specific purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect services and versions running on open ports.
Uses nmap's service detection probes (-sV) to identify software names, versions, and CPE identifiers for services running on open ports.
IMPORTANT: Only scan targets you are authorized to scan.
Returns: ScanResult with service information for each open port.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target to scan: IP address or hostname. | |
| ports | No | Port specification. If omitted, scans nmap default ports. | |
| intensity | No | Version detection intensity (0-9). Higher is more accurate but slower. Default: 7. | |
| timing | No | Timing template. Default: "normal". | normal |
| timeout | No | Maximum scan duration in seconds. Default: 600. |
| Name | Required | Description |
|---|---|---|
| command | Yes | The nmap command that was executed (sanitized) |
| hosts | No | Results per host |
| scan_stats | No | Scan statistics |
| raw_output | No | Raw nmap output text |
| warnings | No | Scan warnings |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions using nmap's -sV probes and returns ScanResult, but does not disclose behavioral aspects like network noise, privilege requirements, or how errors are handled. The authorization warning adds some 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 four sentences, each earning its place. The purpose is stated first, followed by technical detail, an important warning, and return format. No redundancy or unnecessary words.
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 has five parameters and an output schema, the description provides sufficient context: method, returns, and an authorization warning. It does not cover edge cases like timeouts or empty results, but overall it is complete enough for an agent.
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 the schema already documents all parameters. The description adds context about the nmap technique but does not provide additional semantics beyond the schema's parameter descriptions. 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 detects services and versions on open ports using nmap's -sV probes. It specifies a concrete verb and resource, and distinguishes itself from sibling tools like scan-ports (which likely only lists open ports) and detect-os (which focuses on operating system detection).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an authorization warning but provides no guidance on when to use this tool versus alternatives like quick-scan or scan-ports. It does not explain when service detection is appropriate or which scenarios favor this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover live hosts on a network without performing a port scan.
Uses nmap ping scan (-sn) to identify which hosts are up on the target network. This is typically the first step in a network assessment.
IMPORTANT: Only scan networks you are authorized to scan.
Returns: HostDiscoveryResult with lists of hosts that are up and down.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Network range to scan: CIDR notation (192.168.1.0/24) or IP range. Max /24 network size. | |
| timing | No | Timing template: "paranoid" through "insane". Default: "normal". | normal |
| timeout | No | Maximum scan duration in seconds. Default: 600. |
| Name | Required | Description |
|---|---|---|
| hosts_up | No | List of hosts that are up |
| hosts_down | No | List of hosts that are down |
| total_scanned | No | Total hosts scanned |
| scan_stats | No | Scan statistics |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It reveals the underlying tool (nmap -sn) and notes the authorization requirement, but does not disclose potential side effects (e.g., network noise, privilege requirements, or impact on targets).
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 compact (4 sentences plus a returns line) with no wasted words. It front-loads the core action, explains the method, provides use-case context, and includes a critical safety note. Every sentence adds distinct 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 tool's moderate complexity and the presence of an output schema, the description adequately covers what the tool does, how it works, and what it returns. It could mention prerequisites or potential limitations (e.g., network permissions), but overall it provides sufficient context for decision-making.
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?
All parameters have descriptions in the input schema (100% coverage), so the description adds no new meaning beyond schema. The description text itself does not elaborate on parameter semantics, meeting the baseline of 3.
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 'Discover live hosts on a network without performing a port scan' and specifies use of 'nmap ping scan (-sn)'. This clearly distinguishes it from sibling tools like scan-ports and detect-services, which have different purposes.
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 positions the tool as 'typically the first step in a network assessment' and emphasizes 'without performing a port scan', implying usage before port scanning. However, it does not explicitly state when not to use it or directly name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform a fast scan of the most common ports.
Scans the top N most frequently used ports with aggressive timing for quick results. Good for getting a fast security overview of a target.
IMPORTANT: Only scan targets you are authorized to scan.
Returns: ScanResult with discovered hosts and open ports.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target to scan: IP address or hostname. | |
| top_ports | No | Number of top ports to scan (by frequency). Default: 100. | |
| service_detection | No | Enable service/version detection. Default: true. | |
| timeout | No | Maximum scan duration in seconds. Default: 600. |
| Name | Required | Description |
|---|---|---|
| command | Yes | The nmap command that was executed (sanitized) |
| hosts | No | Results per host |
| scan_stats | No | Scan statistics |
| raw_output | No | Raw nmap output text |
| warnings | No | Scan warnings |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It mentions 'aggressive timing for quick results' and returns a ScanResult, but does not disclose potential network impact, rate limits, or additional 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with 4 sentences plus a warning and return note. It front-loads the core purpose and avoids unnecessary details.
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?
The tool has 4 parameters and an output schema. The description covers the main functionality, authorization, and return type. However, it lacks explanation of how parameters like 'service_detection' affect results or performance.
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 parameters are already documented. The description adds context like 'aggressive timing' but does not significantly enhance parameter 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 performs a 'fast scan of the most common ports' and 'top N most frequently used ports,' distinguishing it from sibling tools like 'scan-ports' or 'scan-vulnerabilities' which suggest broader or different scopes.
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 indicates it's 'good for getting a fast security overview' and includes an authorization warning, but does not explicitly state when not to use it or contrast it with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan ports on a target host or network.
Performs a port scan using nmap with the specified parameters. Validates all inputs to prevent command injection.
IMPORTANT: Only scan targets you are authorized to scan.
Returns: ScanResult with discovered hosts, ports, and their states.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target to scan: IP address (192.168.1.1), hostname (example.com), or CIDR notation (192.168.1.0/24). Max /24 network size. | |
| ports | No | Port specification. Examples: "22", "1-1024", "22,80,443", "T:22,80,U:53" for protocol-specific. If omitted, scans nmap default ports. | |
| scan_type | No | Scan type: "connect" (TCP connect, no root needed), "syn" (SYN stealth, needs root), "udp" (UDP, needs root), "fin", "xmas", "null", "ack". Default: "connect". | connect |
| timing | No | Timing template: "paranoid", "sneaky", "polite", "normal", "aggressive", "insane". Default: "normal". | normal |
| service_detection | No | Enable service/version detection (-sV). Slower but identifies running software. | |
| timeout | No | Maximum scan duration in seconds. Default: 600. |
| Name | Required | Description |
|---|---|---|
| command | Yes | The nmap command that was executed (sanitized) |
| hosts | No | Results per host |
| scan_stats | No | Scan statistics |
| raw_output | No | Raw nmap output text |
| warnings | No | Scan warnings |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions input validation to prevent command injection and returns a ScanResult, which is transparent. However, it does not disclose potential network disturbance, detection risk, or permission requirements beyond authorization.
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 three main components: purpose, warning, return value. No superfluous sentences.
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 6 parameters and an output schema, the description covers the core functionality and important usage warning. It is complete for the schema richness, though it could mention alternative tools for context.
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%, and the description does not add meaning beyond what the schema already provides for parameters. 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 action (scan ports) and the resource (target host/network) using nmap. It distinguishes from siblings like detect-os or quick-scan by focusing on port scanning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an authorization warning but lacks explicit guidance on when to use this tool versus sibling tools like detect-services or quick-scan. The description implies usage for network reconnaissance but does not state exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan for known vulnerabilities using Nmap Scripting Engine (NSE).
Runs NSE vulnerability detection scripts against the target. Uses safe script categories by default. Results include CVE identifiers when available.
IMPORTANT: Only scan targets you are authorized to scan. Vulnerability scanning may trigger security alerts on the target network.
Returns: VulnScanResult with discovered vulnerabilities and their details.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target to scan: IP address or hostname. | |
| ports | No | Port specification. If omitted, scans nmap default ports. | |
| scripts | No | NSE script specification. Examples: "vuln", "auth", "default,safe", "http-vuln-*". Only categories from {auth, default, discovery, safe, version, vuln} are allowed. If omitted, uses "vuln" category. | |
| timing | No | Timing template. Default: "normal". | normal |
| timeout | No | Maximum scan duration in seconds. Default: 600. |
| Name | Required | Description |
|---|---|---|
| command | Yes | The nmap command that was executed (sanitized) |
| vulnerabilities | No | Discovered vulnerabilities |
| hosts_scanned | No | Number of hosts scanned |
| raw_output | No | Raw nmap output text |
| warnings | No | Scan warnings |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full disclosure burden. It explains the use of safe script categories by default, inclusion of CVE identifiers, and the return type VulnScanResult. It also warns about triggering security alerts.
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 extremely concise and well-structured with a brief overview, important note, and return type section. Every sentence adds necessary information without redundancy.
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 complexity of 5 parameters and the existence of an output schema, the description adequately covers the tool's purpose, usage, and behavioral traits. It differentiates from siblings through specific vulnerability scanning focus.
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 adds value by clarifying allowed script categories and default behaviors for ports, scripts, timing, and timeout, which is not fully captured in the parameter descriptions alone.
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 verb 'scan' and the specific resource 'known vulnerabilities using Nmap Scripting Engine (NSE)'. It distinguishes from sibling tools like detect-os, detect-services, and scan-ports, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an important usage warning about authorization and potential security alerts. It implies usage for vulnerability scanning but does not explicitly compare to alternatives like quick-scan or scan-ports.
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.0detect-osdetect-servicesdiscover-hostsquick-scanscan-portsscan-vulnerabilitiesScored across 6 tools
Each tool has a clearly distinct purpose: host discovery, OS detection, service detection, quick port scan, comprehensive port scan, and vulnerability scanning. No overlap or ambiguity.
All tool names follow a consistent verb_noun pattern using lowercase and hyphens (e.g., detect-os, scan-ports). The only slight deviation is 'quick-scan' (adjective-verb), but it remains clear and predictable.
With 6 tools, the set is well-scoped for network scanning. It covers the essential nmap operations without being excessive or too sparse.
The tool surface covers the full lifecycle of network reconnaissance: host discovery, OS fingerprinting, service version detection, port scanning (both quick and thorough), and vulnerability scanning. No obvious gaps for typical use cases.
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.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
MCP server for Pentest-Tools.com: run scans, manage findings and reports via your preffered LLM.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Vorota-ai/nmap-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
