Which integrations are available for this server?

Allows AI assistants to run and manage feroxbuster scans on a remote Kali Linux system for web content discovery.

How do I use feroxbuster-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@feroxbuster-mcp scan https://example.com for hidden directories and files" 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.

feroxbuster-mcp

by schwarztim

Overview Schema Source Related Servers Score Discussions Admin

JavaScript

Remote

Feroxbuster MCP Server

A Model Context Protocol (MCP) server for feroxbuster - a fast, simple, recursive content discovery tool written in Rust.

Overview

This MCP server enables AI assistants to control feroxbuster scans on a remote Kali Linux system via SSH. It provides a complete interface for web content discovery with support for:

Directory and file brute-forcing with customizable wordlists
Recursive scanning with configurable depth
Flexible filtering (status codes, response size, word count, line count)
Rate limiting, auto-tuning, and auto-bail features
Background scans with real-time progress monitoring
Resume capability from state files
Multiple output formats (text, JSON, URLs)

Related MCP server: SSH MCP Server

Prerequisites

Node.js 18+
SSH access to a Kali Linux system (or any system with feroxbuster installed)
SSH key authentication configured for passwordless access (recommended)
feroxbuster installed on the remote system

Installation

git clone https://github.com/schwarztim/sec-feroxbuster-mcp.git
cd sec-feroxbuster-mcp
npm install
npm run build

Configuration

Claude Desktop / Claude Code

Add the server to your MCP configuration:

Claude Desktop (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):

{
  "mcpServers": {
    "feroxbuster": {
      "command": "node",
      "args": ["/path/to/sec-feroxbuster-mcp/dist/index.js"],
      "env": {
        "KALI_HOST": "kali"
      }
    }
  }
}

Claude Code (~/.claude/user-mcps.json):

{
  "feroxbuster": {
    "command": "node",
    "args": ["/path/to/sec-feroxbuster-mcp/dist/index.js"],
    "env": {
      "KALI_HOST": "kali"
    }
  }
}

Environment Variables

Variable	Description	Default
`KALI_HOST`	SSH hostname for the remote system with feroxbuster	`kali`

SSH Setup

Ensure SSH key authentication is configured:

# Generate key if needed
ssh-keygen -t ed25519 -C "feroxbuster-mcp"

# Copy to remote host
ssh-copy-id kali

# Test connection
ssh kali "feroxbuster --version"

Available Tools

feroxbuster_scan

Start a directory/file discovery scan against a target URL.

Parameters:

Parameter	Type	Description
`url`	string	(required) Target URL to scan
`wordlist`	string	Path to wordlist on remote system
`extensions`	string[]	File extensions to check (e.g., `["php", "html", "js"]`)
`recursion_depth`	number	Maximum recursion depth (0 = infinite, default: 4)
`threads`	number	Concurrent threads (default: 50)
`timeout`	number	Request timeout in seconds (default: 7)
`rate_limit`	number	Max requests per second per directory
`filter_status`	number[]	Status codes to exclude from results
`status_codes`	number[]	Status codes to include
`filter_size`	number[]	Response sizes to exclude
`filter_words`	number[]	Word counts to exclude
`filter_lines`	number[]	Line counts to exclude
`headers`	object	Custom headers (e.g., `{"Authorization": "Bearer token"}`)
`proxy`	string	Proxy URL (HTTP or SOCKS5)
`insecure`	boolean	Disable TLS certificate validation
`no_recursion`	boolean	Disable recursive scanning
`force_recursion`	boolean	Force recursion on all discovered paths
`auto_tune`	boolean	Automatically reduce rate on errors
`auto_bail`	boolean	Automatically stop on excessive errors
`silent`	boolean	Only output URLs (for piping)
`json`	boolean	Output results as JSON
`background`	boolean	Run scan in background
`dont_scan`	string[]	URLs to exclude from recursion
`time_limit`	string	Maximum scan time (e.g., `"10m"`, `"1h"`)
`scan_limit`	number	Maximum concurrent directory scans
`user_agent`	string	Custom User-Agent string
`cookies`	string	Cookie string to include
`data`	string	POST request body
`methods`	string[]	HTTP methods to use (default: GET)
`query`	string	Query parameters to append

