Which integrations are available for this server?

Supports installation and operation on CentOS systems with specific yum/dnf package manager instructions for setting up the required Nmap dependencies. Supports installation and operation on Debian systems with specific apt package manager instructions for setting up the required Nmap dependencies. Supports installation and operation on macOS systems through Homebrew package manager, with specific configuration instructions for macOS environments. Leverages Python for implementation with specific version requirements (Python 3.10+) and dependency management through pip. Supports installation and operation on Ubuntu systems with specific apt package manager instructions for setting up the required Nmap dependencies.

How do I use Nmap MCP Server?

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., "@Nmap MCP Server scan my local network for open ports" 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 Server

by mohdhaji87

Overview Schema Related Servers Score Discussions

Python

Local

Nmap MCP Server

A Model Context Protocol (MCP) server that exposes Nmap CLI functionality as MCP tools using FastMCP with stdio transport. This server provides comprehensive network scanning capabilities through the Nmap command-line tool.

🚀 FastMCP Implementation

This server is built using FastMCP, a modern, high-performance MCP framework that provides:

Simplified API: Clean decorator-based tool registration
Type Safety: Full type hints and validation
Stdio Transport: Efficient communication via standard input/output
Async Support: Non-blocking operations with proper error handling

Related MCP server: Nmap MCP Server

Features

The Nmap MCP Server exposes the following tools using FastMCP decorators:

1. Basic Scan (`nmap_basic_scan`)

Perform basic Nmap scans with different intensity levels:

Quick: Fast scan with high throughput
Comprehensive: Full scan with service detection and OS detection
Stealth: Low-profile scan to avoid detection

2. Service Detection (`nmap_service_detection`)

Detect services and versions running on target hosts with configurable intensity levels (0-9).

3. OS Detection (`nmap_os_detection`)

Detect operating systems running on target hosts with configurable retry attempts.

4. Script Scanning (`nmap_script_scan`)

Run NSE (Nmap Scripting Engine) scripts for advanced reconnaissance and vulnerability assessment.

5. Stealth Scan (`nmap_stealth_scan`)

Perform SYN scans with minimal detection using configurable timing templates.

6. Comprehensive Scan (`nmap_comprehensive_scan`)

Perform full-featured scans combining multiple detection methods.

7. Ping Scan (`nmap_ping_scan`)

Discover live hosts using various ping methods (ICMP, TCP, or both).

8. Port Scan (`nmap_port_scan`)

Scan specific ports using different methods (SYN, Connect, UDP).

9. Vulnerability Scan (`nmap_vulnerability_scan`)

Run vulnerability detection scripts with different categories.

10. Network Discovery (`nmap_network_discovery`)

Discover hosts and services on entire networks.

11. Custom Scan (`nmap_custom_scan`)

Perform scans with user-defined Nmap options for maximum flexibility.

Prerequisites

Python 3.10 or higher
Nmap installed and available in your system PATH

Installing Nmap

macOS:

brew install nmap

Ubuntu/Debian:

sudo apt update
sudo apt install nmap

CentOS/RHEL:

sudo yum install nmap
# or for newer versions:
sudo dnf install nmap

Windows: Download and install from nmap.org

Installation

Clone this repository:

git clone <repository-url>
cd nmap-mcp-server

Install dependencies:

pip install -e .

Usage

Running the FastMCP Server

The server can be run directly with stdio transport:

python server.py

Or using the installed script:

nmap-mcp-server

Claude Desktop Configuration

Add the following configuration to your Claude Desktop MCP settings:

{
  "mcpServers": {
    "NmapMCP": {
      "command": "uv",
      "args": [
        "--directory",
        "/Users/haji/mcp-servers/nmap-mcp-server",
        "run",
        "server.py"
      ]
    }
  }
}

Configuration Steps:

Open Claude Desktop
Go to Settings → MCP Servers
Add the JSON configuration above
Restart Claude Desktop
Verify the server is connected

FastMCP Tool Examples

Basic Network Scan

# The tool is called with typed parameters
result = await nmap_basic_scan(
    targets="192.168.1.0/24",
    ports="common",
    scan_type="quick"
)

Service Detection

