How do I use NmapMCP?

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., "@NmapMCP scan the top 100 ports on 192.168.1.1" 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.

NmapMCP

by 0xPratikPatil

Overview Schema Related Servers Score Discussions

Python

Local

NmapMCP

NmapMCP is a robust integration of the Nmap scanning tool with the Model Context Protocol (MCP), enabling seamless network scanning capabilities within MCP-compatible environments. This project allows users to perform various network scans, such as top ports scanning, DNS brute force, and more, directly through MCP interfaces.

Features

Top Ports Scanning: Quickly identify the most commonly used ports on target hosts to assess potential entry points.
DNS Brute Force: Discover subdomains associated with a target domain, aiding in comprehensive domain mapping.
List Scan: Obtain a list of active hosts within a specified range without port scanning, useful for network inventory.
OS Detection: Determine the operating system of a target host by analyzing network responses, assisting in vulnerability assessment.
Version Detection: Identify service versions running on open ports to detect outdated or vulnerable services.
FIN Scan: Perform stealthy scans by sending FIN packets to detect open ports without establishing a full connection.
Idle Scan: Conduct highly stealthy scans by leveraging idle hosts to probe target systems, minimizing detection risks.
Ping Scan: Detect active hosts in a network by sending ICMP echo requests, useful for network mapping.
SYN Scan: Perform half-open TCP scans to identify open ports without completing the TCP handshake, reducing detection likelihood.
TCP Connect Scan: Establish full TCP connections to probe open ports, useful when SYN scans are not feasible.
UDP Scan: Identify open UDP ports on a target host to detect services that do not use TCP.
Port Scan Only: Focus solely on scanning ports without additional host discovery, streamlining the scanning process.
No Port Scan: Perform host discovery without scanning ports, useful for identifying live hosts without probing services.
ARP Discovery: Identify active devices within a local network segment using ARP requests, effective in LAN environments.
Disable DNS Resolution: Perform scans without resolving IP addresses to hostnames, enhancing scan speed and reducing DNS query traffic.

Related MCP server: Nmap MCP Server

Installation

Installing via Smithery

To install Nmap Integration for Claude Desktop automatically via Smithery:

npx -y @smithery/cli install @0xPratikPatil/nmapmcp --client claude

Manual Installation

Clone the Repository:

git clone https://github.com/0xPratikPatil/NmapMCP.git
cd NmapMCP

Install uv:

curl -LsSf https://astral.sh/uv/install.sh | sh

Create environment:
```
uv venv
```

Install dependencies from pyproject.toml

uv pip install

uv pip install -r pyproject.toml

Configuration

To configure the Nmap MCP Server, edit the claude_desktop_config.json file located in the project root. This file allows you to set default scan arguments, define MCP tool behaviors, and adjust logging settings.

Example claude_desktop_config.json:

{
  "mcpServers": {
    "NmapMCP": {
      "command": "uv",
      "args": [
        "--directory",
        "/path/to/NmapMCP",
        "run",
        "main.py"
      ]
    }
  }
}

Contributing

Contributions are welcome! To contribute:

Fork the Repository: Click the "Fork" button at the top right of the repository page.

Clone Your Fork:

git clone https://github.com/0xPratikPatil/NmapMCP.git

Create a New Branch:

git checkout -b feature/your-feature-name

Make Your Changes: Implement your feature or fix.
Run Tests: Ensure all tests pass.

Commit Changes:

git commit -m "Add feature: your feature name"

Push to Your Fork:

git push origin feature/your-feature-name

Submit a Pull Request: Navigate to the original repository and click "New Pull Request."

License

This project is licensed under the MIT License.

Acknowledgments

Special thanks to the Nmap and MCP communities for their invaluable tools and support.

Available Tools

15 tools

arp_discoveryB

Perform ARP discovery on the specified target with optional custom arguments.

Args: target (str): The target IP address or subnet (e.g., '192.168.1.0/24'). args (str): Additional Nmap command-line arguments.

Returns: dict: The ARP discovery results.

ParametersJSON Schema

Name	Required	Description	Default
`target`	Yes
`args`	No

TDQS

B3.4/5.0

Behavior2/5

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

No annotations given, so description must carry transparency. It only says 'perform ARP discovery' without disclosing traits like needing root privileges, potential network disruption, or that it uses Nmap. Lacks behavioral disclosure beyond the action.

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?