feroxbuster_config

Configure default settings for subsequent scans. Accepts same filtering and connection parameters as feroxbuster_scan.

feroxbuster_status

Check the status of a running or completed scan.

Parameter	Type	Description
`tail_lines`	number	Number of output lines to show (default: 50)

feroxbuster_stop

Stop a running scan gracefully. Preserves state file for potential resume.

feroxbuster_resume

Resume a previously interrupted scan from its state file.

Parameter	Type	Description
`state_file`	string	Path to state file (optional, uses last scan)
`background`	boolean	Run resumed scan in background

feroxbuster_wordlists

List available wordlists on the remote system.

Parameter	Type	Description
`search`	string	Filter wordlists by search term
`category`	string	Category: `"common"`, `"directory"`, `"web"`, `"api"`, `"all"`

feroxbuster_results

Retrieve and format results from the last completed scan.

Parameter	Type	Description
`format`	string	Output format: `"text"`, `"json"`, `"urls"`
`filter_status`	number[]	Filter results by status codes

feroxbuster_version

Get feroxbuster version information from the remote system.

Usage Examples

Basic Scan

Scan http://target.com for directories and files

Scan with Extensions and Filtering

Scan http://target.com looking for php, html, and txt files.
Exclude 404 and 500 responses. Limit recursion to 3 levels.

Background Scan with Rate Limiting

Start a background scan of http://target.com with rate limiting
at 100 requests/second and auto-tune enabled.

Check Scan Progress

What's the status of my feroxbuster scan?

Resume an Interrupted Scan

Resume the last feroxbuster scan in the background

List Available Wordlists

Show me API-related wordlists on the Kali system

State Management

Scan state is persisted in ~/.feroxbuster-mcp/state.json:

Active scan information (PID, URL, output file, state file)
Last scan results for retrieval
Default configuration settings

This enables scan resumption and result retrieval across sessions.

Security Considerations

This tool is designed for authorized security testing only
Always obtain proper authorization before scanning any systems
Use rate limiting to avoid overwhelming target servers
Consider using the auto_bail option to stop on errors
Proxy support enables routing through Burp Suite or other tools

License

MIT License - see LICENSE for details.

Acknowledgments

feroxbuster by epi052
Model Context Protocol by Anthropic

Available Tools

8 tools

feroxbuster_configB

Configure default feroxbuster settings for subsequent scans

ParametersJSON Schema

Name	Required	Description
`wordlist`	No	Default wordlist path on Kali
`extensions`	No	Default file extensions
`recursion_depth`	No	Default recursion depth
`rate_limit`	No	Default rate limit (requests/sec)
`threads`	No	Default thread count
`timeout`	No	Default request timeout
`filter_status`	No	Default status codes to filter
`filter_size`	No	Default sizes to filter
`filter_words`	No	Default word counts to filter
`filter_lines`	No	Default line counts to filter
`headers`	No	Default headers
`proxy`	No	Default proxy URL

TDQS

B3.4/5.0

Behavior2/5

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

No annotations and minimal description; does not disclose whether settings persist globally, are overwritable, or any side effects of configuration.

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?

One sentence, zero waste, efficiently conveys the tool's purpose.

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 12 parameters and no output schema, the description lacks important context about how settings apply (e.g., session scoping) and what the tool returns.

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%, so description adds no extra meaning beyond the schema; baseline 3 is appropriate.

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

Purpose5/5

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

The description clearly states the tool configures default feroxbuster settings for subsequent scans, distinguishing it from scanning and result 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 use before scans but does not explicitly state when or when not to use it, nor does it mention alternatives.

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

feroxbuster_resultsB

Get the results from the last completed scan

ParametersJSON Schema

Name	Required	Description	Default
`format`	No	Output format (default: text)
`filter_status`	No	Filter results by status code

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations, the description must disclose behavior, but it only states the basic function. It does not mention what happens if no scan has completed, whether results are cleared after retrieval, or any side effects.

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

Conciseness4/5

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

