Which integrations are available for this server?

Provides tools to execute Metasploit commands, search exploits, get module information, list modules, run Nmap scans, and perform vulnerability scans through the Metasploit Framework.

How do I use Metasploit MCP Server?

1. Click on "Deploy 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., "@Metasploit MCP Server Search for Apache Log4j exploits" 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.

Metasploit MCP Server

by RobertoDure

Overview Schema Source Related Servers Discussions Admin

JavaScript

Local

Metasploit MCP Server

A Model Context Protocol (MCP) server that provides AI assistants with secure access to Metasploit Framework functionality through a standardized interface. This server wraps core Metasploit capabilities into MCP tools that can be discovered and used by compatible clients.

Features

🔧 Execute Metasploit commands - Run raw Metasploit commands with built-in security validation
🔍 Search exploits - Find exploits by name, CVE, or keyword
📋 Module information - Get detailed information about any Metasploit module
📦 List modules - Browse available modules by type (exploits, auxiliaries, payloads, etc.)
🌐 Network scanning - Run Nmap scans through Metasploit's database integration
🔒 Vulnerability scanning - Execute vulnerability scans against target systems
ℹ️ Version information - Check your Metasploit installation details
🛡️ Security controls - Input sanitization and command injection prevention

Related MCP server: Metasploit MCP Server

Requirements

Node.js 16.0.0 or higher
Metasploit Framework installed and accessible via command line (msfconsole)
MCP-compatible client (Claude Desktop, VS Code with MCP extension, etc.)

Installation

Clone the repository:

git clone https://github.com/RobertoDure/metasploit-mcp-server.git
cd metasploit-mcp-server

Install dependencies:
```
npm install
```
Verify Metasploit installation:
```
msfconsole --version
```

Usage

Development Mode

npm run dev

Production Mode

npm start

The server communicates via STDIO transport, making it compatible with any MCP client that supports this transport method.

Available Tools

The MCP server exposes the following tools through the @modelcontextprotocol/sdk:

Tool Name	Description	Required Parameters	Optional Parameters
`execute-command`	Execute raw Metasploit commands with security validation	`command` (string)	None
`search-exploit`	Search for exploits by name, CVE, or keywords	`query` (string)	None
`module-info`	Get detailed information about a specific module	`modulePath` (string)	None
`list-modules`	List available modules by type	`type` (exploit\|auxiliary\|post\|payload\|encoder\|nop)	None
`get-version`	Get Metasploit Framework version information	None	None
`run-nmap-scan`	Execute Nmap scans through Metasploit's database	`target` (string)	`options` (string)
`run-vuln-scan`	Run vulnerability scans using auxiliary modules	`target` (string)	None

Tool Details

`execute-command`

Executes any valid Metasploit command
Includes input sanitization to prevent command injection
Runs in quiet, non-interactive mode for consistent output
Timeout protection (30 seconds)

`search-exploit`

Searches Metasploit's exploit database
Supports CVE numbers, exploit names, and keywords
Returns formatted results with module paths and descriptions

`module-info`

Provides comprehensive module information
Includes options, targets, payloads, and references
Works with any module type (exploits, auxiliaries, etc.)

`list-modules`

Lists modules by category with validation
Supports all major module types
Returns organized module listings

`run-nmap-scan`

Integrates with Metasploit's database features
Supports custom Nmap options
Stores results in Metasploit database for further analysis

`run-vuln-scan`

Uses auxiliary scanner modules
Currently implements SMB MS17-010 (EternalBlue) scanning
Can be extended for additional vulnerability checks

Example Usage

When connected to an MCP-compatible client, you can interact with Metasploit using natural language:

Searching and Information:

"Search for Apache Log4j exploits"
"Show me details about the EternalBlue exploit (exploit/windows/smb/ms17_010_eternalblue)"
"List all available Windows payloads"
"What auxiliary modules are available?"

Scanning and Reconnaissance:

"Run an Nmap scan against 192.168.1.100"
"Perform a stealth scan on 10.0.0.0/24 with -sS -O options"
"Check if 192.168.1.50 is vulnerable to MS17-010"

