Enumerate open Amazon S3 buckets using Gobuster's S3 bucket enumeration mode.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@gobuster-mcp Scan example.com for hidden directories"
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.
A Model Context Protocol (MCP) server for Gobuster - a powerful directory/file, DNS, virtual host, S3 bucket, and TFTP enumeration tool written in Go.
This MCP server enables AI assistants to perform security reconnaissance and enumeration tasks by executing Gobuster commands on a remote Kali Linux host via SSH.
Directory/File Enumeration (gobuster_dir) - Discover hidden directories and files on web servers
DNS Subdomain Enumeration (gobuster_dns) - Find subdomains for target domains
Virtual Host Discovery (gobuster_vhost) - Enumerate virtual hosts by brute-forcing Host headers
Fuzzing (gobuster_fuzz) - Replace FUZZ keyword in URLs, headers, or POST data
S3 Bucket Enumeration (gobuster_s3) - Discover open Amazon S3 buckets
TFTP Enumeration (gobuster_tftp) - Find files on TFTP servers
Async Scan Support - Run long scans in background with status tracking
Wordlist Discovery - List available wordlists on the Kali host
Related MCP server: HackBridge
Node.js 18+
SSH access to a Kali Linux host with Gobuster installed
SSH key-based authentication configured (no password prompts)
# Clone the repository
git clone https://github.com/schwarztim/sec-gobuster-mcp.git
cd sec-gobuster-mcp
# Install dependencies
npm install
# Build
npm run buildVariable | Default | Description |
|
| SSH hostname or alias for the Kali Linux host |
Ensure your SSH config (~/.ssh/config) has an entry for your Kali host:
Host kali
HostName 192.168.1.100
User root
IdentityFile ~/.ssh/id_rsaAdd to your Claude Desktop config (~/.config/claude/claude_desktop_config.json on Linux or ~/Library/Application Support/Claude/claude_desktop_config.json on macOS):
{
"mcpServers": {
"gobuster": {
"command": "node",
"args": ["/path/to/sec-gobuster-mcp/dist/index.js"],
"env": {
"KALI_HOST": "kali"
}
}
}
}Directory/file enumeration mode - discovers hidden directories and files on web servers.
{
"url": "https://example.com",
"extensions": "php,html,txt",
"threads": 20,
"status_codes": "200,204,301,302",
"exclude_status": "404,403"
}DNS subdomain enumeration - discovers subdomains for a target domain.
{
"domain": "example.com",
"resolver": "8.8.8.8",
"show_ips": true,
"show_cname": true
}Virtual host enumeration - discovers virtual hosts by brute-forcing Host header values.
{
"url": "https://example.com",
"domain": "example.com",
"exclude_length": "1234"
}Fuzzing mode - replaces FUZZ keyword in URLs, headers, or POST data.
{
"url": "https://example.com/api?param=FUZZ",
"method": "GET",
"exclude_status": "404,500"
}Amazon S3 bucket enumeration.
{
"wordlist": "/usr/share/wordlists/bucket-names.txt",
"max_files": 10
}TFTP file enumeration.
{
"server": "192.168.1.50",
"timeout": 5
}All scan tools support an async parameter to run scans in the background:
{
"url": "https://example.com",
"async": true
}Use these tools to manage async scans:
gobuster_status - Check scan status and retrieve output
gobuster_stop - Stop a running scan
gobuster_list_scans - List all active and recent scans
List available wordlists on the Kali host.
{
"category": "dirb"
}Categories: all, dirb, dirbuster, wfuzz, seclists, subdomains
Most scan tools support these common options:
Option | Description |
| Path to wordlist file on Kali |
| Number of concurrent threads (default: 10) |
| Request timeout in seconds |
| Suppress banner output |
| Cookies to include in requests |
| Custom headers array |
| Custom User-Agent string |
| Skip TLS certificate verification |
| Follow HTTP redirects |
This tool is intended for authorized security testing only. Always ensure you have proper authorization before scanning any systems.
Use only against systems you own or have explicit permission to test
Be aware of rate limiting and server load
Consider legal implications in your jurisdiction
Use responsibly and ethically
# Watch mode for development
npm run dev
# Build
npm run build
# Run
npm startMIT License - see LICENSE file for details.
Contributions are welcome! Please feel free to submit a Pull Request.
Gobuster - The underlying enumeration tool
Model Context Protocol - The protocol specification
MCP SDK - TypeScript SDK for MCP
Directory/file enumeration mode - discovers hidden directories and files on web servers using wordlist-based brute forcing. Executes on remote Kali host via SSH.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Target URL (e.g., https://example.com or https://example.com/path) | |
| async | No | Run scan asynchronously and return scan ID (default: false) | |
| quiet | No | Don't print banner and other noise (default: false) | |
| cookies | No | Cookies to use for requests (e.g., session=abc123) | |
| headers | No | Custom headers (e.g., ['Authorization: Bearer token', 'X-Custom: value']) | |
| threads | No | Number of concurrent threads (default: 10) | |
| timeout | No | HTTP timeout in seconds (default: 10) | |
| expanded | No | Expanded mode, print full URLs (default: false) | |
| wordlist | No | Path to wordlist file on Kali (default: /usr/share/wordlists/dirb/common.txt) | |
| extensions | No | File extensions to search for, comma-separated (e.g., php,html,txt,js) | |
| user_agent | No | Custom User-Agent string | |
| show_length | No | Show response length (default: true) | |
| status_codes | No | Positive status codes to match, comma-separated (e.g., 200,204,301,302) | |
| exclude_status | No | Status codes to exclude, comma-separated (e.g., 404,403) | |
| follow_redirect | No | Follow redirects (default: false) | |
| no_tls_validation | No | Skip TLS certificate verification (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses some behavioral traits such as executing remotely via SSH and using wordlist-based brute forcing. However, it omits details about active scanning consequences, rate limits, or how results are returned, leaving gaps 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, front-loaded with the core purpose. It is concise, free of redundancy, and quickly conveys what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (16 parameters) and lack of an output schema, the description covers the core purpose and remote execution but does not explain expected output, interpretation of results, or typical usage nuances. This leaves the tool under-specified for an agent unfamiliar with gobuster's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage for all 16 parameters, so the baseline is met. The description adds minimal extra meaning beyond mentioning wordlist-based brute forcing, which loosely relates to the wordlist parameter but doesn't enhance understanding of any specific parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function as 'Directory/file enumeration mode' with the objective to discover hidden directories and files on web servers. It distinguishes itself from sibling tools like gobuster_dns and gobuster_vhost by focusing on path brute-forcing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by specifying this mode is for directory/file enumeration via wordlist-based brute forcing, implying when to use it. However, it doesn't explicitly exclude alternatives or mention when not to use it, stopping short of full prescriptive guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
DNS subdomain enumeration mode - discovers subdomains for a target domain using wordlist-based brute forcing. Executes on remote Kali host via SSH.
| Name | Required | Description | Default |
|---|---|---|---|
| async | No | Run scan asynchronously and return scan ID (default: false) | |
| quiet | No | Don't print banner and other noise (default: false) | |
| domain | Yes | Target domain (e.g., example.com) | |
| threads | No | Number of concurrent threads (default: 10) | |
| timeout | No | DNS timeout in seconds (default: 1) | |
| resolver | No | Custom DNS resolver (e.g., 8.8.8.8 or 8.8.8.8:53) | |
| show_ips | No | Show IP addresses for found subdomains (default: true) | |
| wildcard | No | Force wildcards check (default: false) | |
| wordlist | No | Path to wordlist file on Kali (default: /usr/share/wordlists/subdomains-top1million-5000.txt) | |
| show_cname | No | Show CNAME records (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden of behavioral disclosure. It reveals that the tool executes on a remote Kali host via SSH and uses wordlist-based brute forcing, which are meaningful traits. However, it omits side effects, async scan behavior, result output, and potential rate-limit impact, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and front-loads the essential purpose. Every word earns its place, with no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters) and lack of output schema, the description is too sparse. It fails to mention return values, async/sync behavior, scan lifecycle (e.g., using gobuster_status), or how to interpret results. These are critical for an agent to correctly invoke the tool and use its output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so every parameter has a description. The tool description adds minimal semantics beyond the schema, only framing the operation as 'wordlist-based brute forcing'. It does not elaborate on how parameters interact or provide usage examples, fitting the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is the 'DNS subdomain enumeration mode' and specifies the verb 'discovers' with the resource 'subdomains for a target domain'. This unambiguously differentiates it from sibling tools like gobuster_dir (directory brute-forcing) and gobuster_vhost (virtual host discovery).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'DNS subdomain enumeration mode' implies the tool is for discovering DNS subdomains, which guides selection among the gobuster family. It also notes remote execution via SSH, giving context. However, it does not explicitly state when NOT to use it or name alternative tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fuzzing mode - replaces the FUZZ keyword in URLs, headers, or POST data with wordlist entries. Useful for parameter discovery and testing. Executes on remote Kali host via SSH.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Target URL containing FUZZ keyword (e.g., https://example.com?param=FUZZ) | |
| async | No | Run scan asynchronously and return scan ID (default: false) | |
| quiet | No | Don't print banner and other noise (default: false) | |
| method | No | HTTP method (default: GET, or POST if post_data provided) | |
| cookies | No | Cookies to use for requests | |
| headers | No | Custom headers, can contain FUZZ keyword (e.g., ['X-Custom-Header: FUZZ']) | |
| threads | No | Number of concurrent threads (default: 10) | |
| timeout | No | HTTP timeout in seconds (default: 10) | |
| wordlist | No | Path to wordlist file on Kali (default: /usr/share/wordlists/dirb/common.txt) | |
| post_data | No | POST data containing FUZZ keyword (e.g., username=admin&password=FUZZ) | |
| exclude_length | No | Response lengths to exclude, comma-separated | |
| exclude_status | No | Status codes to exclude, comma-separated | |
| no_tls_validation | No | Skip TLS certificate verification (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the core behavior (FUZZ replacement) and importantly notes that it 'Executes on remote Kali host via SSH.' However, it does not mention potential side effects (e.g., generating significant network traffic), the meaning of async, or result format, leaving some uncertainty for a complex 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with no redundancy. The most critical information (FUZZ replacement) is front-loaded, followed by use case and execution context. Every sentence earns its place without unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a tool with 13 well-documented parameters, but it lacks information about output format or workflow (e.g., how results are returned, when to use async). Since there is no output schema, some guidance on return values would improve completeness. The description is not deficient enough to score 2, but it leaves practical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage, so every parameter is already well-documented (e.g., url, headers, post_data). The description adds little beyond what the schema provides, merely summarizing that FUZZ can appear in URLs, headers, or POST data, which is already evident from parameter descriptions. Thus, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Fuzzing mode - replaces the FUZZ keyword in URLs, headers, or POST data with wordlist entries.' This specific verb+resource (replaces in fuzz mode) distinguishes it from sibling tools like gobuster_dir or gobuster_dns, making its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear use case: 'Useful for parameter discovery and testing.' While it doesn't explicitly name alternatives or say 'use this instead of X', the stated purpose effectively guides when to choose fuzzing over directory or DNS brute-forcing. The mention of remote Kali execution adds context for deployment.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all active and recent gobuster scans
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. 'List' implies a read-only operation, and there are no side effects mentioned, which is appropriate for a simple list tool. However, it does not explicitly state whether authentication is required or what constitutes 'recent', leaving some ambiguity about the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the tool's function without any filler words. It is front-loaded with the verb 'List' and the resource, making it immediately clear and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description adequately states what the tool does. It includes the key qualifiers 'active and recent' to set expectations. However, it does not describe the output format or fields, which could be valuable given the lack of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty with 100% coverage. Per the rubric, 0 parameters gives a baseline of 4, and the description correctly implies that no parameters are needed. There is no additional parameter meaning to convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List all active and recent gobuster scans' – a specific verb ('List') and resource ('gobuster scans') with a clear scope ('active and recent'). This distinguishes it from sibling tools like gobuster_status (which checks a specific scan) and gobuster_stop (which stops scans).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (to get an overview of active and recent scans) but provides no explicit guidance on when to use it versus alternatives like gobuster_status or gobuster_stop. It is left to the agent to infer the tool's role from the sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Amazon S3 bucket enumeration mode - discovers open S3 buckets using wordlist-based brute forcing. Executes on remote Kali host via SSH.
| Name | Required | Description | Default |
|---|---|---|---|
| async | No | Run scan asynchronously and return scan ID (default: false) | |
| quiet | No | Don't print banner and other noise (default: false) | |
| threads | No | Number of concurrent threads (default: 10) | |
| wordlist | Yes | Path to wordlist file containing bucket names on Kali | |
| max_files | No | Maximum files to list when bucket is listable (default: 5) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool performs wordlist-based brute forcing and executes on a remote Kali host via SSH. However, it does not mention whether the scan is read-only, potential rate limits, authentication needs, or any side effects. While 'discovers open S3 buckets' suggests non-destructive reconnaissance, more operational transparency would be expected 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and execution context. Every word earns its place, with no redundant or marketing language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 params, no output schema), the description covers the main purpose and execution environment but omits details about expected output/return values, potential impact of the scan, and how to handle results. The schema covers parameters, but the description alone would not fully prepare an agent for what happens after invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the baseline is 3. The description adds context around the wordlist parameter by mentioning 'wordlist-based brute forcing', but it doesn't clarify parameter syntax, formats, or relationships beyond what the schema already provides. No additional parameter semantics are introduced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Amazon S3 bucket enumeration mode - discovers open S3 buckets using wordlist-based brute forcing.' It identifies both the resource (S3 buckets) and the action (enumeration), and the 'mode' phrasing distinguishes it from sibling gobuster tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: it is for discovering open S3 buckets via wordlist brute forcing. Though it doesn't name alternative tools explicitly, the 'mode' label implies it is one of several gobuster modes, and the S3-specific terminology sets it apart. No exclusions or when-not-to-use guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the status of an asynchronous gobuster scan
| Name | Required | Description | Default |
|---|---|---|---|
| scan_id | Yes | The scan ID returned from an async scan |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It only adds the word 'asynchronous' and 'status', but does not describe the return format, possible status values, error behavior for invalid scan_id, or whether the call is blocking/non-blocking. This lack of detail is a significant gap for a status-polling tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler or redundant phrasing. It stays on point and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema), but the description leaves out what a returned status looks like and how to interpret it. While it covers the basic purpose and parameter, it is just barely complete for an AI agent that needs to know what to expect from the call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the single parameter (scan_id) with a clear explanation ('The scan ID returned from an async scan'). The description adds no additional semantic value beyond reinforcing the async context, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Check the status') applied to a specific resource ('an asynchronous gobuster scan'). It is unambiguously differentiated from sibling tools like gobuster_stop (which terminates scans) and gobuster_list_scans (which enumerates scans).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a scan_id from an asynchronous scan is available, but it does not explicitly state when to use this tool over alternatives like gobuster_list_scans or gobuster_stop. There is no mention of exclusions or contextual triggers beyond the basic scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop a running asynchronous gobuster scan
| Name | Required | Description | Default |
|---|---|---|---|
| scan_id | Yes | The scan ID to stop |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states the action but does not mention consequences like irreversibility, impact on partial results, or response/confirmation behavior. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no superfluous content. It is front-loaded with the verb and resource, making it highly concise and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, so the description covers the core action. However, with no annotations and minimal guidance, it is not fully complete—missing usage context and behavioral details, though it remains adequate for a basic stop operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a clear description for scan_id ('The scan ID to stop'). The description text itself adds no additional meaning beyond the schema, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Stop') and resource ('running asynchronous gobuster scan'), clearly distinguishing it from sibling tools like gobuster_status (which checks status) and gobuster_list_scans (which lists scans).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended usage is implied: use this when you need to stop a scan. However, it does not explicitly state alternatives or exclusions, such as noting that this only applies to asynchronous scans or that you should obtain the scan ID from gobuster_list_scans.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TFTP file enumeration mode - discovers files on TFTP servers. Executes on remote Kali host via SSH.
| Name | Required | Description | Default |
|---|---|---|---|
| async | No | Run scan asynchronously and return scan ID (default: false) | |
| quiet | No | Don't print banner and other noise (default: false) | |
| server | Yes | Target TFTP server IP address | |
| threads | No | Number of concurrent threads (default: 10) | |
| timeout | No | TFTP timeout in seconds (default: 1) | |
| wordlist | No | Path to wordlist file on Kali (default: /usr/share/wordlists/dirb/common.txt) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full behavioral disclosure burden. It only adds that execution happens 'on remote Kali host via SSH', which is useful, but it fails to disclose whether the operation is read-only, potential network impact, rate limiting, or expected side effects. For an enumeration tool, this 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences with no filler. The first sentence front-loads the purpose, and the second adds critical execution context. Every word contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description should explain what results look like and any prerequisites. It does not mention return values, interpretation of results, or the need for pre-configured SSH access. For a tool with 6 parameters and no output schema, this is under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for all 6 parameters with clear descriptions. The tool description adds no extra parameter-specific meaning beyond stating the general purpose, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'TFTP file enumeration mode - discovers files on TFTP servers' which clearly identifies the verb (discovers), resource (files on TFTP servers), and distinguishes it from sibling gobuster modes like gobuster_dir or gobuster_dns. The name and description align perfectly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. It merely states what the tool does, leaving the agent to infer usage from the 'mode' label without naming alternatives or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Virtual host enumeration mode - discovers virtual hosts on a web server by brute forcing Host header values. Executes on remote Kali host via SSH.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Target URL (e.g., https://example.com) | |
| async | No | Run scan asynchronously and return scan ID (default: false) | |
| quiet | No | Don't print banner and other noise (default: false) | |
| domain | No | Domain to append to wordlist entries (--append-domain) | |
| cookies | No | Cookies to use for requests | |
| headers | No | Custom headers | |
| threads | No | Number of concurrent threads (default: 10) | |
| timeout | No | HTTP timeout in seconds (default: 10) | |
| wordlist | No | Path to wordlist file on Kali (default: /usr/share/wordlists/dirb/common.txt) | |
| user_agent | No | Custom User-Agent string | |
| exclude_length | No | Exclude results with these response lengths, comma-separated | |
| follow_redirect | No | Follow redirects (default: false) | |
| no_tls_validation | No | Skip TLS certificate verification (default: false) |
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 does disclose that the tool brute-forces Host headers and executes on a remote Kali host via SSH, which is useful context. However, it does not describe output format, potential side effects, or any safety/authorization considerations, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences with front-loaded purpose and no fluff. It efficiently states what the tool does and adds the operational detail of remote SSH execution without unnecessary wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 13 parameters and no output schema, yet the description only covers high-level behavior. It omits expected return values, error handling, and operational considerations like how results are reported, making it incomplete for a complex enumeration tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the structured schema already documents all 13 parameters. The description adds no additional meaning to the parameters, such as how they interact or typical values, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs virtual host enumeration by brute-forcing Host header values, which is a specific verb and resource. It also implicitly distinguishes itself from sibling modes like gobuster_dir and gobuster_dns by focusing on virtual hosts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives such as gobuster_dir or gobuster_dns. It lacks explicit context about prerequisites, target scenarios, or when not to use it, so the usage is only implied by the tool's name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available wordlists on the Kali host
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | Category of wordlists to list (default: all) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It discloses a read-only listing operation but does not elaborate on what kinds of wordlists are included, whether it scans local directories, or any environment dependencies. For a simple list tool, this is acceptable 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words or repetition. It is perfectly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter, no output schema, and a simple listing function, the description conveys the essential purpose. However, it does not specify the output format (e.g., file paths vs. names) or mention the category filter in the description, so it is slightly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single optional 'category' parameter with enum values and a default of 'all', giving 100% coverage. The description adds no additional parameter information, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'available wordlists', with a specific scope 'on the Kali host'. This distinguishes it from sibling tools like gobuster_dir or gobuster_list_scans, which serve different functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, but the purpose implies it is the utility for discovering wordlists before running gobuster scans. There are no explicit exclusions or alternative references, so usage guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0gobuster_dirgobuster_dnsgobuster_fuzzgobuster_list_scansgobuster_s3gobuster_statusgobuster_stopgobuster_tftpgobuster_vhostgobuster_wordlistsEach tool maps to a distinct gobuster mode (dir, dns, vhost, fuzz, s3, tftp) or management function (status, stop, list scans, wordlists), so there is no overlap or ambiguity. Agents can easily select the right tool for the target.
All tools share the 'gobuster_' prefix, but the suffix mixes mode nouns (dir, dns, vhost) with action verbs (stop, list_scans). This is predictable and readable, but not a pure verb_noun pattern throughout.
With 10 tools, the server is well-scoped for a single-purpose gobuster interface. Each enumeration mode earns its place, and management/utility tools are minimal but sufficient.
The tool set covers all standard gobuster enumeration modes and the scan lifecycle (status, stop, list). A minor gap is the lack of an explicit 'get results' tool, but status likely returns findings, so agents can work around it.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for Pentest-Tools.com: run scans, manage findings and reports via your preffered LLM.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/schwarztim/sec-gobuster-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