result = await nmap_service_detection(
    targets="example.com",
    ports="80,443,8080",
    intensity=7
)

Vulnerability Assessment

result = await nmap_vulnerability_scan(
    targets="192.168.1.100",
    ports="common",
    vuln_category="all"
)

Custom Scan

result = await nmap_custom_scan(
    targets="example.com",
    custom_options="-sS -p 1-1000 -A --script=vuln",
    output_format="normal"
)

FastMCP Architecture

The server uses FastMCP's clean decorator pattern:

@app.tool(
    name="nmap_basic_scan",
    description="Perform a basic Nmap scan of specified targets"
)
async def nmap_basic_scan(
    targets: str,
    ports: str = "common",
    scan_type: str = "quick"
) -> str:
    """Perform a basic Nmap scan of specified targets."""
    # Implementation here
    return result

Security Considerations

⚠️ Important Security Notes:

Legal Compliance: Only scan networks and systems you own or have explicit permission to scan.
Network Impact: Some scans can be resource-intensive and may impact network performance.
Detection: Aggressive scans may trigger security systems and firewalls.
Rate Limiting: The server includes timeouts and rate limiting to prevent abuse.

Error Handling

The FastMCP server includes comprehensive error handling for:

Nmap command not found
Command timeouts
Invalid arguments
Network connectivity issues
Permission errors

Logging

The server uses Python's built-in logging system. Logs include:

Command execution details
Error messages
Performance metrics

Testing

Test the FastMCP server:

# Test tool registration and functionality
python test_fastmcp.py

# Test examples
python example_usage.py

Contributing

Fork the repository
Create a feature branch
Make your changes
Add tests if applicable
Submit a pull request

License

This project is licensed under the MIT License - see the LICENSE file for details.

Disclaimer

This tool is for educational and authorized security testing purposes only. Users are responsible for ensuring they have proper authorization before scanning any network or system.

Support

For issues and questions:

Check the error logs
Verify Nmap is installed and accessible
Ensure you have proper permissions
Open an issue on the repository

Changelog

Version 1.0.0

Initial release with FastMCP implementation
Support for all major Nmap scanning techniques
Comprehensive error handling
Stdio transport mode
Type-safe tool definitions
Claude Desktop configuration with uv

Available Tools

11 tools

nmap_basic_scanC

Perform a basic Nmap scan of specified targets

ParametersJSON Schema

Name	Required	Default
`targets`	Yes
`ports`	No	common
`scan_type`	No	quick

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.4/5.0

Behavior1/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action without detailing critical traits such as network impact, permissions required, rate limits, output format, or whether it's safe for production use. This is inadequate for a network scanning tool with potential security implications.

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, direct sentence with no wasted words, making it highly concise and front-loaded. It efficiently communicates the core action without unnecessary elaboration, though this brevity contributes to gaps in other dimensions.

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's complexity (network scanning with 3 parameters), lack of annotations, and 0% schema coverage, the description is insufficient. While an output schema exists, the description fails to address behavioral risks, parameter meanings, or differentiation from siblings, making it incomplete for safe and effective use.

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%, meaning parameters are undocumented in the schema. The description does not compensate by explaining what 'targets', 'ports', or 'scan_type' mean, their formats, or acceptable values (e.g., what 'common' ports or 'quick' scan type entail). This leaves key input semantics unclear.

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 the tool's purpose as 'Perform a basic Nmap scan of specified targets,' which clearly indicates the verb ('Perform'), resource ('Nmap scan'), and scope ('basic'). However, it does not differentiate this tool from its many siblings (e.g., nmap_port_scan, nmap_network_discovery), leaving ambiguity about what makes it 'basic' versus other scan types.

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 its alternatives. With multiple sibling tools available (e.g., nmap_comprehensive_scan, nmap_stealth_scan), there is no indication of scenarios where a 'basic' scan is preferred, prerequisites, or exclusions, leading to potential misuse.

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

nmap_comprehensive_scanC

Perform comprehensive scan with all detection methods

ParametersJSON Schema