Description is short with clear sections (Args and Returns). It front-loads the purpose. However, it could be slightly more concise by removing the redundant 'Args:' header since the parameter list is already in the schema.

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?

For a tool with no output schema, the description states returns 'dict: The ARP discovery results' but doesn't detail result keys or error behavior. Missing prerequisites like network access. Adequate but not fully complete.

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?

Schema coverage is 0%, but the description explains both parameters: 'target (str)' with example subnet '192.168.1.0/24' and 'args (str)' as additional Nmap arguments. This adds significant meaning beyond the schema's title and type fields.

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 states 'Perform ARP discovery on the specified target' which specifies the action and resource. It distinguishes from sibling tools like syn_scan or tcp_scan by focusing on ARP protocol, making its purpose clear and unique.

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 ARP discovery versus other scanning methods. It does not mention limitations like local subnet requirement or that it is for LAN environments. No exclusions or alternatives provided.

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

disable_dns_resolutionC

Perform a scan on the specified target with DNS resolution disabled and optional custom arguments.

Args: target (str): The target IP address or hostname. args (str): Additional Nmap command-line arguments.

Returns: dict: The scan results with DNS resolution disabled.

ParametersJSON Schema

Name	Required	Description	Default
`target`	Yes
`args`	No

TDQS

C2.7/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 disabling DNS resolution without explaining behavioral implications such as speed impact or limitation to IP addresses. The meaning of 'scan' is vague.

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 concise with a front-loaded sentence and a structured Args/Returns format. However, the Returns section is minimal and could be integrated into the main description.

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?

Without output schema, annotations, or detailed parameter info, the description lacks completeness. It does not explain the structure of the returned dictionary or edge cases.

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 notes target as IP/hostname and args as Nmap arguments, which adds basic meaning, but does not specify format or constraints for args (e.g., allowed flags).

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 states it performs a scan with DNS resolution disabled, which is a specific verb-resource pair. It distinguishes from siblings that do not disable DNS resolution, though it does not specify the type of scan (e.g., port scan, host discovery).

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 syn_scan or ping_scan. The description does not mention scenarios where disabling DNS resolution is beneficial or necessary.

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

dns_brute_forceB

Perform DNS brute-force to discover subdomains of the specified target.

Args: target (str): The target domain to scan. args (str): Additional Nmap command-line arguments.

Returns: dict: The DNS brute-force scan results.

ParametersJSON Schema

Name	Required	Description	Default
`target`	Yes
`args`	No

TDQS

B3.2/5.0

Behavior2/5

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

The description does not disclose any behavioral traits beyond the basic function. Without annotations, it fails to mention if the tool is destructive, affects network traffic, requires permissions, or has rate limiting, leaving the agent uninformed about potential side effects.

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 concise with three clear lines: purpose, parameter descriptions, and return type. It is front-loaded with the main action, and each sentence serves a purpose without unnecessary detail.

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?

For a simple tool with two parameters and no output schema, the description covers the basic purpose and parameter roles. However, it lacks details on the return value structure (e.g., keys in the dict), which would help the agent interpret results.

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

Parameters3/5

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

The description adds meaning to the parameters beyond the input schema titles: 'target' is defined as 'the target domain to scan' and 'args' as 'Additional Nmap command-line arguments.' While this is helpful, it is minimal and does not explain valid values or constraints.

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 the action ('Perform DNS brute-force') and the resource ('subdomains of the specified target'), making it clear what the tool does. It distinguishes itself from sibling tools like arp_discovery or syn_scan, which focus on different network discovery methods.

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 when DNS brute-force is appropriate or when to prefer other discovery methods. The description lacks any context about prerequisites, expected outcomes, or usage scenarios.

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

fin_scanB

Perform a FIN scan on the specified target with optional custom arguments.

Args: target (str): The target IP address or hostname. args (str): Additional Nmap command-line arguments.

Returns: dict: The FIN scan results.

ParametersJSON Schema

Name	Required	Description	Default
`target`	Yes
`args`	No

TDQS

B3.3/5.0

Behavior2/5

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

No annotations provided; description does not disclose important behavioral traits such as stealth level, required privileges, or potential network impact of a FIN scan.

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?

Concise docstring format with clear purpose and parameter descriptions, though the Returns line is somewhat redundant given no output schema.

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 no annotations, no output schema, and minimal parameter info, the description lacks context on use cases, prerequisites, and expected behavior beyond the basic operation.

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?