The description is a single, concise sentence that front-loads the primary action. However, it could include more detail without becoming verbose.

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 low complexity (2 optional params, no output schema) and sibling context, the description is minimally complete but lacks details about the lifetime of results or error states.

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%, so the schema already documents both parameters. The description adds no additional meaning beyond what the schema provides (format enum, filter_status array).

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

Purpose5/5

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

The description 'Get the results from the last completed scan' clearly states the tool's verb and resource, differentiating it from siblings like feroxbuster_scan (starts a scan) and feroxbuster_status (checks status).

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives, nor on prerequisites (e.g., ensuring a scan has completed). The description omits any context for proper invocation.

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

feroxbuster_resumeA

Resume a previously interrupted feroxbuster scan from its state file

ParametersJSON Schema

Name	Required	Description	Default
`state_file`	No	Path to feroxbuster state file on Kali (optional, uses last scan if not specified)
`background`	No	Run resumed scan in background

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description must disclose behavior. It states the core action but does not mention side effects (e.g., overwriting results), state file requirements, or how the 'background' parameter affects behavior. This covers the basics but has gaps.

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 12-word sentence, concise and front-loaded. However, for a resume operation, a bit more detail (e.g., 'Resume with the same options') would improve without losing conciseness.

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 no output schema, two optional parameters, and sibling tools covering other aspects, the description is minimally complete. It states the purpose but lacks details on prerequisites (valid state file) or what happens after resuming.

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 both parameters. The description adds no additional meaning beyond what is in the schema, meeting the baseline for high coverage.

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

Purpose5/5

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

The description uses the specific verb 'Resume' and identifies the resource as 'a previously interrupted feroxbuster scan from its state file'. This clearly differentiates from sibling tools like feroxbuster_scan (starts new) and feroxbuster_status (checks status).

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

Usage Guidelines4/5

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

The description implies the tool is for resuming interrupted scans, providing clear context. However, it does not explicitly state when not to use it or mention alternatives like starting a new scan, which would improve guidance.

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

feroxbuster_scanB

Start a feroxbuster directory scan against a target URL. Executes on remote Kali system via SSH.

ParametersJSON Schema