Name	Required	Default
`targets`	Yes
`ports`	No	all
`include_scripts`	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 provided, the description carries full burden but offers minimal behavioral insight. It mentions 'comprehensive scan' and 'all detection methods', hinting at thoroughness, but doesn't disclose critical traits like potential intrusiveness, network impact, time requirements, or output format. For a scanning tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

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, efficient sentence that gets straight to the point without unnecessary words. It's appropriately sized for a tool name that implies its function, though it could be more informative.

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 complexity (comprehensive scanning), lack of annotations, and 0% schema coverage, the description is incomplete. However, the presence of an output schema mitigates some need to explain return values. The description provides a basic purpose but fails to address usage, parameters, or behavioral details adequately.

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 must compensate but adds no parameter information. It doesn't explain what 'targets', 'ports', or 'include_scripts' mean, their formats, or how they affect the scan. With 3 parameters and no schema descriptions, this is inadequate.

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 the tool performs a 'comprehensive scan with all detection methods', which indicates a broad scanning operation but lacks specificity about what resources are being scanned. It distinguishes from siblings by implying completeness ('all detection methods'), but doesn't clearly articulate what makes it different from tools like 'nmap_custom_scan' or 'nmap_script_scan' beyond the 'comprehensive' label.

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 explicit guidance is provided on when to use this tool versus alternatives. The description mentions 'all detection methods', which might imply it's for thorough scanning, but it doesn't specify scenarios, prerequisites, or exclusions compared to sibling tools like 'nmap_basic_scan' or 'nmap_stealth_scan'.

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

nmap_custom_scanC

Perform custom Nmap scan with user-defined options

ParametersJSON Schema

Name	Required	Default
`targets`	Yes
`custom_options`	Yes
`output_format`	No	normal

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 provided, the description carries full burden but only states the action without disclosing behavioral traits. It lacks details on permissions, rate limits, output behavior, or potential impacts (e.g., network effects, security considerations), which are critical for a scanning tool.

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, efficient sentence with no wasted words, making it appropriately sized and front-loaded. Every part contributes directly to the tool's purpose, earning its place without redundancy.

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 custom Nmap scan with 3 parameters, 0% schema coverage, no annotations, and sibling tools, the description is incomplete. It does not address usage context, parameter details, or behavioral aspects, despite having an output schema that might cover return values.

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 must compensate but adds minimal meaning. It mentions 'user-defined options' which loosely relates to 'custom_options', but does not explain parameters like 'targets' format, 'output_format' options, or provide examples, leaving significant gaps.

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 the tool performs a custom Nmap scan with user-defined options, which provides a basic purpose (verb+resource). However, it lacks specificity about what distinguishes it from siblings like nmap_basic_scan or nmap_port_scan, making it vague in context.

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 alternatives (e.g., nmap_basic_scan, nmap_vulnerability_scan). The description implies usage for custom options but does not specify scenarios, exclusions, or comparisons, leaving the agent without clear direction.

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

nmap_network_discoveryC

Discover hosts and services on a network

ParametersJSON Schema

Name	Required	Default
`network`	Yes
`discovery_method`	No	all
`include_ports`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.2/5.0

Behavior1/5

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

With no annotations provided, the description carries full burden for behavioral disclosure but offers minimal information. It doesn't describe what 'discover' entails operationally (e.g., is it active scanning, passive listening, requires special permissions, has rate limits, affects network performance, returns structured data). The description is too generic for a network scanning tool that likely has significant behavioral implications.

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 extremely concise at just 6 words, with no wasted language. It's front-loaded with the core purpose. However, this conciseness comes at the cost of completeness - every word earns its place but too few words are present for adequate tool documentation.

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 network discovery tools, 3 parameters with 0% schema coverage, no annotations, but with an output schema, the description is insufficient. While the output schema may document return values, the description doesn't provide enough context about the tool's behavior, parameter usage, or differentiation from siblings to enable effective tool selection and invocation.

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 for all 3 parameters, the description provides no parameter semantics beyond what's implied by the tool name. It doesn't explain what 'network' expects (CIDR notation, IP range, hostname), what 'discovery_method' options exist, or what 'include_ports' controls. The description fails to compensate for the complete lack of schema documentation.

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 'Discover hosts and services on a network' clearly states the tool's purpose with a specific verb ('Discover') and resources ('hosts and services'), but it doesn't distinguish this tool from its many siblings (e.g., nmap_basic_scan, nmap_ping_scan, nmap_port_scan) that likely perform similar discovery functions. The description is vague about what makes this tool unique within the NMPA toolset.

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