With 0% schema coverage, description adds value by defining parameter types and roles (target as IP/hostname, args as additional Nmap arguments), compensating for schema gaps.

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 the action ('Perform a FIN scan') and the target resource, distinguishing it from sibling tools which are 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?

No guidance on when to use a FIN scan versus alternatives like SYN scan or TCP scan. The agent lacks context to choose correctly.

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

idle_scanC

Perform an idle scan on the specified target with optional custom arguments.

Args: target (str): The target IP address or hostname. args (str): Additional Nmap command-line arguments.

Returns: dict: The idle scan results.

ParametersJSON Schema

Name	Required	Description	Default
`target`	Yes
`args`	No

TDQS

C2.9/5.0

Behavior2/5

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

No annotations exist, so the description bears full responsibility. It does not disclose behavioral traits such as network side effects, stealth characteristics, or required permissions. The description is purely functional.

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 short and includes a structured docstring with Args and Returns sections. It is front-loaded with the primary purpose. However, it could be more concise by omitting the redundant 'Args' section that repeats schema info.

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?

With no output schema and no annotations, the description should provide more context about the technique of idle scanning, how results are returned, and any caveats. It is insufficient for an AI agent to successfully invoke the tool.

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 minimal meaning: 'target' is an IP/hostname, 'args' are additional Nmap arguments. This is insufficient; more detail (e.g., valid patterns, restrictions) would be needed.

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

Purpose5/5

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

The description clearly states the action ('Perform'), the resource ('idle scan'), and the primary operand ('target'). It distinguishes from siblings which include various scan types like syn_scan or udp_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 its siblings (e.g., for zombie scanning vs. direct scans). No prerequisites or context for appropriate usage are mentioned.

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

list_scanB

Perform a list scan on the specified target with optional custom arguments.

Args: target (str): The target IP address or hostname. args (str): Additional Nmap command-line arguments.

Returns: dict: The list scan results.

ParametersJSON Schema

Name	Required	Description	Default
`target`	Yes
`args`	No

TDQS

B3.3/5.0

Behavior2/5

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

No annotations present, and the description does not disclose behavioral traits like network permissions, side effects, or what the return dict contains.

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?

Two-line description with parameter docs, no extraneous content, efficiently front-loaded.

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?

No output schema and no annotations, description is adequate for basic usage but does not explain the return format or behavior in depth.

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

Parameters3/5

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

With 0% schema coverage, the description adds minimal meaning by defining target as IP/hostname and args as additional Nmap arguments, but lacks details like format or examples.

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 performs a list scan on a target with optional arguments, distinguishing it from other scan types like ping_scan or syn_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 on when to use this tool versus its siblings; lacks context about scenarios or prerequisites.

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

no_portscanB

Perform host discovery without port scanning on the specified target with optional custom arguments.

Args: target (str): The target IP address or hostname. args (str): Additional Nmap command-line arguments.

Returns: dict: The host discovery results.

ParametersJSON Schema

Name	Required	Description	Default
`target`	Yes
`args`	No

TDQS

B3.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 carry the full burden. It discloses that the tool does host discovery without port scanning, but does not specify what methods are used, expected behavior, or any side effects. The 'custom arguments' possibility is mentioned but not elaborated.

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

Conciseness4/5

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

The description is very concise, with the main purpose stated upfront. The docstring format includes separate lines for Args and Returns, which adds structure but also some redundancy. Overall, it is efficient.

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 two parameters, no output schema, and no annotations, the description provides basic completeness. It explains what the tool does and what each parameter means, but lacks detail on return format, error conditions, or typical use cases.

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

Parameters3/5

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

Schema description coverage is 0%, so the description's parameter explanations add value. It clarifies that 'target' is an IP or hostname and 'args' are additional Nmap command-line arguments. This improves understanding beyond the raw schema, though it remains minimal.

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 performs host discovery without port scanning, using a specific verb ('Perform') and resource ('host discovery'). It implicitly distinguishes from sibling tools that involve port 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 explicit guidance on when to use this tool versus alternatives like ping_scan or arp_discovery. The description only says 'without port scanning', which is not enough to differentiate among the 14 sibling tools.

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

os_detectionA

Perform OS detection on the specified target with optional custom arguments.