System Information:

"What version of Metasploit am I running?"
"Execute the 'help' command to see available commands"

Sample Responses

The server returns structured JSON responses:

{
  "success": true,
  "output": "Metasploit Framework Console Output...",
  "command": "search apache"
}

Or in case of errors:

{
  "success": false,
  "output": "Command contains potentially dangerous characters",
  "error": "Security violation"
}

Architecture

The server follows a clean, modular architecture:

src/
├── index.js                     # Main MCP server with tool registrations
└── services/
    └── metasploit-service.js    # Metasploit Framework integration layer

tests/
└── metasploit-service.test.js   # Unit tests with Jest

Key Components

McpServer: Uses @modelcontextprotocol/sdk for MCP protocol implementation
MetasploitService: Encapsulates all Metasploit interactions with security controls
StdioServerTransport: Handles communication via STDIO for client compatibility
Zod Schemas: Provides runtime type validation for all tool inputs

Security Features

Input Sanitization: Removes dangerous shell characters (;&|$()`)
Command Validation: Ensures commands are non-empty strings
Timeout Protection: 30-second timeout on all command executions
Error Handling: Comprehensive error responses with structured formatting
Module Type Validation: Strict validation for module type parameters

Configuration

Package Configuration

The server is configured as an ES module with the following key settings:

{
  "name": "metasploit-mcp-server",
  "version": "1.0.0",
  "type": "module",
  "main": "src/index.js",
  "engines": {
    "node": ">=16.0.0"
  }
}

Dependencies

Production Dependencies:

@modelcontextprotocol/sdk (^1.12.0) - MCP protocol implementation
zod (^3.22.4) - Runtime type validation and schema definition

Development Dependencies:

jest (^29.7.0) - Testing framework with ES module support
eslint (^8.57.0) - Code linting and style enforcement

MCP Client Configuration

For Claude Desktop, add to your MCP settings:

{
  "mcpServers": {
    "metasploit": {
      "command": "node",
      "args": ["src/index.js"],
      "cwd": "/path/to/metasploit-mcp-server"
    }
  }
}

For VS Code with MCP extension:

{
  "mcpServers": {
    "metasploit-mcp-server": {
      "command": "npm",
      "args": ["start"],
      "cwd": "/path/to/metasploit-mcp-server"
    }
  }
}

Security Considerations

⚠️ Important Security Notice

This MCP server provides direct access to Metasploit Framework capabilities. Please observe these security guidelines:

🔒 Access Control

No built-in authentication - Consider adding authentication for production use
Local access recommended - Avoid exposing this server to untrusted networks
Principle of least privilege - Run with minimal required system permissions

🛡️ Built-in Security Features

Command sanitization - Prevents command injection attacks
Input validation - All parameters are validated using Zod schemas
Timeout protection - 30-second execution limits prevent hanging processes
Error isolation - Failures are contained and don't crash the server

⚖️ Legal and Ethical Considerations

Authorization required - Only use against systems you own or have explicit permission to test
Responsible disclosure - Follow responsible disclosure practices for discovered vulnerabilities
Compliance - Ensure usage complies with local laws and organizational policies
Documentation - Maintain records of authorized testing activities

🔧 Recommended Deployment Practices

Run in isolated/sandboxed environments
Use dedicated testing networks
Implement network-level access controls
Monitor and log all activities
Regular security updates for dependencies

🚨 Risk Awareness

Commands executed have the same privileges as the user running the server
Metasploit modules can perform invasive actions on target systems
Some modules may cause service disruption or system instability
Always test in non-production environments first

Development

Scripts

# Start in development mode with file watching
npm run dev

# Run production server
npm start

# Run tests with Jest
npm test

# Run tests in watch mode
npm run test:watch

# Lint code with ESLint
npm run lint

# Fix linting issues automatically
npm run lint:fix

Testing

The project includes comprehensive Jest tests:

# Run all tests
npm test

# Generate coverage report
npm test -- --coverage

# Watch mode for development
npm run test:watch

Test coverage includes:

✅ Command execution validation
✅ Security sanitization
✅ Error handling
✅ Module type validation
✅ Input validation edge cases

Project Structure

metasploit-mcp-server/
├── src/
│   ├── index.js                   # MCP server entry point
│   └── services/
│       └── metasploit-service.js  # Metasploit integration
├── tests/
│   └── metasploit-service.test.js # Unit tests
├── package.json                   # Dependencies and scripts
├── jest.config.json              # Jest testing configuration
└── README.md                     # Documentation

Extending the Server

Adding New Tools

To add new Metasploit capabilities:

Add a method to MetasploitService:

async myNewFeature(param) {
  return this.executeCommand(`my_command ${param}`);
}

Register the tool in index.js:

server.registerTool("my-new-tool", {
  title: "My New Tool",
  description: "Description of what it does",
  inputSchema: {
    param: z.string().describe("Parameter description")
  }
}, async ({ param }) => {
  const result = await metasploitService.myNewFeature(param);
  return {
    content: [{ type: "text", text: JSON.stringify(result, null, 2) }]
  };
});

Add tests:

describe('myNewFeature', () => {
  it('should execute the new feature', async () => {
    // Test implementation
  });
});

Custom Module Integration

For specific module integrations, you can create specialized methods:

async scanForWebVulns(target) {
  const commands = [
    `use auxiliary/scanner/http/dir_scanner`,
    `set RHOSTS ${target}`,
    `run`,
    `back`
  ].join('; ');
  
  return this.executeCommand(commands);
}

Error Handling Patterns

Follow the established error handling pattern:

if (!param || typeof param !== 'string') {
  return {
    success: false,
    output: 'Invalid parameter',
    error: 'Validation failed'
  };
}

Troubleshooting

Common Issues

Metasploit not found:

# Ensure Metasploit is in PATH
which msfconsole

# Or check installation
msfconsole --version

Permission errors:

# Check file permissions
ls -la src/index.js

# Ensure Node.js has execution rights
chmod +x src/index.js

Module import errors:

Verify "type": "module" is set in package.json
Use .js extensions in all import statements
Check Node.js version (requires >=16.0.0)

MCP client connection issues:

Verify STDIO transport is being used correctly
Check that the server starts without errors
Ensure the client configuration points to the correct path

Debug Mode

Enable debug logging by setting environment variables:

DEBUG=mcp* npm start

Performance Tuning

For better performance with large scans:

// Increase timeout for long-running operations
const { stdout, stderr } = await execAsync(fullCommand, { 
  timeout: 60000  // 60 seconds
});

License

MIT License - see LICENSE file for details.

Contributing

Contributions are welcome! Please follow these guidelines:

Fork the repository and create a feature branch
Write tests for new functionality
Follow the existing code style (use ESLint)
Update documentation as needed
Submit a pull request with a clear description

Development Workflow

# Clone your fork
git clone https://github.com/yourusername/metasploit-mcp-server.git

# Install dependencies
npm install

# Create a feature branch
git checkout -b feature/new-tool

# Make changes and test
npm test
npm run lint

# Commit and push
git commit -m "Add new tool for X"
git push origin feature/new-tool

Code Standards

Use ES modules (import/export)
Follow JSDoc documentation style
Maintain test coverage above 80%
Use meaningful variable and function names
Handle errors gracefully with structured responses

Happy hacking! 🚀🔒

Available Tools

7 tools

execute-commandExecute Metasploit CommandC

Execute a raw Metasploit command

ParametersJSON Schema

Name	Required	Description	Default
`command`	Yes	The Metasploit command to execute

TDQS

C2.8/5.0

Behavior2/5

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

No annotations are provided, so the description must carry the full behavioral burden. It gives no indication of potential danger, side effects, output behavior, or whether commands run in a persistent session. The word 'raw' hints at arbitrary execution, but the description does not disclose the resulting risks or expected behavior.

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

Conciseness3/5

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

The description is very short and free of redundancy, but it is under-specified rather than deliberately concise. It does not add enough value beyond the title and schema to be considered a well-structured tool definition.

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

Completeness2/5

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

For a raw command execution tool with no annotations and no output schema, the description is too thin. It does not clarify the expected command format, what output will be returned, or any safety considerations, leaving an agent to guess important call details.

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 100%, so the baseline is 3. The description adds no meaning beyond the schema's 'The Metasploit command to execute', and provides no syntax, examples, or accepted command formats, but the schema already documents the parameter adequately.

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 a specific verb and resource: execute a raw Metasploit command. It distinguishes this general-purpose tool from the more specialized sibling tools like search-exploit or run-vuln-scan, although it does not explain exactly what 'raw' means in practice.

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?

There is no guidance on when to use this tool versus the specialized siblings, no exclusions, and no mention of safer alternatives. The word 'raw' weakly implies it is for commands not covered by other tools, but this is left entirely to inference.

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

get-versionGet VersionA

Get Metasploit version information

ParametersJSON Schema

Name	Required	Description	Default
No parameters

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 of behavioral disclosure. It describes the action as retrieving version information, which implies a read-only operation, but it doesn't explicitly state whether it returns the version as a string, requires a running Metasploit instance, or has any side effects. For a simple informational tool, this is adequate but not rich.

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?

A single, clear sentence with no extraneous information. Exactly as concise as needed for a simple zero-parameter getter.

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 simplicity (zero params, no output schema, no annotations), the description is mostly complete for an agent to know what the tool does. However, it lacks context about the return format or any prerequisites (e.g., requires Metasploit to be installed/running), which could matter for an agent deciding whether to call it.

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

Parameters4/5

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

The tool has zero parameters and the schema coverage is 100% (vacuously, since there are no properties). The description adds no parameter details because there are none to add. Baseline for 0 params is 4, and the description doesn't introduce confusion.

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 ('Get') and the resource ('Metasploit version information'), using a specific verb and object. It is distinguishable from siblings like execute-command or run-vuln-scan, though it doesn't explicitly differentiate itself from potential version-related tools.

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

Usage Guidelines3/5

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

The description implies a simple use case: retrieving version info. However, it does not state when to use this over alternatives or any context like 'call before other operations to verify environment' – but for a zero-parameter read-only informational tool, the implied usage is fairly obvious.

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

list-modulesList ModulesB

List available modules by type

ParametersJSON Schema

Name	Required	Description	Default
`type`	Yes	Module type

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It merely states the action without describing return format, scope of 'available,' pagination, permissions, or error behavior. 'List' implies read-only, but that is implicit rather than disclosed.

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 four words and completely free of redundancy. Every word contributes to the core purpose, and the key scoping phrase 'by type' is present.

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 one-parameter tool with a rich enum schema, the input side is well covered. However, there is no output schema and no indication of what the returned module list contains, which leaves an agent uncertain about downstream use.

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 schema fully documents the single required parameter with an enum and description, so the schema does the heavy lifting. The description's 'by type' adds only minimal reinforcement of the parameter's role.

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 'List available modules by type' clearly states the verb (list), resource (modules), and the key scoping dimension (by type). It is distinguishable from siblings like module-info by the list-versus-detail contrast, though it does not explicitly name that distinction.

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 choose this tool over alternatives such as module-info or search-exploit. The phrase 'by type' implies a use case, but there is no explicit when-to-use or when-not-to-use guidance.

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

module-infoModule InformationC

Get information about a specific Metasploit module

ParametersJSON Schema

Name	Required	Description	Default
`modulePath`	Yes	Full path to the module (e.g., exploit/windows/smb/ms17_010_eternalblue)

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description must carry the burden of behavioral disclosure, but it only says 'Get information', implying a read operation. It does not explain what happens for invalid paths, whether the module is loaded or executed, what return data to expect, or any side effects or prerequisites.

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 front-loaded sentence with no filler. It is efficiently concise, though the terseness means it omits behavioral and return-value details.

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

Completeness2/5

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

With no output schema, the description should clarify what 'information' means and what the agent will receive, but it doesn't. It also lacks context for how this tool differs from list-modules or search-exploit, leaving an agent uncertain about when to invoke it.

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 schema description already fully documents modulePath with a concrete example. The description adds no extra parameter semantics beyond 'specific Metasploit module', so with 100% schema coverage, a baseline of 3 is appropriate.

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

Purpose4/5

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

The description 'Get information about a specific Metasploit module' states a clear verb and resource, and the 'specific' qualifier differentiates it from sibling list-modules. However, 'information' is vague and does not define the scope of the data returned, so it doesn't fully separate it from search-exploit.

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 about when to use this tool versus siblings. It neither names alternatives like list-modules or search-exploit, nor states that a known modulePath is required. The agent must infer usage from the parameter schema.

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

run-nmap-scanRun Nmap ScanC

Run a nmap scan using Metasploit

ParametersJSON Schema

Name	Required	Description	Default
`target`	Yes	Target IP or hostname
`options`	No	Additional nmap options

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of disclosing behavior. It only says 'Run a nmap scan using Metasploit,' which names the operation but not what happens afterward, whether results are returned, how long the scan may take, or what side effects occur. For a scan tool with no output schema, this is a significant transparency 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 sentence with no filler. It front-loads the primary action and adds one useful contextual detail ('using Metasploit') without redundant phrasing. It is economically written and easy to parse.

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 that there is no output schema and no annotations, the description needs to explain what the agent should expect from the scan, such as output format, success/failure signals, or whether results are returned directly. It provides none of this context. The tool may be callable, but an agent receives no guidance about the outcome or edge 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 100%, so the schema already documents target and options adequately. The description adds no parameter-level meaning beyond the schema. Since the schema does the heavy lifting, the baseline score of 3 is appropriate.

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 a specific action and resource: 'Run a nmap scan using Metasploit.' It clearly identifies the tool as a network scanning operation, and the nmap vs. vulnerability scan distinction separates it from the sibling run-vuln-scan. However, it does not explicitly contrast itself with any sibling, so it stops short of full differentiation.

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 gives no guidance about when to use this tool versus alternatives such as run-vuln-scan or execute-command. There is no mention of prerequisites, target selection criteria, or conditions where another tool would be more appropriate. The usage context can only be guessed from the tool name.

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

run-vuln-scanRun Vulnerability ScanC

Run a vulnerability scan on a target

ParametersJSON Schema

Name	Required	Description	Default
`target`	Yes	Target IP or hostname

TDQS

C2.7/5.0

Behavior1/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Run a vulnerability scan on a target' and does not disclose side effects, scan type, authentication needs, network impact, or expected output.

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 short sentence with no wasted words and is easy to parse. However, it essentially restates the tool title, so it is concise but not especially informative.

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

Completeness2/5

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

For a tool that executes an active scan, this description is under-specified. There is no output schema, no annotation safety context, and no information about scan scope, credentials, output format, or relation to sibling tools. An agent would not know what to expect after invoking it.

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 coverage is 100%, and the schema already documents the single 'target' parameter as 'Target IP or hostname'. The description adds no extra parameter meaning, so the baseline score of 3 is appropriate.

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 a specific verb ('Run') and a clear resource ('a vulnerability scan on a target'). It is understandable, but it does not differentiate the tool from sibling run-nmap-scan or explain what kind of vulnerability scan is intended.

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 gives no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or how this differs from run-nmap-scan, search-exploit, or execute-command.

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

search-exploitSearch ExploitsB

Search for exploits by name or CVE

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Search query (e.g., name, CVE number)

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 carries the full burden. It states the action but does not disclose behavior such as whether the search is local or external, rate limits, or what happens if no exploits are found. This is a minimal but not misleading disclosure.

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 one short sentence that is direct and front-loaded. No filler or redundant information.

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 is thin. It does not mention expected output format, potential errors, or integration with other tools, leaving the agent without enough context for confident invocation.

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 100%, so the schema already explains the query parameter. The description adds the example 'name, CVE number', which is helpful but not deeply informative beyond the 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 a specific verb ('Search') and resource ('exploits') and specifies the search can be by name or CVE. While it doesn't explicitly differentiate from sibling tools like run-vuln-scan or list-modules, the focus on exploit lookup by query is reasonably distinct.

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 usage for exploit discovery, but does not explicitly state when to use this tool over alternatives like run-vuln-scan or list-modules. An agent would infer it is for quick exploit searches, but clearer routing guidance is absent.

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.

7 tool updatesv1.0.0Sep 6, 2026
- First observedexecute-command
- First observedget-version
- First observedlist-modules
- First observedmodule-info
- First observedrun-nmap-scan
- First observedrun-vuln-scan
- First observedsearch-exploit

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.2/5.0

Scored 2026-09-06 14:00 across 7 tools

Disambiguation4/5

Most tools have clearly distinct purposes: versioning, raw command execution, module discovery, and scanning are separate concerns. Some overlap exists between search-exploit and list-modules, and between run-nmap-scan and run-vuln-scan, but the descriptions are clear enough to avoid major misselection.

Naming Consistency4/5

Tool names mostly follow a hyphenated verb_noun pattern like get-version, search-exploit, and list-modules. The name module-info deviates by leading with a noun instead of a verb, and run- is repeated twice, but the overall convention is consistent and readable.

Tool Count5/5

Seven tools is a well-scoped size for a Metasploit-oriented server. Each tool represents a meaningful capability without unnecessary duplication or bloat, and the count fits comfortably within the ideal range.

Completeness3/5

The tool surface covers discovery, information gathering, scanning, and raw command execution, which are core Metasploit workflows. However, there are notable gaps in high-level exploit execution, session management, and workspace/database controls, leaving agents reliant on the generic execute-command for these important actions.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Singularity - MCP Discovery & Security Gateway AOAuth
io.github.gaurav-kumar-sinha-060705
Find, vet, and run MCP tools through a secure audited gateway with prompt-injection risk scoring
Security Developer Tools
511
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
Exploit Intelligence Platform — CVE, Vulnerability and Exploit Database A
com.exploit-intel
Real-time CVE, exploit, and vulnerability intelligence for AI assistants (350K+ CVEs, 115K+ PoCs)
Security Penetration Testing Monitoring
2
StrixOAuth
ai.strix
AI pentesting: run scans, triage vulnerabilities, review PRs, manage schedules and assets.
Penetration Testing Version Control
1

Related MCP Servers

Vibehacker Metasploit MCP
Penetration Testing Autonomous Agents Security
foolsec
A
license
Not graded
quality
D
maintenance
A FastMCP-based interface for Metasploit Framework, enabling AI agents to interact with Metasploit capabilities for exploitation, payload generation, target scanning, and session management.
Updated a year ago (2025-03-30 00:48 UTC)
14
Apache 2.0
Metasploit MCP Server
Penetration Testing Autonomous Agents Shell Access
GH05TCREW
A
license
Not graded
quality
D
maintenance
Provides a bridge between large language models and the Metasploit Framework, enabling AI assistants to access and control penetration testing functionality through natural language.
Updated 7 months ago (2026-02-05 16:43 UTC)
727
Apache 2.0
MSFConsole MCP Server
Penetration Testing Security Autonomous Agents
LYFTIUM-INC
A
license
Not graded
quality
D
maintenance
Enables secure integration with Metasploit Framework for AI assistants, providing comprehensive access to penetration testing tools, module management, payload generation, and database operations. Designed for authorized security testing and defensive analysis with 28 specialized tools covering complete MSF functionality.
Updated 7 months ago (2026-02-27 01:40 UTC)
8
MIT
MSFConsole MCP Server
Penetration Testing Security Command Line
PreistlyPython
-
license
Not graded
quality
Not graded
maintenance
Enables AI assistants to interact with Metasploit Framework through 28 comprehensive tools for penetration testing and security analysis. Provides secure, structured access to MSF modules, database operations, session management, and payload generation capabilities.
Updated a year ago (2025-08-20 18:40 UTC)
2
-