Metasploit MCP Server
Server Quality Checklist
Latest release: v1.0.0
- 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/5Tool 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/5Seven 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/5The 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.
Average 3/5 across 7 of 7 tools scored.
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 status not available
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.jsonto 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 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/5Is 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/5Given 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/5Does 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/5Does 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/5Does 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.
- 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/5Is 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/5Given 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/5Does 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/5Does 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/5Does 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.
- 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/5Is 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/5Given 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/5Does 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/5Does 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/5Does 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.
- 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/5Is 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/5Given 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/5Does 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/5Does 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/5Does 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.
- 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/5Is 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/5Given 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/5Does 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/5Does 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/5Does 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.
- 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/5Is 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/5Given 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/5Does 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/5Does 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/5Does 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.
- 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/5Is 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/5Given 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/5Does 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/5Does 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/5Does 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.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/RobertoDure/metasploit-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server