Args: target (str): The target IP address or hostname. args (str): Additional Nmap command-line arguments.

Returns: dict: The OS detection results.

ParametersJSON Schema

Name	Required	Description	Default
`target`	Yes
`args`	No

TDQS

A3.6/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden. It discloses that it performs OS detection and returns a dict, but does not mention side effects, permissions, rate limits, or limitations. Basic disclosure.

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 short and includes Args and Returns sections. It is front-loaded but could be more concise. Every sentence is relevant, but the format is acceptable.

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 lack of output schema/annotations, the description adequately specifies target and args but does not explain what OS detection entails, how results are structured, or prerequisites.

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

Parameters3/5

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

The description names parameters and explains 'target' as IP/hostname and 'args' as additional Nmap arguments, adding meaning beyond the schema's types. However, schema coverage is 0%, so the description compensates minimally.

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 'Perform OS detection on the specified target', specifying verb and resource. It distinguishes from sibling tools like version_detection or ping_scan by focusing 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.

Usage Guidelines3/5

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

The description implies when to use the tool (for OS detection) but provides no guidance on when not to use it or what alternatives exist among siblings. No when-to-use or when-not-to-use statements.

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

ping_scanB

Perform a ping scan on the specified target with optional custom arguments.

Args: target (str): The target IP address or hostname. args (str): Additional Nmap command-line arguments.

Returns: dict: The ping scan results.

ParametersJSON Schema

Name	Required	Description	Default
`target`	Yes
`args`	No

TDQS

B3/5.0

Behavior2/5

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

With no annotations, the description should disclose behavioral traits but only mentions returns a dict. It omits important details like network impact, required permissions, or how results are formatted.

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 short but includes an Args section that largely repeats schema info. Could be more concise by integrating the parameter descriptions into the first sentence.

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?

For a simple 2-param tool with no output schema, the description covers purpose and param semantics but lacks usage guidelines and behavioral details, making it marginally adequate.

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?

Despite 0% schema description coverage, the description adds meaning by defining target as 'IP address or hostname' and args as 'Additional Nmap command-line arguments', which is helpful beyond the schema's bare 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 it performs a ping scan on a target with optional args, distinguishing it from sibling tools like syn_scan or udp_scan which use different scan types. However, it could be more specific about what a ping scan entails (e.g., ICMP echo requests).

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 arp_discovery or portscan_only. The description does not specify typical use cases or prerequisites.

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

portscan_onlyB

Perform a port scan only on the specified target with optional custom arguments.

Args: target (str): The target IP address or hostname. args (str): Additional Nmap command-line arguments.

Returns: dict: The port scan results.

ParametersJSON Schema

Name	Required	Description	Default
`target`	Yes
`args`	No

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description carries full burden. It fails to disclose behavioral traits such as potential intrusiveness, required permissions (e.g., root), or rate limits. The return value is only vaguely described as 'dict: The port scan results'.

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 very concise with no wasted sentences. It uses a clear structure with Args and Returns sections, making it easy to parse quickly.

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 2 parameters, no output schema, and no annotations, the description lacks completeness. It does not explain the default scan type, how results are structured, or how this tool differs from the many sibling scanning tools.

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?

Schema coverage is 0%, so the description adds value by explaining that target is an IP/hostname and args are additional Nmap arguments. However, it could be more specific about valid argument formats and constraints.

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 'Perform a port scan only' with a specific verb and resource. However, it does not differentiate from sibling tools like syn_scan or tcp_scan, which are also port scans, leaving ambiguity about the exact type of 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 is provided on when to use this tool versus alternatives such as syn_scan, tcp_scan, or os_detection. The description does not mention prerequisites or conditions for appropriate use.

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

scan_top_portsC

Scan the top ports of the specified target with optional custom arguments.

Args: target (str): The target hostname or IP address. args (str): Additional Nmap command-line arguments.

Returns: dict: The scan results in JSON format.

ParametersJSON Schema

Name	Required	Description	Default
`target`	Yes
`args`	No

TDQS

C2.7/5.0

Behavior2/5

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

