Nmap MCP Server

by mohdhaji87

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.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.
Average 2.6/5 across 11 of 11 tools scored. Lowest: 2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![Nmap-MCP-Server MCP server](https://glama.ai/mcp/servers/mohdhaji87/Nmap-MCP-Server/badges/card.svg)](https://glama.ai/mcp/servers/mohdhaji87/Nmap-MCP-Server)

Score Badge

Copy to your README.md:

[![Nmap-MCP-Server MCP server](https://glama.ai/mcp/servers/mohdhaji87/Nmap-MCP-Server/badges/score.svg)](https://glama.ai/mcp/servers/mohdhaji87/Nmap-MCP-Server)

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