Name	Required	Description
`url`	Yes	Target URL to scan (e.g., http://example.com)
`wordlist`	No	Path to wordlist on Kali (default: /usr/share/wordlists/seclists/Discovery/Web-Content/common.txt)
`extensions`	No	File extensions to check (e.g., ['php', 'html', 'js'])
`recursion_depth`	No	Maximum recursion depth (0 = infinite, default: 4)
`threads`	No	Number of concurrent threads (default: 50)
`timeout`	No	Request timeout in seconds (default: 7)
`rate_limit`	No	Maximum requests per second per directory
`filter_status`	No	Status codes to filter OUT (exclude from results)
`status_codes`	No	Status codes to include (default: 200,204,301,302,307,308,401,403,405,500)
`filter_size`	No	Response sizes to filter OUT
`filter_words`	No	Word counts to filter OUT
`filter_lines`	No	Line counts to filter OUT
`headers`	No	Custom headers to include (e.g., {"Authorization": "Bearer token"})
`proxy`	No	Proxy URL (e.g., http://127.0.0.1:8080 or socks5://127.0.0.1:9050)
`insecure`	No	Disable TLS certificate validation
`no_recursion`	No	Disable recursive scanning
`force_recursion`	No	Force recursion on all found paths
`auto_tune`	No	Automatically lower scan rate on errors
`auto_bail`	No	Automatically stop on excessive errors
`silent`	No	Only output URLs (for piping)
`json`	No	Output results as JSON
`background`	No	Run scan in background and return immediately
`dont_scan`	No	URLs to exclude from recursion
`time_limit`	No	Maximum scan time (e.g., '10m', '1h', '30s')
`scan_limit`	No	Maximum concurrent directory scans
`user_agent`	No	Custom User-Agent string
`cookies`	No	Cookies to include (e.g., 'session=abc123; token=xyz')
`data`	No	Request body data for POST requests
`methods`	No	HTTP methods to use (default: GET)
`query`	No	Query parameters to append (e.g., 'token=abc&debug=true')

TDQS

B3.3/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It discloses remote execution via SSH, but lacks details on whether the scan is blocking, asynchronous, how results are returned, or safety implications (e.g., network impact).

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 concise sentence, front-loads the action, and has no redundancy. However, it could be slightly expanded to improve clarity without sacrificing conciseness.

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

Completeness2/5

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

Given the tool has 30 parameters and no output schema, the description is too minimal. It does not explain parameter relationships, expected behavior of complex options (e.g., background or recursion), or how to interpret results.

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

Parameters3/5

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

Schema coverage is 100% (all parameters have descriptions), so the description adds no additional meaning. Baseline 3 is appropriate.

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

Purpose5/5

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

The description clearly states the action ('Start'), the resource ('feroxbuster directory scan'), and the target ('target URL'). It distinguishes from sibling tools like feroxbuster_config or feroxbuster_results by focusing on initiating a scan.

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

Usage Guidelines2/5

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

The description mentions remote execution via SSH but provides no guidance on when to use this tool versus siblings, such as when to stop or resume a scan, or prerequisites like having feroxbuster installed.

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

feroxbuster_statusB

Check the status of a running or completed feroxbuster scan

ParametersJSON Schema

Name	Required	Description	Default
`tail_lines`	No	Number of lines to show from output (default: 50)

TDQS

B3.4/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 full burden. It states 'Check the status' but does not disclose whether it reads state, requires a running scan, or returns any specific output format. Missing key behavioral details.

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 of 8 words, with zero waste. It is front-loaded and efficient for the purpose stated.

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

Completeness2/5

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

Given the simplicity of the tool (one optional parameter, no output schema), the description is too minimal. It does not explain what status information is returned, how to interpret it, or any prerequisites like an active scan. More context is needed for effective 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?

Schema coverage is 100% for the single parameter, which already includes a description. The tool description adds no additional meaning beyond the schema, so baseline 3 is appropriate.

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

Purpose5/5

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

The description clearly states the tool checks status of a feroxbuster scan, with specific verb and resource. It distinguishes from sibling tools like feroxbuster_results (for results) and feroxbuster_stop (for stopping).

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 checking progress but does not explicitly state when to use versus alternatives like feroxbuster_results or feroxbuster_config. No when-not or context guidance is provided.

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

feroxbuster_stopB

Stop a running feroxbuster scan

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.4/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 convey behavioral traits. It fails to disclose whether stopping is irreversible, destroys scan progress, or requires specific authorization. Minimal beyond the verb 'stop'.

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

Conciseness5/5

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

Extremely concise single sentence that front-loads the critical information. No wasted words.

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 with no parameters and no output schema, the description still lacks crucial context: it does not mention whether a scan must be active, what happens to results, or if confirmation is needed. Incomplete for safe autonomous use.

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 input schema has zero parameters, so schema coverage is 100%. The description does not need to add parameter information. No issues.

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

Purpose5/5

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

The description clearly states the action (stop) and the target (running feroxbuster scan), distinguishing it from sibling tools like feroxbuster_scan (start) and feroxbuster_resume (resume).

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives (e.g., feroxbuster_status) or any prerequisites such as having an active scan. The description lacks usage context entirely.

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

feroxbuster_versionA

Get feroxbuster version information from Kali

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.1/5.0

Behavior3/5

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

No annotations are provided, and the description lacks details on behavioral traits such as whether it is read-only, network-dependent, or the exact format of the output. However, the tool is trivial (version retrieval), so minimal disclosure is acceptable.

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 wasted words. It is perfectly concise for a tool that requires no parameters and has a straightforward purpose.

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 absence of an output schema, the description does not clarify the return format (e.g., string or JSON). While adequate for the tool's simplicity, adding output details would improve completeness.

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

Parameters4/5

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

With zero parameters and 100% schema coverage, the baseline is 4. The description does not need to add parameter information as there are none, and the schema is already complete.

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

Purpose5/5

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

The description clearly states the verb 'Get', the resource 'feroxbuster version information', and the source 'from Kali'. It is specific and distinguishes from sibling tools like feroxbuster_scan or feroxbuster_config, which have different purposes.

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

Usage Guidelines4/5

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

While the description does not explicitly state when to use or not use the tool, its simplicity and the distinct sibling tool names imply usage when version information is needed. No alternatives or exclusions are needed for such a straightforward tool.

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

feroxbuster_wordlistsC

List available wordlists on the Kali system

ParametersJSON Schema

Name	Required	Description	Default
`search`	No	Search term to filter wordlists
`category`	No	Category of wordlists to show

TDQS

C2.9/5.0

Behavior2/5

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

Description is minimal with no annotations. Does not disclose behavioral traits such as being a read-only operation or where the wordlists are sourced.

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?

Single sentence, efficiently states purpose without redundancy.

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

Completeness2/5

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

No output schema and no description of return values or behavior. With no annotations, the description is insufficient for a tool with two optional parameters.

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% with parameter descriptions. Description adds no additional meaning beyond the schema, meeting baseline.

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?

Clear verb+resource: 'List available wordlists on the Kali system'. Distinguishes from sibling tools which involve scanning or configuration.

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs alternatives, no exclusions or context provided.

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.

8 tool updatesv1.0.0Jun 19, 2026
- First observedferoxbuster_config
- First observedferoxbuster_results
- First observedferoxbuster_resume
- First observedferoxbuster_scan
- First observedferoxbuster_status
- First observedferoxbuster_stop
- First observedferoxbuster_version
- First observedferoxbuster_wordlists

Install Server

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

TDQS

A3.7/5.0

Scored 2026-06-19 14:55 across 8 tools

Disambiguation5/5

Each tool has a clear, distinct purpose (config, results, resume, scan, status, stop, version, wordlists) with no overlap.

Naming Consistency5/5

All tools follow a consistent 'feroxbuster_<noun>' pattern, using snake_case throughout.

Tool Count5/5

8 tools is appropriate for a directory scanning MCP server, covering configuration, execution, monitoring, and results.

Completeness4/5

Covers the core lifecycle (version, config, scan, status, stop, results, resume, wordlists), but lacks per-scan parameter customization beyond config.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

AgentGrade A
com.agentgrade
Scan any website for AI agent readiness, payment protocols, and discovery endpoints
Web Scraping AI & Machine Learning Agent Orchestration
43
FEDLIN Scanners A
com.fedlin
Exposes FEDLIN's public security scanners as agent-callable tools over Streamable HTTP.
Penetration Testing Testing & QA Tools
31
StrixOAuth
ai.strix
AI pentesting: run scans, triage vulnerabilities, review PRs, manage schedules and assets.
Penetration Testing Version Control
1
Brainiall Web A
com.brainiall
Web search, URL content extraction to Markdown, site mapping, and recursive web crawler.
Browser Automation Web Scraping
51

Related MCP Servers

MCP SSH Server
Shell Access Command Line
Fabber-bot
A
license
Not graded
quality
F
maintenance
Enables AI assistants to execute commands and transfer files on remote servers over SSH connections.
Updated 7 months ago (2026-02-19 17:32 UTC)
1
MIT
SSH MCP Server
Shell Access File Systems
uarlouski
A
license
Not graded
quality
C
maintenance
Enables AI assistants to securely execute commands, transfer files, and manage port forwarding on remote servers via SSH.
Updated 3 months ago (2026-06-10 10:12 UTC)
91
37
Apache 2.0
sec-aircrack-ng-mcp
Penetration Testing Shell Access
schwarztim
A
license
A
quality
F
maintenance
Enables AI assistants to perform authorized WiFi security assessments, including network scanning, handshake capture, and password cracking, by executing aircrack-ng commands on a remote Kali Linux system via SSH.
Updated 4 months ago (2026-05-09 04:31 UTC)
16
MIT
SSH MCP Server
Command Line Monitoring Shell Access
hypnosis
A
license
A
quality
A
maintenance
Enables AI assistants to manage remote servers via SSH with 14 commands for execution, file transfer, auditing, and monitoring.
Updated 8 days ago (2026-09-03 12:23 UTC)
18
627
3
MIT