With no annotations, the description should disclose behavioral traits such as potential intrusiveness or performance impact. It only mentions scanning with Nmap args, omitting caveats like detection risk or speed implications.

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 concise with clear sections (Args, Returns). No redundant information, though it could be more front-loaded. Every sentence is relevant.

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 (custom Nmap args) and lack of output schema, the description is incomplete. It fails to explain what 'top ports' means, how results are structured, or when to prefer this over siblings.

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 input schema has no descriptions (0% coverage). The description adds minimal meaning: target is a hostname/IP, args are additional Nmap arguments. It does not clarify format, constraints, or examples, leaving ambiguity.

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 scans top ports of a target, using a specific verb and resource. However, it does not define what 'top ports' means (e.g., top 1000), which slightly reduces clarity compared to a more explicit definition.

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 syn_scan or tcp_scan. The description merely states what it does, missing an opportunity to differentiate among the many sibling scanning tools.

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

syn_scanC

Perform a SYN scan on the specified target with optional custom arguments.

Args: target (str): The target IP address or hostname. args (str): Additional Nmap command-line arguments.

Returns: dict: The SYN scan results.

ParametersJSON Schema

Name	Required	Description	Default
`target`	Yes
`args`	No

TDQS

C2.7/5.0

Behavior2/5

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

No annotations provided. Description does not disclose key behavioral traits such as that SYN scan is a half-open scan requiring root privileges, or potential detection by IDS.

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?

Description is short, front-loaded, and includes structured Args/Returns sections. However, it could be more informative without losing conciseness.

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 no output schema, no annotations, and 0% schema coverage, the description fails to explain return value structure, prerequisites (e.g., nmap), or the nature of SYN scan.

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?

Input schema has 0% description coverage. The description only restates parameter names ('target IP', 'additional args') without adding format, constraints, or examples.

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 a SYN scan on a target with optional args. However, it does not differentiate SYN scan from sibling scan tools like tcp_scan or fin_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 on when to use this tool versus alternatives (e.g., when stealth is needed). No when-not or alternative tools mentioned.

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

tcp_scanC

Perform a TCP connect scan on the specified target with optional custom arguments.

Args: target (str): The target IP address or hostname. args (str): Additional Nmap command-line arguments.

Returns: dict: The TCP scan results.

ParametersJSON Schema

Name	Required	Description	Default
`target`	Yes
`args`	No

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 bears the full burden. It mentions performing a TCP connect scan but does not disclose potential side effects, permission requirements, or risks (e.g., detectability, need for root privileges). The args parameter allows arbitrary Nmap flags, a significant safety concern left unaddressed.

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 concise, using a single sentence plus a structured docstring with Args and Returns sections. It is front-loaded with the core purpose, but the Returns section is overly terse.

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 no output schema, the description fails to adequately describe the return value ('dict: The TCP scan results' is too vague). It also omits any guidance on choosing among sibling tools, making it incomplete for an agent to decide when to invoke this tool.

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

Parameters3/5

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

The docstring adds basic meaning to the parameters: target is the IP or hostname, args are additional Nmap arguments. With 0% schema coverage, the description provides some value beyond the schema but lacks detail on input formats, constraints, or examples.

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 it performs a TCP connect scan on a specified target, specifying the verb and resource. It distinguishes itself from sibling tools like syn_scan or udp_scan by naming the scan type, though it could elaborate on what a TCP connect scan entails.

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 syn_scan or idle_scan. The description lacks any context about appropriate scenarios or when not to use it.

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

udp_scanB

Perform a UDP scan on the specified target with optional custom arguments.

Args: target (str): The target IP address or hostname. args (str): Additional Nmap command-line arguments.

Returns: dict: The UDP scan results.

ParametersJSON Schema

Name	Required	Description	Default
`target`	Yes
`args`	No

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description should disclose behaviors like privilege requirements or error handling, but it only states the basic action. Important traits are missing.

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 concise with two sentences, front-loading the main action. It is appropriately sized but could be slightly more informative without becoming 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?

Given no output schema, no annotations, and many sibling tools, the description omits return value structure, prerequisites like root privileges, and when to prefer this scan over others.

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

Parameters3/5

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

The description adds meaning to parameters beyond the schema by explaining target as 'IP address or hostname' and args as 'additional Nmap arguments', but remains vague on format or allowed values.

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

Purpose5/5

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

The description clearly states it performs a UDP scan on a target, distinguishing it from sibling tools like syn_scan or tcp_scan by specifying the protocol.

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 UDP scan versus alternatives like TCP scan or other scan types. It lacks context for appropriate usage.

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

version_detectionB

Detect service versions on the specified target with optional custom arguments.