Usage Guidelines1/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 the 10 sibling tools listed. There's no mention of alternatives, prerequisites, or specific contexts where this discovery tool is preferred over other scanning/detection tools. This leaves the agent with no basis for selecting among similar-sounding tools.

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

nmap_os_detectionC

Perform operating system detection scan

ParametersJSON Schema

Name	Required	Default
`targets`	Yes
`ports`	No	common
`max_retries`	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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Perform operating system detection scan') but lacks details on traits like required permissions, network impact, rate limits, or output format. For a network scanning tool with potential security implications, this is a significant gap in transparency.

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, efficient sentence: 'Perform operating system detection scan'. It is front-loaded with the core action and wastes no words, making it highly concise and well-structured for quick comprehension.

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 complexity (network scanning with 3 parameters) and the presence of an output schema, the description is minimally adequate. However, with no annotations and 0% schema coverage, it lacks crucial context like behavioral traits and parameter meanings. The output schema may help with return values, but overall completeness is limited.

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?

The schema description coverage is 0%, meaning parameters are undocumented in the schema. The description adds no information about parameters like 'targets', 'ports', or 'max_retries', failing to compensate for the coverage gap. This leaves the agent without semantic understanding of inputs beyond their titles.

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's purpose: 'Perform operating system detection scan'. It specifies the verb ('Perform') and the resource/action ('operating system detection scan'), making it understandable. However, it doesn't explicitly differentiate from sibling tools like 'nmap_service_detection' or 'nmap_comprehensive_scan', which might also involve OS detection, so it doesn't reach a 5.

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. With multiple sibling tools like 'nmap_basic_scan', 'nmap_comprehensive_scan', and 'nmap_service_detection', there's no indication of specific contexts, prerequisites, or exclusions. This leaves the agent without clear usage direction.

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

nmap_ping_scanC

Perform ping scan to discover live hosts

ParametersJSON Schema

Name	Required	Description	Default
`targets`	Yes
`ping_type`	No		both

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.8/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 mentions the tool performs a ping scan to discover live hosts, but lacks details on permissions needed, network impact, rate limits, output format (though output schema exists), or whether it's read-only or destructive. This is inadequate for a network scanning tool.

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, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded with the core functionality.

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 network scanning, no annotations, and 0% schema description coverage, the description is insufficient. It doesn't explain parameter usage, behavioral traits, or when to use it versus siblings. The existence of an output schema helps with return values, but other critical context is missing.

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 must compensate. It adds no information about the 'targets' or 'ping_type' parameters beyond what the schema provides (just their names). No context on target format (e.g., IP ranges, hostnames) or ping type options (e.g., ICMP, TCP) 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?

The description clearly states the action ('Perform ping scan') and the goal ('to discover live hosts'), which is specific and distinguishes it from siblings focused on port scanning, OS detection, or vulnerability scanning. However, it doesn't explicitly differentiate from 'nmap_network_discovery' which might have overlapping functionality.

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 like 'nmap_network_discovery' or other sibling tools. The description only states what it does, not when it's appropriate or what scenarios it's best suited for.

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

nmap_port_scanC

Scan specific ports on target hosts

ParametersJSON Schema

