Click on "Deploy 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., "@mcp-noctua scan example.com for vulnerabilities"
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.
🇬🇧 English · 🇫🇷 Français
An MCP server (stdio) that exposes a pentest toolbox to a strong LLM orchestrator (Claude Code, interactive), to run authorized security audits.
A clean rewrite inspired by the Darkmoon MCP (GPL v3) with no code copied → CeCILL-B license, zero GPL debt. What's reused is the toolbox (sqlmap, nuclei, ffuf, httpx, naabu, katana, whatweb…); the fragile orchestration (opencode + local model) is dropped and replaced by a strong brain that verifies.
[Claude Code] --stdio--> [mcp-noctua (host)] --docker.sock--> [darkmoon container = toolbox]
(the brain) (controlled gateway) (sqlmap, nuclei, ffuf…)mcp-noctua reuses the darkmoon container (ascit/darkmoon:latest) as its
toolbox, invoking it via docker.sock. Invoking tools inside a container is not a
derivative work → no license concern. The container is kept alive; noctua starts
it if it's stopped before a run.
Related MCP server: Kali MCP Pentest Server
Tool | Role |
| Run a whitelisted tool in the toolbox. |
| Bounded crawl (katana). |
| naabu + httpx, bounded. |
| nuclei, bounded. |
| Tools available in the toolbox. |
| Toolbox container state (running / started / not found). |
Strict allow-list of tools; dangerous patterns blocked (rm -rf, fork bomb, exfil…).
A timeout that actually kills the process inside the toolbox (fixes the Darkmoon flaw).
Authorized testing only; the operator validates every target.
.env)See .env.example. Keys: DOCKER_CONTAINER_NAME, NOCTUA_TIMEOUT,
NOCTUA_REPORTS_DIR, NOCTUA_COMPOSE_DIR, DEBUG.
git clone https://github.com/NeveuGregor/mcp-noctua.git
cd mcp-noctua
python3 -m venv venv && source venv/bin/activate
pip install -e ".[dev]"
cp .env.example .env # adjust as needed
pytestRegister in ~/.claude.json as a stdio MCP server:
venv/bin/python -m src.main (cwd = mcp-noctua).
CeCILL-B — see LICENSE.
Etat du conteneur toolbox (present/absent, running, image). Ne demarre rien.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It explicitly states the tool does not start anything, indicating a read-only operation. While it doesn't detail the response format, it covers the key behavioral trait.
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 with two short sentences, front-loading the purpose and adding a clarifying phrase. No fluff.
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 no output schema, the description covers the main aspects of the status (present/absent, running, image) but does not specify the return structure or format. However, for a simple health check, it is sufficiently complete.
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?
There are no parameters, so baseline is 4. The description adds no parameter information, but none is needed.
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 returns the status of the toolbox container, specifying aspects like present/absent, running, and image. The additional statement 'Ne demarre rien' further clarifies it does not start anything, distinguishing it from sibling tools like run_tool.
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 implicitly indicates use for checking container status and explicitly contrasts with run_tool by stating it does not start anything. However, it lacks explicit when-not or alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Liste les outils whitelistes presents (et absents) dans la toolbox.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full disclosure burden. It reveals that the tool lists both present and absent tools, indicating no destructive effects. However, it does not specify read-only behavior, data volume, or response format, which would enhance 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 a single concise sentence that directly conveys the tool's functionality. No extraneous words, and it is front-loaded with the core action.
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 simple listing tool with no parameters, the description sufficiently explains what it does. It could benefit from briefly noting the expected output (e.g., list of tool names or objects), but the current text is adequate given the simplicity.
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 no parameters, and schema coverage is 100%. The description adds no parameter details, but none are needed. With zero parameters, the baseline is 4, and the description meets it adequately.
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: listing whitelisted tools in the toolbox, including both present and absent ones. The verb 'list' and resource 'tools' are specific, and the action is distinct from sibling tools (health, port_scan, etc.), which perform different operations.
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 guidance on when to use this tool versus alternatives. It does not mention scenarios, prerequisites, or conditions for invocation. An agent would need to infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan de ports (naabu top-ports) puis sonde HTTP (httpx) des ports ouverts.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Hote ou IP cible. | |
| timeout | No | Timeout en secondes (defaut 300). | |
| top_ports | No | Nombre de top-ports (defaut 100). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions the two-step process but omits details about destructiveness, authentication requirements, rate limits, or output format. This is insufficient for a scanning tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence) and front-loads the purpose. 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters, no output schema, no annotations), the description covers the core workflow but lacks details about return values and important behavioral context. It is minimally adequate.
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 description adds no additional meaning beyond the schema. Baseline score is 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 the tool performs a port scan using naabu top-ports followed by an HTTP probe on open ports. It distinguishes itself from sibling tools like vuln_scan and web_crawl.
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?
No explicit guidance on when to use this tool versus alternatives. The description implies its purpose but does not provide when-not-to-use or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute un outil de reconnaissance/scan whiteliste dans la toolbox (forme exec, sans shell : pas de pipe ni de chainage). Usage test AUTORISE uniquement. Borne par un timeout qui tue reellement le process. Pour enchainer des outils, faire plusieurs appels.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | Commande complete, p.ex. 'httpx -u http://cible -title -tech-detect'. | |
| timeout | No | Timeout en secondes (defaut 300, max 3600). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses key behaviors: no shell, no pipe/chaining, timeout kills process, and restricted to authorized usage. It could add return format details but covers critical safety aspects.
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 concise paragraph, front-loaded with the core action, and every sentence contributes unique information without redundancy.
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 2 parameters and no output schema, the description covers purpose, constraints, and parameter behavior adequately. It is missing explicit mention of output handling, but for a command executor, the behavior is standard.
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% with descriptive parameter descriptions. The description adds behavioral context for timeout (kills process) and provides an example command, enhancing understanding beyond the schema.
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 specifies that the tool executes whitelisted reconnaissance/scan tools in exec form without shell, clearly distinguishing it from sibling tools like port_scan or vuln_scan which are specific tools. The scope is precise.
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 states usage is for authorized tests only, and that to chain tools multiple calls are needed. While it implies not to use pipes or unauthorized usage, it does not explicitly name alternative tools for other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan de vulnerabilites borne (nuclei) : debit/concurrence limites, tags et severite optionnels.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL http(s) cible. | |
| tags | No | Tags nuclei, ex. 'cve,exposure' (optionnel). | |
| timeout | No | Timeout en secondes (defaut 900). | |
| severity | No | Severites, ex. 'high,critical' (optionnel). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only mentions limited throughput/concurrency, lacking details on authentication needs, rate limits, destructive potential, or response 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?
Single sentence is concise, but could benefit from more structure (e.g., separate lines for purpose and constraints).
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?
No output schema, no annotations, and only 4 parameters. Description lacks details on output format, success/failure indicators, and error handling, making it incomplete for complex use.
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%; description adds that tags and severity are optional, which is already implied by schema not marking them required. Limited added meaning beyond schema.
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?
Clearly states it is a vulnerability scan using nuclei, specifying bounded throughput/concurrency and optional tags/severity. Distinguishes from sibling tools like port_scan and web_crawl.
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?
Mentions limited throughput/concurrency but does not explicitly state when to use this tool versus alternatives or provide when-not conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Crawl borne d'une URL (katana, profondeur 1..3, crawling JS).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL http(s) de depart. | |
| depth | No | Profondeur 1..3 (defaut 1). | |
| timeout | No | Timeout en secondes (defaut 120). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions depth bounds and JS crawling but omits critical details like output format, impact on the target, rate limiting, or scope restrictions (e.g., same-domain only). This leaves significant behavioral ambiguity.
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 very brief and front-loaded with key information (tool, depth, JS). It is efficient, though slightly more context (e.g., output) could be added without bloat.
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 lacks an output schema, so the description should explain what the crawl returns (e.g., list of links, content). It does not. Additionally, it fails to mention behavioral constraints like rate limiting or robot.txt compliance, leaving the agent underinformed for proper usage.
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% with descriptions for all parameters. The description adds no extra parameter-specific meaning beyond mentioning 'katana' and 'crawling JS', so it does not enhance understanding beyond the schema baseline.
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 crawls a URL using Katana with options for depth and JS crawling. It distinguishes itself from sibling tools like port_scan and vuln_scan, which are different in functionality.
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 guidance on when or when not to use this tool, nor does it reference alternatives. Sibling tools are not compared, leaving the agent without contextual usage advice.
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.
v0.1.0healthlist_toolsport_scanrun_toolvuln_scanweb_crawlScored across 6 tools
Each tool has a clearly distinct purpose: health checks container state, list_tools enumerates whitelisted tools, port_scan performs port scanning, run_tool executes a generic recon tool, vuln_scan does vulnerability scanning, and web_crawl does web crawling. No overlap or ambiguity.
All names use snake_case and are descriptive, but there's a mix of verb-first (list_tools, run_tool) and noun-first (port_scan, vuln_scan, web_crawl) patterns, plus health stands alone. Still consistent in style and readable.
6 tools is well-scoped for a reconnaissance/scanning toolbox, covering essential functions without being overly numerous or sparse.
The set covers core recon tasks: tool listing, port scanning, vulnerability scanning, web crawling, and a generic run_tool for extensibility. Minor gaps like explicit service detection or DNS enumeration are likely addressable via run_tool.
Exposes FEDLIN's public security scanners as agent-callable tools over Streamable HTTP.
Find, vet, and run MCP tools through a secure audited gateway with prompt-injection risk scoring
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
Runtime permission, approval, and audit layer for AI agent tool execution.