Args: target (str): The target IP address or hostname. args (str): Additional Nmap command-line arguments.

Returns: dict: The version detection results.

ParametersJSON Schema

Name	Required	Description	Default
`target`	Yes
`args`	No

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, and the description only states the basic action. It does not disclose potential side effects, permissions needed, or behaviors like network scanning aggressiveness. The agent lacks behavioral confidence.

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 concise, starting with the main purpose. However, the Args/Returns docstring adds some redundancy. Overall, it is well-structured for quick comprehension.

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 (version detection via Nmap) and lack of output schema, the description is too brief. It does not explain return value structure or error conditions, leaving gaps for an AI agent.

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

Parameters3/5

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

With 0% schema description coverage, the description adds essential meaning by explaining 'target' as IP/hostname and 'args' as Nmap arguments. This compensates for the schema gaps, though it remains minimal.

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 detects service versions on a target, which is a specific verb-resource pair. It distinguishes from sibling tools like os_detection, ping_scan, etc., 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.

Usage Guidelines2/5

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

The description does not provide any guidance on when to use this tool versus alternatives. It lacks exclusions, prerequisites, or context for decision-making.

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.

15 tool updatesv0.1.0May 28, 2026
- First observedarp_discovery
- First observeddisable_dns_resolution
- First observeddns_brute_force
- First observedfin_scan
- First observedidle_scan
- First observedlist_scan
- First observedno_portscan
- First observedos_detection
- First observedping_scan
- First observedportscan_only
- First observedscan_top_ports
- First observedsyn_scan
- First observedtcp_scan
- First observedudp_scan
- First observedversion_detection

Install Server

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

TDQS

B3.3/5.0

Disambiguation4/5

Tools are mostly distinct, each representing a different Nmap scan type or feature (e.g., ping scan, SYN scan, OS detection). However, several port scanning tools (syn_scan, tcp_scan, fin_scan, udp_scan, portscan_only) could be confused if not read carefully, as they all perform port scanning with different techniques.

Naming Consistency4/5

All tool names use snake_case and most follow a pattern like `<type>_scan` or `<feature>_scan`. Some deviations exist, such as `disable_dns_resolution`, `os_detection`, and `scan_top_ports`, but overall the naming is predictable and readable.

Tool Count5/5

With 15 tools, the server covers a wide range of common Nmap operations without being overwhelming. Each tool addresses a specific scanning scenario, making the set well-scoped for network reconnaissance tasks.

Completeness4/5

The tools cover essential Nmap functionalities including various scan types, OS and version detection, DNS brute force, and ARP discovery. While NSE scripts and some advanced options are not exposed as separate tools, the generic `args` parameter allows for custom extensions, leaving only minor gaps.

Maintenance

ActivityInactive

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

mcpcheckup A
io.github.fpetitit
Scans remote MCP servers for protocol, security, and TLS issues; exposes scan tools via MCP.
Penetration Testing Security
22
Crimson Crawler
com.crimsoncrawler
Enrich, search, assess, and manage threat intelligence through 80+ typed MCP tools.
Security Search Research & Data
1
Kadent Scan A
so.kadent
Free, read-only security scanner for remote MCP servers, before you connect them.
Security Penetration Testing
11
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

Related MCP Servers

mcp-osint-server
Search Web Scraping Shell Access
himanshusanecha
F
license
Not graded
quality
D
maintenance
MCP server to perform various OSINT tasks by leveraging common network reconnaissance tools.
Updated a year ago (2025-03-12 16:44 UTC)
48
-
Nmap MCP Server
Security App Automation
mohdhaji87
F
license
B
quality
D
maintenance
Exposes Nmap network scanning capabilities through a Model Context Protocol (MCP) server, allowing users to perform various types of network scans including vulnerability assessment, service detection, and OS fingerprinting.
Updated 9 months ago (2025-12-18 22:28 UTC)
11
6
-
BBOT MCP Server
Penetration Testing Security Code Execution
marlinkcyber
A
license
Not graded
quality
D
maintenance
Enables users to run and manage BBOT security scans through the MCP interface. Provides comprehensive tools for executing reconnaissance scans, monitoring progress, and retrieving results with support for concurrent scanning operations.
Updated a year ago (2025-08-13 04:31 UTC)
2
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)
-

Appeared in Searches

Remote MCP servers without authentication

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/0xPratikPatil/NmapMCP'

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