Name	Required	Default
`targets`	Yes
`ports`	Yes
`scan_method`	No	syn

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.8/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Scan specific ports' implies a read-only operation, but it doesn't address potential network impact, permissions required, rate limits, timeout behavior, or what constitutes a 'scan' (e.g., active probing vs. passive). For a network scanning tool with zero annotation coverage, this leaves critical behavioral traits unspecified.

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, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse. Every word earns its place by conveying essential information without fluff.

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 network scanning (with potential for misuse or network impact), no annotations, 0% schema coverage, and multiple sibling tools, the description is incomplete. It doesn't address behavioral risks, parameter details, or differentiation from alternatives. The presence of an output schema helps with return values, but the overall context demands more guidance for safe and effective use.

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%, meaning none of the 3 parameters (targets, ports, scan_method) have descriptions in the schema. The description mentions 'specific ports' and 'target hosts', which loosely maps to the 'ports' and 'targets' parameters but adds minimal semantic value—it doesn't explain format (e.g., comma-separated ports, CIDR ranges), defaults, or the meaning of 'scan_method' (with a default of 'syn'). The description fails to compensate for the lack of schema documentation.

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 'Scan specific ports on target hosts' clearly states the verb ('Scan') and resource ('specific ports on target hosts'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from its many siblings (like nmap_basic_scan, nmap_service_detection, etc.), which all involve scanning but with different scopes or focuses.

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. With 10 sibling tools available, including nmap_basic_scan and nmap_comprehensive_scan, the agent has no indication whether this is for targeted port scanning versus broader network discovery or other scan types. No context, exclusions, or prerequisites are mentioned.

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

nmap_script_scanC

Run NSE (Nmap Scripting Engine) scripts

ParametersJSON Schema

Name	Required	Default
`targets`	Yes
`scripts`	No	default
`ports`	No	common

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.4/5.0

Behavior1/5

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

No annotations are provided, so the description carries full burden but fails to disclose behavioral traits. It doesn't mention if this is a read-only or destructive operation, network impact, permissions needed, rate limits, or output format. The description is minimal and adds no context beyond the basic action.

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, efficient sentence with no wasted words. It's front-loaded and appropriately sized for the tool's complexity, though it could benefit from more detail given the lack of annotations and schema coverage.

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 (3 parameters, 0% schema coverage, no annotations) and the presence of an output schema, the description is incomplete. It doesn't explain parameter meanings, usage context, or behavioral aspects, relying too heavily on the output schema to cover return values without addressing input or operational 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 description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'targets', 'scripts', or 'ports' mean, their formats (e.g., IP ranges, script names, port lists), or default behaviors. This leaves key semantics undocumented.

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 'Run NSE (Nmap Scripting Engine) scripts' clearly states the action (run) and resource (NSE scripts), but it's vague about what this entails compared to siblings like nmap_vulnerability_scan or nmap_service_detection, which might also use scripts. It doesn't specify if this is for targeted script execution versus broader scanning.

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. With many sibling tools (e.g., nmap_vulnerability_scan, nmap_service_detection), the description lacks context on whether this is for custom scripts, default scripts, or specific use cases, leaving the agent to guess based on the name alone.

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

nmap_service_detectionC

Perform service and version detection scan

ParametersJSON Schema

Name	Required	Default
`targets`	Yes
`ports`	No	common
`intensity`	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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action (perform scan) but doesn't mention whether this is read-only or destructive, what permissions are needed, potential network impact, rate limits, or output format. For a network scanning tool, this lack of context is a significant gap.

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, efficient sentence with zero waste. It's appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration.

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 complexity of a network scanning tool with 3 parameters, 0% schema coverage, and no annotations, the description is incomplete—it lacks behavioral and parameter details. However, the presence of an output schema mitigates some need to explain return values, keeping it from being completely inadequate.

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 must compensate for undocumented parameters. It adds no information about the three parameters (targets, ports, intensity), such as what 'targets' should be (IPs, hostnames), what 'common' ports means, or the range/meaning of 'intensity'. This leaves parameters largely unexplained.

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 'Perform service and version detection scan' clearly states the action (perform scan) and purpose (service and version detection), but it's vague about the specific resource (network targets) and doesn't differentiate from sibling tools like 'nmap_port_scan' or 'nmap_script_scan' which might also detect services. It's better than a tautology but lacks specificity.

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 like 'nmap_port_scan' or 'nmap_comprehensive_scan'. It doesn't mention prerequisites, context, or exclusions, leaving the agent to guess based on the tool name alone.

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

nmap_stealth_scanC

Perform stealth scan (SYN scan) with minimal detection

ParametersJSON Schema

Name	Required	Default
`targets`	Yes
`ports`	No	common
`timing`	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?

No annotations are provided, so the description carries full burden. It mentions 'stealth scan (SYN scan)' and 'minimal detection', which hints at network behavior, but lacks details on permissions needed, rate limits, output format (though output schema exists), or potential risks like network disruption. More context on what 'stealth' entails operationally would help.

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?

Extremely concise with a single sentence that front-loads the core action. Every word earns its place: 'Perform stealth scan' states the purpose, '(SYN scan)' clarifies the method, and 'with minimal detection' adds context. No wasted verbiage.

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 3 parameters with 0% schema coverage, no annotations, but an output schema exists, the description is incomplete. It covers the tool's purpose and stealth aspect but misses parameter explanations and behavioral details. The output schema mitigates some gaps, but for a network scanning tool with siblings, more guidance on usage and params is needed.

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 must compensate. It adds no information about parameters like 'targets', 'ports', or 'timing'. Without param details, users can't infer what values to provide (e.g., format for 'targets', meaning of 'timing' levels). The description fails to explain these beyond the bare schema.

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 action ('Perform stealth scan') and method ('SYN scan'), with the goal of 'minimal detection'. It distinguishes from siblings by specifying the stealth/SYN technique, though it doesn't explicitly contrast with other nmap tools like 'nmap_basic_scan' or 'nmap_port_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 explicit guidance on when to use this tool versus alternatives like 'nmap_basic_scan' or 'nmap_port_scan'. The mention of 'minimal detection' implies a use case for stealth, but it doesn't specify scenarios, prerequisites, or exclusions compared to sibling tools.

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

nmap_vulnerability_scanC

Run vulnerability detection scripts

ParametersJSON Schema

Name	Required	Default
`targets`	Yes
`ports`	No	common
`vuln_category`	No	all

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2/5.0

Behavior1/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'Run vulnerability detection scripts' but fails to describe critical traits like potential network impact, security implications, output format, error handling, or execution time. This is inadequate for a tool that likely performs active scanning.

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, efficient sentence with no wasted words. It is front-loaded and appropriately sized for its minimal content, though this conciseness comes at the cost of detail.

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 vulnerability scanning, no annotations, and an output schema (which might cover return values), the description is incomplete. It lacks essential context like safety warnings, performance considerations, and differentiation from siblings, making it insufficient for effective tool 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 parameters are undocumented in the schema. The description adds no information about parameters like 'targets', 'ports', or 'vuln_category', such as their formats, allowed values, or effects. It does not compensate for the lack of schema documentation.

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 'Run vulnerability detection scripts' states a general purpose (running scripts for vulnerability detection) but lacks specificity about what resource it acts on (e.g., network targets) and how it differs from sibling tools like 'nmap_script_scan' or 'nmap_comprehensive_scan'. It's vague about scope and implementation details.

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

Usage Guidelines1/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_script_scan' or 'nmap_comprehensive_scan'. The description offers no context, prerequisites, or exclusions, leaving the agent without direction for selection among similar tools.

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.

11 tool updatesAug 15, 2025
- First observednmap_basic_scan
- First observednmap_comprehensive_scan
- First observednmap_custom_scan
- First observednmap_network_discovery
- First observednmap_os_detection
- First observednmap_ping_scan
- First observednmap_port_scan
- First observednmap_script_scan
- First observednmap_service_detection
- First observednmap_stealth_scan
- First observednmap_vulnerability_scan

Install Server

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

TDQS

B3/5.0

Disambiguation3/5

The tools have clear distinctions in their primary functions (e.g., ping_scan vs. os_detection), but there is significant overlap in scanning types. For instance, basic_scan, comprehensive_scan, and custom_scan could be confused as they all perform general scans, and network_discovery might overlap with ping_scan. Descriptions help differentiate, but an agent might struggle to choose between similar tools without deeper context.

Naming Consistency5/5

All tool names follow a consistent 'nmap_' prefix with descriptive snake_case suffixes (e.g., nmap_basic_scan, nmap_os_detection). This pattern is uniform across all 11 tools, making them predictable and easy to parse. There are no deviations in naming conventions, which enhances clarity and usability.

Tool Count4/5

With 11 tools, the count is reasonable for covering Nmap's diverse scanning capabilities. It's well-scoped to include various scan types (e.g., stealth, vulnerability) and detection methods. However, it might be slightly heavy as some tools could be consolidated (e.g., basic and comprehensive scans), but overall, each tool serves a distinct purpose in the domain.

Completeness5/5

The tool set provides comprehensive coverage of Nmap's core functionalities, including host discovery, port scanning, service detection, OS detection, script execution, and vulnerability scanning. There are no obvious gaps; agents can perform full network reconnaissance workflows from discovery to in-depth analysis, ensuring no dead ends in typical use cases.

Maintenance

ActivityInactive

ResponsivenessSyncing

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

mcpcheckup A
io.github.fpetitit
Scans remote MCP servers for protocol, security, and TLS issues; exposes scan tools via MCP.
Penetration Testing Security
22
MCP FortressOAuth
io.github.mcp-fortress
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
Security Testing & QA Tools Penetration Testing
2
mcp-server
com.pentest-tools
MCP server for Pentest-Tools.com: run scans, manage findings and reports via your preffered LLM.
Penetration Testing Security
23
Kadent Scan A
so.kadent
Free, read-only security scanner for remote MCP servers, before you connect them.
Security Penetration Testing
11

Related MCP Servers

Nmap MCP Server
Security Command Line OS Automation
imjdl
A
license
B
quality
D
maintenance
A Model Control Protocol server that provides access to nmap network scanning functionality, allowing users to run customizable scans, store results, and analyze network security using AI prompts.
Updated a year ago (2025-04-24 10:20 UTC)
3
18
MIT
Nmap MCP Server
Penetration Testing Security
sideffect263
F
license
Not graded
quality
D
maintenance
Enables network scanning and security assessment using Nmap through MCP, allowing AI assistants to perform port scans, service detection, and network reconnaissance on specified targets with configurable scan parameters.
Updated a year ago (2025-05-25 14:36 UTC)
-
Nmap MCP Server
Security Penetration Testing
flagify-com
A
license
Not graded
quality
D
maintenance
Enables network security scanning using Nmap through MCP protocol. Supports quick port scans, full port scans with service detection, and custom Nmap commands with async task management.
Updated 4 months ago (2026-04-26 08:19 UTC)
3
MIT
mcp-server-nmap
Security Networking & Infrastructure Penetration Testing
daedalus
A
license
Not graded
quality
C
maintenance
Enables network scanning and reconnaissance through MCP tools, leveraging nmap for port scanning, service detection, and host discovery via synchronous, asynchronous, and streaming interfaces.
Updated 5 months ago (2026-04-21 19:28 UTC)
MIT

Appeared in Searches

How to get the IP address of a domain

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/mohdhaji87/Nmap-MCP-Server'

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

Nmap MCP Server

🚀 FastMCP Implementation

Features

1. Basic Scan (nmap_basic_scan)

2. Service Detection (nmap_service_detection)

3. OS Detection (nmap_os_detection)

4. Script Scanning (nmap_script_scan)

5. Stealth Scan (nmap_stealth_scan)

6. Comprehensive Scan (nmap_comprehensive_scan)

7. Ping Scan (nmap_ping_scan)

8. Port Scan (nmap_port_scan)

9. Vulnerability Scan (nmap_vulnerability_scan)

10. Network Discovery (nmap_network_discovery)

11. Custom Scan (nmap_custom_scan)

Prerequisites

Installing Nmap

Installation

Usage

Running the FastMCP Server

Claude Desktop Configuration

FastMCP Tool Examples

Basic Network Scan

Service Detection

Vulnerability Assessment

Custom Scan

FastMCP Architecture

Security Considerations

Error Handling

Logging

Testing

Contributing

License

Disclaimer

Support

Changelog

Version 1.0.0

Available Tools

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

Appeared in Searches

Latest Blog Posts

MCP directory API

1. Basic Scan (`nmap_basic_scan`)

2. Service Detection (`nmap_service_detection`)

3. OS Detection (`nmap_os_detection`)

4. Script Scanning (`nmap_script_scan`)

5. Stealth Scan (`nmap_stealth_scan`)

6. Comprehensive Scan (`nmap_comprehensive_scan`)

7. Ping Scan (`nmap_ping_scan`)

8. Port Scan (`nmap_port_scan`)

9. Vulnerability Scan (`nmap_vulnerability_scan`)

10. Network Discovery (`nmap_network_discovery`)

11. Custom Scan (`nmap_custom_scan`)