What can you do with this server?

MoonMCP is a scope-aware bug-bounty and reconnaissance MCP server exposing 54 tools, 5 resources, and 7 prompts for passive OSINT, active reconnaissance, and intrusive security testing, with structured JSON output and a built-in authorization model. Meta / Scope Management * server_status — View server config, capabilities, and detected external CLI tools * scope_list / scope_add / scope_exclude / scope_remove — Dynamically manage authorized testing scope (exclusions always override allowlist) Passive OSINT (no direct target contact) * enumerate_subdomains — Discover subdomains via crt.sh, HackerTarget, AnubisDB, AlienVault OTX * wayback_urls — Retrieve historical URLs from the Internet Archive * cve_lookup / cve_search — Look up CVEs by ID or keyword from NVD, sorted by severity * host_intel — Query Shodan (free InternetDB or full API) for open ports, hostnames, CPEs, and known CVEs * ip_intel — Map IPs to ASN, org, ISP, cloud provider * reverse_ip — Find co-hosted domains * email_security — Assess SPF/DMARC/DKIM/CAA posture * jwt_analyze — Decode and analyze JWTs Active — Light Recon (benign, in-scope requests) * dns_lookup — Resolve A/AAAA, MX, NS, TXT, CNAME, SOA, CAA, PTR records * http_probe — Structured HTTP(S) requests returning status, headers, timing, redirect chain, page title * tls_inspect — Inspect TLS certificates, validity, SANs * analyze_headers — Audit HTTP security headers with A–F grade * fingerprint — Detect web server, CDN, language, framework, CMS, JS libraries * well_known — Fetch and parse robots.txt, sitemap.xml, security.txt, humans.txt Active — Web App Checks (in-scope, structured findings) * crawl — Depth-1 crawl for links, forms, JS assets * extract_secrets — Scan pages and JS for exposed secrets * cors_audit — Audit CORS misconfigurations * graphql_check — Discover GraphQL endpoints and test introspection * waf_detect / waf_efficacy — Detect and test WAF/CDN efficacy * takeover_check — Test subdomain takeover * open_redirect — Test open redirects * vcs_exposure — Confirm .git/.svn/.env exposure * screenshot — Take screenshots via Playwright * analyze_binary / analyze_config — Analyze binaries and config files for secrets/misconfigs * favicon_hash / tls_fingerprint / jarm_fingerprint — Fingerprinting and pivoting * origin_discovery — Discover real origin IP behind CDN * behavior_probe — Behavioral profiling (soft 404s, stack traces, etc.) * desync_probe — Detect request-smuggling indicators Active — Intrusive (gated by MOONMCP_ALLOW_INTRUSIVE) * port_scan — TCP connect-scan with optional banner grabbing * content_discovery — Probe for sensitive paths using built-in or custom wordlists * http_methods — Enumerate allowed HTTP methods * vuln_scan — Run nuclei template-based vulnerability scans Orchestration & External Tools * recon_target — One-shot passive+light recon sweep chaining subdomains → DNS → TLS → HTTP → headers → fingerprint * report — Generate a severity-ranked Markdown report * add_finding / list_findings / clear_findings — Manage findings session store * external_tools — List detected external security CLIs * run_scanner — Execute external CLIs (subfinder, httpx, nuclei, nmap, ffuf, etc.) with scope-checked targets and auto-parsed output Knowledge Base * injection_info / injection_search / match_injection_signatures — 29 injection classes with payloads, signatures, and response matching * technique_info / technique_search — 115 exploitation techniques with references Resources: Access scope, capabilities, findings, full injection catalog, and technique catalog via MCP resource URIs. Operator Prompts: Pre-built system prompts for AI agents — bug_bounty_operator, deep_recon, injection_hunt, technique_advisor, triage_and_report, safe_recon, recon_methodology.

Which integrations are available for this server?

Provides access to historical URLs from the Internet Archive for passive reconnaissance.

How do I use MoonMCP?

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., "@MoonMCP perform a full recon sweep on example.com" 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.

MoonMCP

by Moonwuk

Overview Schema Source Related Servers Score Discussions Admin

Python

Remote

MoonMCP is a scope-aware bug-bounty and reconnaissance MCP server exposing 54 tools, 5 resources, and 7 prompts for passive OSINT, active reconnaissance, and intrusive security testing, with structured JSON output and a built-in authorization model.

Meta / Scope Management

server_status — View server config, capabilities, and detected external CLI tools
scope_list / scope_add / scope_exclude / scope_remove — Dynamically manage authorized testing scope (exclusions always override allowlist)

Passive OSINT (no direct target contact)

enumerate_subdomains — Discover subdomains via crt.sh, HackerTarget, AnubisDB, AlienVault OTX
wayback_urls — Retrieve historical URLs from the Internet Archive
cve_lookup / cve_search — Look up CVEs by ID or keyword from NVD, sorted by severity
host_intel — Query Shodan (free InternetDB or full API) for open ports, hostnames, CPEs, and known CVEs
ip_intel — Map IPs to ASN, org, ISP, cloud provider
reverse_ip — Find co-hosted domains
email_security — Assess SPF/DMARC/DKIM/CAA posture
jwt_analyze — Decode and analyze JWTs

Active — Light Recon (benign, in-scope requests)

dns_lookup — Resolve A/AAAA, MX, NS, TXT, CNAME, SOA, CAA, PTR records
http_probe — Structured HTTP(S) requests returning status, headers, timing, redirect chain, page title
tls_inspect — Inspect TLS certificates, validity, SANs
analyze_headers — Audit HTTP security headers with A–F grade
fingerprint — Detect web server, CDN, language, framework, CMS, JS libraries
well_known — Fetch and parse robots.txt, sitemap.xml, security.txt, humans.txt

Active — Web App Checks (in-scope, structured findings)

crawl — Depth-1 crawl for links, forms, JS assets
extract_secrets — Scan pages and JS for exposed secrets
cors_audit — Audit CORS misconfigurations
graphql_check — Discover GraphQL endpoints and test introspection
waf_detect / waf_efficacy — Detect and test WAF/CDN efficacy
takeover_check — Test subdomain takeover
open_redirect — Test open redirects
vcs_exposure — Confirm .git/.svn/.env exposure
screenshot — Take screenshots via Playwright
analyze_binary / analyze_config — Analyze binaries and config files for secrets/misconfigs
favicon_hash / tls_fingerprint / jarm_fingerprint — Fingerprinting and pivoting
origin_discovery — Discover real origin IP behind CDN
behavior_probe — Behavioral profiling (soft 404s, stack traces, etc.)
desync_probe — Detect request-smuggling indicators

Active — Intrusive (gated by MOONMCP_ALLOW_INTRUSIVE)

port_scan — TCP connect-scan with optional banner grabbing
content_discovery — Probe for sensitive paths using built-in or custom wordlists
http_methods — Enumerate allowed HTTP methods
vuln_scan — Run nuclei template-based vulnerability scans

Orchestration & External Tools

recon_target — One-shot passive+light recon sweep chaining subdomains → DNS → TLS → HTTP → headers → fingerprint
report — Generate a severity-ranked Markdown report
add_finding / list_findings / clear_findings — Manage findings session store
external_tools — List detected external security CLIs
run_scanner — Execute external CLIs (subfinder, httpx, nuclei, nmap, ffuf, etc.) with scope-checked targets and auto-parsed output

Knowledge Base

injection_info / injection_search / match_injection_signatures — 29 injection classes with payloads, signatures, and response matching
technique_info / technique_search — 115 exploitation techniques with references

Resources: Access scope, capabilities, findings, full injection catalog, and technique catalog via MCP resource URIs.

Operator Prompts: Pre-built system prompts for AI agents — bug_bounty_operator, deep_recon, injection_hunt, technique_advisor, triage_and_report, safe_recon, recon_methodology.

🌙 MoonMCP

A scope-aware bug-bounty & reconnaissance MCP server that works out of the box on the Python standard library — and augments itself with your favorite CLI tools when they're present.

MoonMCP exposes a curated set of reconnaissance, fingerprinting, OSINT and detection capabilities to any Model Context Protocol client (Claude Desktop, Claude Code, Cursor, …), so an AI agent can map a target's attack surface safely and within an authorised scope: web + OSINT recon (multi-engine search, a page reader, subdomains, wayback, CVE/Shodan), web-app detectors (CORS, GraphQL introspection + batch/BOLA, WebSocket/CSWSH, secrets, exposed-.git history forensics, injection/SQLi/SSRF/SSTI, datastore exposure), behavioural infrastructure mapping, offline knowledge bases, and a persistent, cross-agent memory hub with a typed knowledge graph so findings are remembered and built upon. Every tool is detection-only — leads to verify, with weaponisation delegated to sqlmap/Strix under human confirmation.

⚖️ Authorised testing only. MoonMCP is for security research on assets you own or are explicitly permitted to test (e.g. a bug-bounty program's in-scope targets). You are responsible for staying within scope and the law.

Why another recon MCP server?

Before writing a line of code, we surveyed the ecosystem: a fan-out research pass discovered 161 candidate projects and deep-read 23 confirmed bug-bounty / offensive-security MCP servers (ProjectDiscovery's pd-tools-mcp, HexStrike AI, ExternalAttacker-MCP, gokulapap/bugbounty-mcp-server, SlanyCukr/bugbounty-mcp-server, VulneraMCP, akinabudu/bug-bounty-mcp, cyproxio/mcp-for-security, several pentest-mcp variants, BurpMCP, and the HackerOne-platform integrations, among others). The full survey and the design blueprint it produced are in docs/RESEARCH.md. Three patterns stood out:

Observation across the ecosystem	MoonMCP's answer
Almost everything is a thin CLI wrapper. They shell out to `subfinder`, `amass`, `nmap`, `masscan`, `httpx`, `nuclei`, `sqlmap`, `ffuf`, `gobuster`, … and are useless until you install a pile of Go/native binaries.	Stdlib-first. Every core tool is implemented on the Python standard library, so MoonMCP is useful the moment it starts — no external binaries required.
Kitchen-sink surfaces (some expose 40–50 tools) that assume a fully-loaded pentest box and offer little safety.	A focused tool surface covering the recon workflow end-to-end, each with structured JSON output, plus offline knowledge bases (injections, techniques, privilege escalation, server-side vulns, WAF).
No authorization model. Point-and-scan primitives with no notion of "is this target in scope?"	Scope-first. Every packet-sending tool is gated by an authorization scope; intrusive scans are opt-in and rate-limited.

MoonMCP's design principles:

🔋 Works out of the box — zero required dependencies beyond the MCP SDK.
🧩 Augments, never depends — detects and wraps nuclei/httpx/subfinder/nmap/… when installed, degrades gracefully when not.
🛡️ Scope-first & safe by default — an authorization guardrail on every active tool, rate limiting, and an intrusive-tools switch.
📦 Structured output — everything returns clean JSON, not scraped console text.

Related MCP server: shodan-mcp

Tool surface

MoonMCP exposes 166 tools, 11 resources and 9 operator prompts, grouped by how much they touch the target:

🟢 Meta / scope

Tool	Purpose
`server_status`	Report config, active program, detected enhancers and external CLIs.
`tool_catalog`	Self-describing map of all tools grouped by family, each tagged `scope_gated` / `intrusive`, plus the recommended recon→report workflow — call it second to orient.
`scope_list` / `scope_add` / `scope_exclude` / `scope_remove`	Manage the authorization scope at runtime.
`program_add` / `program_use` / `program_list` / `program_remove`	Bug-bounty program profiles. Each program carries its own scope and its own identifying header (e.g. `X-HackerOne-Research: <handle>`) + optional User-Agent; activating one swaps in its scope and auto-attaches its header/UA to every in-scope request. Persist across restarts via `MOONMCP_STATE_DIR`.
`auth_set` / `auth_clear`	Set the engagement auth context (bearer / cookie / basic / headers) so the web tools test the authenticated surface — merged into every in-scope request only.
`oast_configure` / `oast_selfhost` / `oast_generate` / `oast_poll` / `oast_list`	Out-of-band callback canaries to confirm blind vulns (blind SSRF/XXE/RCE/SQLi, blind XSS): point at an interactsh/Collaborator (`oast_configure`) or start the built-in catcher (`oast_selfhost`, stdlib — no third party), mint a canary URL, plant it, poll for the callback.
`audit_log`	Read the session audit trail — one record per scope decision (allow / deny / SSRF-block) and external command (also on `audit://recent`, persisted via `MOONMCP_AUDIT_LOG`).

🔵 Passive OSINT (never touches the target)

Tool	Purpose
`web_search`	Search the internet (keyless) → structured title / URL / snippet results. Multi-engine & resilient: tries DuckDuckGo HTML → DDG Lite → Bing and returns the first that answers (so one engine failing doesn't blind the search); dedupes by URL; `site=` scopes to one domain. Passive — queries a search engine, not the target.
`web_read`	Fetch a public page and return clean readable content — title, description, main text (scripts/styles/nav stripped), outbound links, word count. The OSINT reader that pairs with `web_search`. Not target-scoped (reads third-party research), but the block-private SSRF guard still refuses internal/metadata IPs and no engagement auth is sent; returned text is untrusted.
`search_dorks`	Generate ready-to-run Google/Bing dorks for a target (exposed files, login panels, config/secrets, dir listings, code leaks, SSRF params).
`enumerate_subdomains`	Passive subdomain enum via crt.sh, HackerTarget, AnubisDB, AlienVault OTX.
`wayback_urls`	Historical URLs from the Internet Archive (flags interesting endpoints).
`cve_lookup` / `cve_search`	Query the NVD for a CVE by ID or by keyword (e.g. a product+version).
`host_intel`	IP exposure via Shodan InternetDB (free) or the full Shodan API.
`ip_intel`	Map an IP → ASN, org, ISP, cloud/CDN provider, hosting flag, reverse DNS, geo.
`reverse_ip`	Other domains co-hosted on the same IP (reverse-IP lookup).
`cloud_buckets`	Enumerate cloud storage buckets (S3 / GCS / Azure Blob): permutate names from a keyword and probe which exist and which are anonymously listable.
`email_security`	SPF / DMARC / DKIM / CAA posture with an A–F grade (DNS-based).
`jwt_analyze`	Decode a JWT and flag `alg:none`, weak HS*, missing expiry, key-injection (no traffic).
`jwt_alg_confusion`	JWT algorithm-confusion forgery — re-signs a captured RS/ES token as HS256/384/512 using the public key's PEM text as the HMAC secret (`kid` preserved). If the verifier reuses the same key material for both algorithm families, the forged token validates under the public key alone — full forgery without the private key. No traffic, offline.
`deserialize_fingerprint`	Deserialization-format fingerprint (Freddy-lite) — 100% passive byte/base64 signature scan of an already-captured cookie/header/field value: Java native serialization (`ACED0005`/`rO0AB...`), .NET ViewState (LosFormatter `FF01`), PHP `serialize()` objects, Python pickle, Ruby `Marshal`, Fastjson/Jackson polymorphic JSON (`@type`/`@class`). Reports the format; never invokes a gadget chain (→ ysoserial/PHPGGC/ViewGen via Strix). No traffic.

🟡 Active — light (benign, in-scope requests)

Tool	Purpose
`dns_lookup`	Resolve A/AAAA + MX/NS/TXT/CNAME/SOA/CAA (via dnspython or DNS-over-HTTPS, no dep needed) and reverse PTR.
`http_probe`	Structured HTTP(S) probe: status, headers, timing, redirect chain, title.
`tls_inspect`	Certificate subject/issuer/validity + Subject Alt Names (sibling hosts).
`analyze_headers`	Security-header audit with an A–F grade; flags leaks and risky cookies.
`fingerprint`	Technology detection: server, CDN/WAF, language, framework, CMS, JS libs.
`well_known`	Fetch & parse robots.txt, sitemap.xml, security.txt, humans.txt.

🕸️ Web-app checks (light active, in-scope, structured findings)

Tool	Purpose
`crawl`	Bounded depth-1 crawl → internal links, forms+inputs, JS/asset URLs, parameters, external hosts, emails.
`analyze_js`	Deep-extract the hidden API surface from a page and its JavaScript (LinkFinder-style) — absolute/relative endpoints a UI crawl misses, plus source maps (`.map`).
`js_library_scan`	Known-vulnerable JS library detector (Retire.js-lite) — matches script URLs/filenames/version banners already surfaced by `analyze_js`/`crawl` against a small bundled table (jQuery <3.5.0 DOM XSS, AngularJS <1.8.0 sandbox bypass, Lodash <4.17.21 prototype pollution, Moment.js <2.29.2 ReDoS, Handlebars <4.5.3 prototype-pollution RCE gadget, Bootstrap <4.1.2 tooltip XSS). No traffic, offline.
`parse_openapi`	Parse an OpenAPI/Swagger spec (URL or pasted) → full endpoint/param/method inventory, servers, security schemes, and flags (operations with no security).
`extract_secrets`	Scan a page and its JavaScript for exposed keys/tokens (AWS, GitHub, Slack, Stripe, private keys, JWTs) — redacted.
`cors_audit`	CORS misconfig: origin reflection, `null` origin, prefix/suffix bypass — worse with credentials.
`access_control_check`	Replay a request as user A (auth) vs user B vs anonymous and diff the responses → broken-access-control / IDOR signal (the #1 payout class; set `auth_set` first).
`authz_probe`	Function/object-level authorization: replay a privileged/admin action as a lower-priv or anonymous user → BFLA / BOLA.
`response_leak_probe`	Drives the OTP / reset / verify flow and detects the out-of-band secret (token/OTP) returned in-band in the response (account-takeover primitive).
`reset_poison_probe`	Password-reset poisoning via `Host` / `X-Forwarded-Host` — the reset link is built to point at an attacker host.
`path_bypass_probe`	401/403 → 2xx path-normalization ACL bypass (`/admin/./`, `%2e`, trailing dot, case, `..;/`).
`crlf_probe`	CRLF injection → response splitting / header injection (Set-Cookie / redirect smuggling).
`oauth_probe`	OIDC discovery recon — flags implicit grant, missing/`plain` PKCE, `none`/HS256 signing, `http` issuer, issuer↔jwks mismatch.
`oauth_redirect_probe`	OAuth `redirect_uri` validation bypass (prefix/suffix/subdomain/open-redirect chaining).
`recover_sourcemaps`	Recover the original app source from exposed `.js.map` sourcemaps and scan the recovered code for secrets.
`graphql_check`	Discover GraphQL endpoints and test whether introspection is enabled.
`graphql_probe`	Deep GraphQL — the classes that pay out even with introspection OFF: batch abuse (an array of queries in one request → rate-limit/brute-force amplifier, batched-login credential stuffing), field-suggestion schema recovery (a typo'd field → "Did you mean …?" leaks real names without introspection), aliases, and a nested-traversal BOLA lead. Detection-only.
`ws_probe`	WebSocket detection (the surface most scanners skip): RFC 6455 handshake by hand (stdlib) to confirm the endpoint, then the flagship Cross-Site WebSocket Hijacking (CSWSH) check — a foreign `Origin` still upgrading means Origin isn't validated, so a cookie-authed socket is hijackable. Reports a lead; `probe_message` (opt-in) sends one benign frame to check echo/reflection.
`discover_parameters`	Brute a wordlist of param names → flag hidden params the app reacts to: `reflected` (XSS/SSRF/injection entry point) or behavioural `status`/`length` change.
`waf_detect`	Fingerprint WAF/CDN (Cloudflare, Akamai, Imperva, AWS WAF, Sucuri, F5, …).
`takeover_check`	Subdomain-takeover detection over a 40+ provider fingerprint DB (S3, GH Pages, Heroku, Azure, …).
`open_redirect`	Inject a canary into common redirect params (url, next, returnTo, …) — Location / meta / JS.
`trace_redirects`	Follow a URL's redirect chain hop by hop and flag offsite / `https→http` downgrade / leaves-scope / loop / meta-refresh / JS redirect (OAuth `redirect_uri`, SSRF-via-redirect).
`vcs_exposure`	Confirm exposed `.git`/`.svn`/`.env`/`.DS_Store` by content signature; extract git remote + commit log.
`git_forensics`	Git-history forensics on an exposed `.git` (the deep follow-up to `vcs_exposure`) — reconstructs history from what the server serves (read-only) and mines it: `.git/config` remote credentials, `.git/logs/HEAD` reflog (SHAs + author emails + messages), `.git/index` tracked file list (flags `.env`/`id_rsa`/`.sql`), and a bounded loose-object walk* (commit→tree→blob) running the secret scanner over history. Packed history is detected + flagged for git-dumper/Strix. Secrets redacted.
`screenshot`	Render a page to PNG via Playwright+Chromium when installed (else a graceful note).
`browser_open`	Drive a headless browser: render a JS-heavy SPA and return the post-JS text/HTML, the console log, the network requests the page made, and page errors — endpoint/secret discovery a raw fetch can't see. Uses `auth_set`.
`browser_eval`	Run JavaScript in the page (the browser console) and return the result + console log — inspect the live DOM, read `window`/JS state, extract SPA-rendered data.
`browser_interact`	Drive a real user flow — click / fill / type / submit / wait / eval steps — and return the resulting page state plus cookies & localStorage (login, multi-step forms, SPA navigation).
`analyze_binary`	Download a compiled artifact (.dll/.exe/.jar/.so) → filetype (incl. .NET), strings (ASCII+UTF-16), secrets, URLs, conn-strings; optional `ilspycmd` decompile.
`analyze_config`	Parse a config file (.env/INI/JSON/YAML/.properties/XML/PHP) → every setting by category + flags (secrets, DEBUG, TLS-off, wildcard CORS, weak creds, conn-strings).
`favicon_hash`	Shodan-style favicon mmh3 hash + `http.favicon.hash:` pivot query (find siblings / origin behind CDN).
`tls_fingerprint`	Supported TLS versions (flags weak 1.0/1.1), cipher per version, ALPN / HTTP-2.
`jarm_fingerprint`	JARM active TLS fingerprint (62-char; verified byte-for-byte vs Salesforce) for infra/C2 pivoting.
`origin_discovery`	Find the real origin IP behind a CDN/WAF via cert SANs, non-proxied subdomains and MX.
`behavior_probe`	Behavioural profile: soft/custom-404, stack-trace disclosure, Host / X-Forwarded-Host reflection, methods, timing.

🟠 Active — intrusive (gated by `MOONMCP_ALLOW_INTRUSIVE`)

Tool	Purpose
`port_scan`	Unprivileged TCP connect-scan (`top` set or a custom range), optional banners.
`content_discovery`	Probe for sensitive paths (admin, `.git`, `.env`, backups, API docs, …).
`http_methods`	Enumerate allowed methods + probe risky ones (TRACE/PUT/DELETE/PATCH → XST / write-enabled).
`waf_efficacy`	Test which attack categories the WAF blocks (benign canaries) + whether simple transforms bypass it.
`desync_probe`	Detection-only request-smuggling indicators (CL+TE / obfuscated TE); complete-message probes, never poisons a connection.
`desync_modern_probe`	Modern desync (2025 class): 0.CL / TE.0 / `Expect: 100-continue` / chunk-extension via response-timeout deltas on raw closed sockets (CVE-2025-32094 / CVE-2025-55315). Detection-only.
`cache_deception_probe`	Web-cache deception: primes a path-confusion variant (`/x.css`, `;x.css`, `%2f`) of the private page and re-reads it cookieless → a cached authed body under an attacker-readable key.
`ssrf_metadata_probe`	Response-based SSRF → cloud-metadata credential theft (AWS/GCP/Azure/Alibaba/Yandex/Oracle/DO): injects each provider's IMDS URL and scans for its credential signature.
`logic_probe`	Business-logic abuse: mass-assignment (privileged fields echoed back) + value/quantity tampering.
`value_probe`	Money-aware value manipulation (negative/overflow/precision/>100 % discount, currency swap, single-use-coupon reuse).
`race_probe`	Single-packet race condition (HTTP/1.1 last-byte sync) → non-atomic per-user limits (coupon/withdrawal double-spend).
`workflow_probe`	Step-skipping on a multi-step flow — fetch each step cold (without its prerequisites) → order confirmed without payment, account active without verification.
`jwt_jku_probe`	JWT `jku`/`x5u` key-injection SSRF — re-issues the token with a `jku` pointing at an OAST canary; a callback = the server fetched attacker key material (CVE-2018-0114).
`vuln_scan`	Run a `nuclei` template scan (requires nuclei installed).

🗄️ Databases, data stores & advanced injection

Detection-only DB attack-surface coverage. Every probe is a read-only fetch, a benign two-request differential, an error-string match, or an OAST callback — weaponization (dump, --os-shell, CONFIG SET/SLAVEOF/MODULE LOAD, gadget/JNDI chains) is delegated to sqlmap / Strix under human confirmation.

Tool	Purpose
`db_exposure`	Unauthenticated datastore sweep — speaks each store's minimal read-only handshake: Redis `PING`/`INFO`, memcached `version`, a hand-built MongoDB `listDatabases` OP_MSG, and HTTP reads for Elasticsearch/OpenSearch, CouchDB, InfluxDB, Hadoop YARN, TiDB. Intrusive.
`nosqli_probe`	NoSQL (MongoDB) operator injection — sends an object where a string is expected (`$ne`/`$gt`/`$nin`, bracket and JSON forms) + a `$where` boolean oracle; flags a reproducible auth/record flip. Intrusive.
`graphql_nosqli`	GraphQL → Mongo/Mongoose operator injection — after `graphql_check`, sends an operator object as a GraphQL variable vs a string baseline; flags a resolver data/auth flip or a Mongoose `CastError`. Intrusive.
`second_order_sqli_probe`	Stored / second-order SQLi — seeds a tagged payload at a write endpoint, drives the read endpoints, correlates the SQL error/differential by tag (the sink is a different endpoint — invisible to any stateless matcher). Intrusive.
`orm_leak_probe`	ORM leak (Django/Prisma/Rails) — injects a relational lookup (`<field>__startswith`) to filter by a hidden field (`password`, `reset_token`) via a true/false differential. Intrusive.
`parser_diff_probe`	HTTP parser-differential / WAF-bypass multiplier — pairs a canonical request with quirk-twins (UTF-7 / overlong-UTF-8 decode, duplicate JSON keys / comments / BOM / bare-LF multipart tolerance) to find where the app and a fronting WAF parse differently. Intrusive.
`fastjson_oast_probe`	Java fastjson/Jackson autoType — POSTs a benign `@type` OAST canary (`Inet4Address`/`URL`); a DNS/HTTP callback = the endpoint deserializes attacker-controlled `@type`. Intrusive, OAST.
`ssrf_protocol_probe`	SSRF → internal datastore — scheme-deref OAST canaries (`gopher`/`dict`/`ftp`) + an internal-port reachability differential (`http://127.0.0.1:<db_port>/`). Intrusive.
`stack_probe`	Fingerprint + unauth reads for ClickHouse, Druid (session-leak via `/druid/websession.json`), vector stores (Chroma/Weaviate/Qdrant), Nacos, ThinkPHP, Shiro, 1C-Bitrix. Intrusive.
`cspp_probe`	Client-side prototype pollution — loads `__proto__`/`constructor` URL paths (query + hash) in MoonMCP's own headless browser and reads `Object.prototype[marker]` back. Safe by design — the pollution lands in our throwaway Chromium, never the target. Light active.
`firebase_exposure`	Open Firebase RTDB — harvests the app's own `databaseURL`/`projectId` from its JS, then one shallow unauth read. Light active.
`supabase_exposure`	Supabase RLS-off — harvests the public `anon` key, enumerates the PostgREST schema, then a per-table `limit=1` read with that key. Light active.
`debug_exposure`	DB/admin panels by path→signature: Adminer (+ CVE-2021-21311 rogue-MySQL note), phpMyAdmin, Mongo-Express, pgAdmin, RedisInsight, ClickHouse `/play`. Light active.

🧰 Interception (Burp-style, native — no external proxy)

Tool	Purpose
`http_repeater`	Repeater — send one fully-controlled request (structured or a `raw` Burp-style HTTP request) to an in-scope target; full response + quick passive scan; logged for replay.
`intruder`	Intruder — a request `template` with a `§` marker + payload list, fired and diffed (status / length / reflection) vs a baseline → injection/IDOR entry points. Intrusive.
`passive_scan`	One benign GET → all passive analysers at once (header grade + issues, tech fingerprint, redacted secret hits).
`confirm_finding`	Prove a lead before reporting it: baseline vs test request → weighs reflection, status/length/timing diff, injection signatures, and an out-of-band callback (OAST) into a verdict (`confirmed` / `likely` / `inconclusive` / `unconfirmed`). Optionally records a confirmed hit.
`ssti_probe`	SSTI detector — arithmetic markers per engine (Jinja2/Twig, Freemarker, ERB, Smarty, Velocity, Razor); reports which engine evaluated the expression. Intrusive.
`sqli_probe`	SQLi detector — error signatures + a reproducible boolean pair, plus opt-in lanes: `context` (ORDER BY / LIMIT), `oob` (per-DBMS OAST), `time_based` (monotonic-guarded), `waf_bypass` (JSON-operator), `multibyte` (Shift-JIS/EUC-KR/GBK), and header/cookie placement. Reports the DBMS; no data extraction (→ sqlmap). Intrusive.
`cmdi_probe`	Blind OS command injection detector — a small, non-combinatorial set of shell separators (`;` `\|` `&&` `&` backtick `$()`), each carrying only a side-channel payload (`sleep N`, confirmed by the same monotonic-timing check as `sqli_probe`'s `time_based` lane; or an OAST callback). Never sends an output-eliciting payload (`id`, `cat /etc/passwd`, `dir`) — command output is never displayed (→ Strix). Intrusive.
`lfi_probe`	Path traversal / LFI content-disclosure — depth-escalating `../` (x1/3/6/8), null-byte, double-URL-encoded, and Windows-style variants, confirmed by a genuine file-content signature (`root:x:0:0:`, win.ini markers) in the response — proof the traversal reached the filesystem, not just that a WAF let the payload shape through. Reads only universally-present, non-sensitive files. Intrusive.
`ssrf_probe`	Blind SSRF detector — plants an OAST canary in a param and checks for a callback (start `oast_selfhost` first). Intrusive.
`xxe_probe`	Blind XXE detector — two lanes: `format_confusion` rewrites a JSON/form body into equivalent XML and resends it under the original Content-Type (tests whether a "JSON-only" endpoint parses XML anyway); `oob` injects a `<!DOCTYPE>` external entity pointing at an OAST canary and polls for a callback — never reads file contents. Intrusive.
`interp_probe`	Generic differential "interpretation" prober (Backslash Powered Scanner-style) — a meta-probe, not a class-specific one: sends five small markers (backslash/escape, quote/string-context, NUL-byte truncation, `/./` path normalization, bare `{}` template tokens) and checks whether each is echoed literally or transformed. Requires two or more independent markers to agree before calling anything more than a weak signal. Never asserts a vulnerability class — `suggested_next` names which class-specific probe (`sqli_probe`, `cmdi_probe`, `lfi_probe`, `ssti_probe`, `parser_diff_probe`, …) to run next. Intrusive.
`saml_xsw_probe`	SAML XML Signature Wrapping (XSW) probe — give it a captured, legitimately-signed SAMLResponse + the SP's ACS URL; clones the signed assertion, strips the clone's signature, forges its identity, and splices it in via three representative topologies (`sibling_before`/`sibling_after`/`wrap_extension` — first-wins / last-wins / direct-children-only assertion selection). The original signature is never touched — `reflected_forged_identity` (the forged identity showing up in a variant's response but neither baseline's) is the strong, replay-noise-independent confirmation signal. Intrusive.
`cache_probe`	Web cache poisoning detector — unkeyed-header reflection (`X-Forwarded-Host`, …) × cacheability. Intrusive.
`http_history`	Review / fetch / clear the session's request-response history (what repeater/intruder/passive_scan sent).

🏗️ Behavioural infrastructure (infer the infra from response variance)

Tool	Purpose
`backend_probe`	Infer the backend fleet behind a load balancer: clusters N responses by their discriminators (Server, Via, backend-id headers, cookie names) → distinct backends, patch drift (nodes on different Server versions — one may be individually vulnerable) and clock skew.
`dns_behavior`	DNS/zone behaviour: wildcard-DNS detection (so subdomain enum isn't fooled), DNS load-balancing (rotating A records), IPv6, and the CNAME target (dangling → takeover surface).
`vhost_probe`	Host-header routing: does the edge validate the Host or serve the same app for any host (cache/reset poisoning surface)? Is a bogus host reflected (host-header injection) directly or via `X-Forwarded-Host`?
`ratelimit_probe`	Rate-limit behaviour: finds the throttle threshold/window, `Retry-After`, and whether spoofing `X-Forwarded-For` resets the limit (per-IP bypass). Intrusive.
`tls_behavior`	TLS routing behaviour: real-host vs bogus-SNI cert diff (→ SNI routing / shared hosting / default-cert origin hint), supported versions (flags weak TLS 1.0/1.1), cipher, HTTP/2.
`edge_map`	Edge topology: which CDN/WAF/cache vendors front the origin (Cloudflare/CloudFront/Fastly/Akamai/Sucuri/Imperva…), the `Via` proxy chain, cache layer — are you hitting the edge or the origin?
`http_behavior`	Raw HTTP/1.x fingerprint (intrusive): reactions to HTTP/1.0, an unknown method, an oversized header, and bare-LF line endings → lenient parsing / proxy-origin mismatch (desync surface). Detection-only.

🔗 Orchestration & reporting

Tool	Purpose
`probe_batch`	Probe a list of hosts/URLs in parallel (liveness, status, title, tech) — the enum→probe step; feed it `enumerate_subdomains`. Scope-gated + rate-limited.
`recon_target`	One-shot passive+light sweep (subdomains → DNS → TLS → HTTP → headers → fingerprint → email security).
`report`	Full safe sweep → a severity-ranked Markdown report (surface, posture grades, findings).
`add_finding` / `list_findings` / `clear_findings`	Record / read / clear findings in the session store (also on the `findings://` resource).
`triage_findings`	Dedupe + prioritise findings before reporting: collapse exact duplicates, rank by severity × frequency, and surface systemic issues (same finding across many targets). Dry-run or `apply=true`.
`cvss_score`	Compute a CVSS 3.1 base score + severity band from a vector or individual metrics — so a confirmed finding carries a defensible standard severity. Offline.
`export_findings`	Export findings as SARIF 2.1.0 (GitHub code-scanning / DAST pipelines) or JSON.
`export_obsidian`	"Graphify" the session into an Obsidian vault — linked notes (asset ↔ finding, vuln ↔ root cause) + tags + an Obsidian Canvas graph. Open the folder and use the graph view.
`surface_diff` / `surface_snapshots`	Track how the attack surface changes over time — baseline a set (subdomains/endpoints/…) and surface only what's new since last run (persists via `MOONMCP_STATE_DIR`).

🧠 Shared memory hub (persistent, cross-agent)

Tool	Purpose
`memory_add`	Store an item in a shared, persistent knowledge store (SQLite; persists via `MOONMCP_STATE_DIR`) so multiple agents/sessions build on each other's work. Every item is trust-tagged — `untrusted` (scraped/observed content — a prompt-injection vector) vs `curated` (a vetted conclusion).
`memory_search`	Full-text search (bm25 via SQLite FTS5, LIKE fallback) over the hub; filter by `kind` / `target` / `trust` (`trust=curated` returns only vetted knowledge). Also on `memory://recent`.
`memory_get` / `memory_stats`	Fetch one item; summarise the hub (counts by kind/trust). `add_finding` auto-mirrors findings into the hub as `curated`.
`memory_brief`	What do we know about TARGET? — one-shot rollup for orienting before/resuming work: graph entities by kind, confirmed findings, open leads, applicable lessons, counts. Call it first on a target.
`memory_graph` / `memory_link`	Read / build the knowledge graph — typed entities (host / endpoint / param / technology / service / cve / …) and typed relations (`affects` / `on` / `uses` / `caused_by` / …) between them and findings. `add_finding` auto-links a finding to its host + endpoint, turning flat findings into a queryable structure.
`memory_lesson`	The learning loop — record (`action=add`) and recall (`action=recall`) durable, cross-target lessons (tradecraft, false-positive traps, tool quirks) so mistakes and wins carry forward between sessions and agents.

🛠️ External tools

Tool	Purpose
`external_tools`	List known security CLIs (36, categorised) and whether each is installed + its native fallback.
`run_scanner`	Run an installed CLI (`subfinder`, `httpx`, `nuclei`, `nmap`, `ffuf`, …); JSONL auto-parsed; intrusive scanners gated by `MOONMCP_ALLOW_INTRUSIVE`.

📚 Knowledge bases

Referenced catalogs built into the server (offline, searchable as tools + MCP resources) — descriptions, detection guidance and links to public research, not weaponized exploit code:

Injections — 29 classes (255 detection payloads · 318 response signatures). docs/INJECTIONS.md
Exploitation techniques & notable PoCs — 115 techniques across 14 categories, from assembler-level memory corruption to the highest-level web / supply-chain. docs/TECHNIQUES.md
Privilege escalation — 129 techniques (Linux · Windows · container · cloud · Active Directory · macOS) + 68 tools. docs/PRIVESC.md
Server-side vulnerabilities — 44 classes (popular and obscure), each mapped to its root cause and the concrete point where apps break, + 29 tools. docs/SERVER_SIDE_VULNS.md
Root-cause taxonomy — the 13 fundamental causes from which nearly all server-side bugs spring, each with its systemic fix. Where the core of all problems is. docs/ROOT_CAUSES.md
WAF reference — 24 entries: how WAFs work, vendor fingerprints, and conceptual/defensive bypass classes. docs/WAF.md

Tool	Purpose
`injection_info` / `injection_search`	Look up / search one of 29 injection classes (sqli, nosqli, xss, ssti, cmdi, xxe, xpath, ldapi, ssrf, crlf, prototype-pollution, prompt-injection, …): detection payloads, root causes, per-engine signatures.
`match_injection_signatures`	Scan a response body for known injection error signatures → which class + technology (e.g. `ORA-01756` → Oracle SQLi).
`technique_info` / `technique_search`	115 exploitation techniques & landmark public PoCs across all languages/levels — descriptions + links, not exploit code.
`privesc_info` / `privesc_search`	129 privilege-escalation techniques across Linux/Windows/container/cloud/AD/macOS: enumeration commands, detection indicators, mitigations, references.
`privesc_tools`	Catalog of 68 privesc tools (LinPEAS/WinPEAS, GTFOBins, LOLBAS, PowerUp, Seatbelt, pspy, potato family, BloodHound, Impacket, …).
`match_privesc`	Scan pasted enumeration output (`sudo -l`, `id`, `getcap -r /`, `whoami /priv`, `systeminfo`) → which escalation vectors it indicates.
`vuln_info` / `vuln_search` / `vuln_tools`	44 server-side vuln classes (popular + obscure) with root cause, `where_it_breaks`, detection, WAF notes and real-world incidents; + a 29-tool discovery catalog.
`rootcause_info`	The root-cause taxonomy — the ~13 fundamental causes underneath all these bugs, each with why it recurs, the systemic fix, and the catalog vulns that derive from it.
`waf_info` / `identify_waf`	WAF KB (how they work · fingerprints · bypass concepts); `identify_waf` names the vendor from a raw HTTP response (CF-RAY, `__cfduid`, `x-akamai`, `incap_ses`, BigIP, …).

Resources: moonmcp://scope, moonmcp://capabilities, findings://current, injections://all, techniques://all, privesc://all, vulns://all, rootcauses://all, waf://all, audit://recent

Operator prompts (docs/SYSTEM_PROMPTS.md) — system prompts that make an agent using MoonMCP plan, pick the right tool, verify before it reports, minimise false positives and stay strictly in scope. Synthesised from real pentest-agent prompts (CAI, PentestGPT, XBOW, HexStrike), agent prompt-engineering (ReAct, Plan-and-Execute, Chain-of-Verification, Reflexion) and bug-bounty methodology (TBHM, OWASP WSTG, PortSwigger, HackerOne/Bugcrowd):

bug_bounty_operator — master engagement prompt (rules of engagement + OODA-style loop + tool map).
deep_recon — exhaustive 5-phase attack-surface mapping.
injection_hunt — KB-backed injection hunt with benign canaries + signature confirmation.
technique_advisor — referenced technique guidance for an observed tech/CVE.
triage_and_report — verify, dedupe, severity-rate and write accepted-quality reports.
safe_recon — conservative, passive-first, scope-strict default.
privesc_hunt — KB-backed privilege-escalation triage from an authorised foothold (enumerate → match_privesc → verify).
recon_methodology — the original quick-start recon playbook.

Quickstart

Requires Python 3.10+.

# with uv (recommended)
uv tool install --from . moonmcp        # or: uvx --from . moonmcp
# or with pip
pip install .

# sanity check (prints detected capabilities, does not start the server)
moonmcp --check

Add to an MCP client

Claude Desktop / Claude Code (claude_desktop_config.json or .mcp.json):

{
  "mcpServers": {
    "moonmcp": {
      "command": "moonmcp",
      "env": {
        "MOONMCP_SCOPE": "*.example.com, 203.0.113.0/24",
        "MOONMCP_ALLOW_INTRUSIVE": "0"
      }
    }
  }
}

See examples/claude_desktop_config.json for a fuller example.

Then, in the client: "Using MoonMCP, run recon on example.com" — the agent will call scope_add, then the passive/light tools, and summarise the attack surface.

Use it from a shell-based agent (no MCP client needed)

Any agent with a shell (or a CI step) can drive MoonMCP without an MCP client:

moonmcp tools                                              # list exposed tools
moonmcp call fingerprint   --arg target=https://example.com
moonmcp call injection_info --json '{"injection_class":"ssti"}'

Each call prints JSON; scope-gated tools still enforce MOONMCP_SCOPE. Expose a curated slice with a profile — MOONMCP_PROFILE=strix (knowledge + memory + recon + findings; hides the heavy scanners/proxy), or passive / knowledge / recon, or fine-grained MOONMCP_EXPOSE_TOOLS / MOONMCP_HIDE_TOOLS. This is how MoonMCP plugs into a tool like Strix as a shared brain/memory/guard (see docs/STRIX_INTEGRATION.md).

Claude Code skill

A packaged skill ships in .claude/skills/moonmcp/ that teaches an agent the MoonMCP workflow, the rules of engagement, and the tool map. Copy that folder into your ~/.claude/skills/ (or a project's .claude/skills/) and the agent will orient itself with server_status + tool_catalog and drive the tools in the right order — scope/program first, passive → light → intrusive (with consent) → report.

A second skill, strix-orchestration, teaches an agent to drive MoonMCP (fast, scope-first detection) together with Strix (autonomous validation with working PoCs) as two MCP tools of the same agent — MoonMCP finds, Strix confirms. See docs/STRIX_INTEGRATION.md and the scope-gated reference wrapper in examples/strix_mcp/.

Configuration

All configuration is via environment variables (set them in your MCP client's env block):

Variable	Default	Description
`MOONMCP_SCOPE`	(empty)	Comma/newline-separated in-scope entries: domains, `*.wildcards`, hosts, IPs, CIDRs.
`MOONMCP_SCOPE_EXCLUDE`	(empty)	Out-of-scope entries that always override the allowlist.
`MOONMCP_ENFORCE_SCOPE`	`1`	When on, active tools refuse targets not in scope.
`MOONMCP_BLOCK_PRIVATE`	`1`	SSRF guard: hard-block private/loopback/link-local/reserved IPs (incl. cloud metadata). Set `0` for authorised internal-network testing.
`MOONMCP_ALLOW_INTRUSIVE`	`1`	Gate for `port_scan`, `content_discovery`, `vuln_scan`.
`MOONMCP_RATE_LIMIT`	`20`	Max outbound requests/sec (token bucket; `0` = unlimited).
`MOONMCP_MAX_CONCURRENCY`	`20`	Max concurrent outbound connections.
`MOONMCP_TIMEOUT`	`10`	Default request timeout (seconds).
`MOONMCP_USER_AGENT`	`Mozilla/5.0 … Chrome/131 …`	User-Agent for HTTP probing (browser-like by default so the probe traffic does not fingerprint the tool).
`MOONMCP_ALLOW_EXTERNAL_TOOLS`	`1`	Allow shelling out to installed CLIs.
`MOONMCP_EXTERNAL_TIMEOUT`	`300`	Hard ceiling on any external CLI run (seconds).
`MOONMCP_SCREENSHOT_DIR`	(temp dir)	Where the `screenshot` tool writes PNGs.
`MOONMCP_SHODAN_API_KEY`	(none)	Enables the full Shodan API (else free InternetDB).
`MOONMCP_NVD_API_KEY`	(none)	Raises the NVD CVE-lookup rate limit.

The scope model

Scope is MoonMCP's core safety guardrail. Entries are matched like a bug-bounty program:

Entry	Matches
`example.com`	the apex and every subdomain
`*.example.com`	subdomains only (not the apex)
`api.example.com`	that exact host (and deeper labels under it)
`203.0.113.10`	a single IP
`10.0.0.0/8`	a CIDR range (IPv4 or IPv6)

Exclusions always win over inclusions, so scope_add example.com + scope_exclude admin.example.com authorises everything under example.com except admin.example.com. When enforcement is on and the scope is empty, active tools refuse to run until you authorise a target — a deliberate "fail closed" default.

Passive OSINT tools also scope-check the apex, so MoonMCP only enumerates assets you've declared authorised.

Defence in depth. Beyond the allowlist, MoonMCP:

Blocks private/reserved IPs (RFC1918, loopback, link-local incl. the 169.254.169.254 cloud-metadata endpoint, and carrier-grade-NAT 100.64.0.0/10 where Alibaba/OCI metadata lives) by default — an SSRF guard no active tool can bypass, even if a broad CIDR was added. Flip MOONMCP_BLOCK_PRIVATE=0 for authorised internal engagements.
Pins the vetted IP — the HTTP client resolves each hop's host once for the SSRF guard and dials that address (with the original hostname as Host/TLS SNI), so a short-TTL DNS-rebinding name can't pass the guard and then re-resolve to a private IP at connect time.
Re-checks redirects — the HTTP client refuses to follow a Location that leaves the scope, and reports it as redirect_blocked instead; crossing to a different origin drops every non-allowlisted header so no credential leaks onward.
Scope-checks external-CLI targets — run_scanner extracts and validates the host/URL from its args (including obfuscated decimal/hex/IPv6 IP encodings), not just the optional target field.

Program profiles (one header per program)

Bug-bounty programs each want their own identifying header on your traffic so their WAF/SOC recognises authorised testing. A program profile bundles that with the program's scope:

program_add(name="acme", scope="*.acme.com, api.acme.io",
            exclude="blog.acme.com",
            header="X-HackerOne-Research: yourhandle",
            user_agent="acme-recon/1.0")     # activates by default
program_use(name="acme")                     # switch engagements later

Activating a program swaps in its scope and auto-attaches its header + User-Agent to every in-scope request (through the same merge path as auth_set, so it never leaks to out-of-scope hosts). Profiles persist to MOONMCP_STATE_DIR, so a restart resumes the same engagement. Engagement credentials from auth_set still layer on top and win on a key collision.

How a tool call is processed

Every packet-sending tool wears one decorator — @active_tool — that is the single place scope lives, so behaviour is uniform and safe:

Normalise the target — a URL, host:port, bracketed IPv6 or bare host is reduced to a canonical host.
Classify & gate — the tool declares its class via the decorator: passive OSINT (third-party datasets, e.g. ip_intel, cve_search) runs without touching the target; light active (@active_tool(), e.g. http_probe, favicon_hash) and intrusive (@active_tool(intrusive=True), e.g. port_scan, waf_efficacy) route through _require_scope, which fails closed if the host isn't in scope, is a blocked private IP, or — for intrusive tools — MOONMCP_ALLOW_INTRUSIVE is off. A CI guard test asserts every packet-sending tool carries the gate, so an un-gated capability can't ship.
Rate-limit — all outbound traffic passes one shared token-bucket + concurrency Governor, so a fan-out never exceeds MOONMCP_RATE_LIMIT.
Execute on the async stdlib layer (blocking calls wrapped in asyncio.to_thread), preferring an installed CLI when present and detected.
Structure the result — dataclasses are converted to clean JSON; the HTTP client caps body size and re-checks redirects against scope.
Contain failures — the @active_tool gate (and the @safe_tool wrapper it applies) turns scope/validation errors into structured {"error": …} objects instead of exceptions, so one bad input never crashes the session.

Augmenting with external CLIs

MoonMCP has native, stdlib implementations for the whole recon workflow, but it gets sharper when best-in-class tools are on PATH — on Kali most already are. It auto-detects and can run 36 tools, grouped by category:

Category	Tools
subdomain	`subfinder`, `amass`, `assetfinder`, `subjack`
dns	`dnsx`, `dnsrecon`, `dnsenum`, `asnmap`
http	`httpx`, `whatweb`, `wafw00f`, `gowitness`
crawl / url	`katana`, `hakrawler`, `gospider`, `gau`, `waybackurls`
content 🔸	`ffuf`, `feroxbuster`, `gobuster`, `dirb`, `arjun`
port 🔸	`naabu`, `nmap`, `masscan`
vuln / cms 🔸	`nuclei`, `nikto`, `wpscan`, `sqlmap`, `dalfox`
tls	`sslscan`, `sslyze`, `testssl.sh`, `tlsx`
decompile	`ilspycmd`, `monodis`

🔸 = intrusive — run_scanner gates these behind MOONMCP_ALLOW_INTRUSIVE (on top of the scope check), exactly like the native intrusive tools. If a tool is missing, MoonMCP returns a clear note and the native fallback to use instead — nothing errors out. Call external_tools for the live, categorised inventory (installed + install hints).

Note: the ProjectDiscovery httpx binary and the Python httpx library share a name. MoonMCP detects and ignores the Python shim so it won't be mistaken for the scanner.

Architecture

moonmcp/
├── server.py        # FastMCP server: 158 tools, 11 resources, 9 prompts (@active_tool = the one scope gate)
├── catalog.py       # self-describing tool map (tool_catalog): families + gate flags + workflow
├── confirm.py       # finding-confirmation scoring (differential + OAST + signatures)
├── cvss.py          # CVSS 3.1 base-score calculator
├── web/probes.py    # active detectors: SSTI / SQLi / SSRF / cache poisoning
├── recon/infra.py   # behavioural infra analysers (backend fleet, DNS, vhost, rate-limit)
├── intel/oast_server.py  # built-in OAST callback catcher (self-host)
├── memory.py        # shared persistent memory hub (SQLite + FTS5, trust/provenance tags)
├── intercept.py     # Burp-style repeater / intruder / passive scan + request-response history
├── programs.py      # bug-bounty engagement profiles (per-program scope + header + UA)
├── prompts.py       # operator system prompts (see docs/SYSTEM_PROMPTS.md)
├── scope.py         # ScopeManager — the authorization guardrail
├── config.py        # env-driven Settings
├── context.py       # shared Settings + Scope + rate Governor + HttpClient + Programs
├── net/             # stdlib networking (async via asyncio.to_thread)
│   ├── http.py      #   urllib-based HTTP client w/ redirect tracing + rate limit
│   ├── dns.py       #   getaddrinfo + DNS-over-HTTPS (+ optional dnspython)
│   ├── tls.py       #   ssl-based cert inspection + TLS version/cipher/ALPN profile
│   ├── jarm.py      #   JARM active TLS fingerprint (verified vs salesforce/jarm)
│   ├── ports.py     #   asyncio TCP connect-scan
│   └── ratelimit.py #   token-bucket + concurrency governor
├── recon/           # subdomains, fingerprint, headers, wayback, content, crawl, secrets, binary, favicon, origin, config_audit
├── web/             # cors, graphql, waf(+efficacy), jwt, methods, takeover, redirect, exposure, screenshot, behavior
├── intel/           # cve (NVD), shodan, email (SPF/DMARC/DKIM/CAA), asn (ASN/cloud/reverse-IP), search (multi-engine), reader (OSINT page reader)
├── reporting.py     # pure Markdown report renderer
├── findings.py      # session findings store (findings:// resource)
├── knowledge/       # injection KB + techniques/PoC catalog (injections:// / techniques:// resources)
└── external/        # optional CLI detection + safe invocation

Everything is async and shares one rate limiter, so recon traffic stays polite. Blocking stdlib calls are wrapped with asyncio.to_thread; port scanning uses native asyncio streams.

Development

uv venv && source .venv/bin/activate
uv pip install -e ".[dev,enhanced]"
pytest -q          # 190+ tests: scope logic, the @active_tool gate, program profiles, parsers, web-app checks, local-server integration
ruff check .

Tests are fully offline — network-dependent parsers are covered with fixtures, and the HTTP/port/content tools are exercised against a local http.server.

Ethics & legal

MoonMCP is a defensive/authorised-research tool. Only use it against systems you own or have explicit written permission to test (e.g. an in-scope bug-bounty target). Respect program rules, rate limits and the law. The authors accept no liability for misuse.

License

MIT — see LICENSE.

Available Tools

22 tools

analyze_headersA

Fetch a URL and audit its HTTP security headers.

Grades (A-F) the presence of HSTS, CSP, X-Frame-Options, X-Content-Type- Options, Referrer-Policy and Permissions-Policy; flags information-leaking headers (Server, X-Powered-By, ...) and risky Set-Cookie flags. In scope only.

ParametersJSON Schema

Name	Required	Description	Default
`target`	Yes

TDQS

A3.7/5.0

Behavior3/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 the grading and flagging behavior but omits side effects like network requests, authentication needs, or error handling. It is adequate but not thorough for a tool that fetches external URLs.

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 concise, front-loading the primary action. It lists specific headers in a structured manner, but could be slightly more streamlined. Still, every sentence serves a purpose.

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

Completeness4/5

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

For a single-parameter tool with no output schema, the description covers what is audited (headers, leaks, cookies) and notes the 'in scope' constraint. It is fairly complete, though additional detail on return format or errors would improve it.

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

Parameters4/5

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

The only parameter 'target' has 0% schema description coverage. The description clarifies that it expects a URL ('Fetch a URL'), adding semantic meaning beyond the bare schema type 'string'. This compensates for the schema gap.

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 fetches a URL and audits HTTP security headers, listing specific headers and their grades. It also mentions flagging information-leaking headers and risky cookie flags, distinguishing it from siblings like tls_inspect or http_probe.

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 explicit guidance on when to use this tool versus alternatives. The phrase 'In scope only' implies a constraint but does not offer criteria for selection or exclusions, leaving the agent to infer usage context.

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

content_discoveryA

Probe an in-scope host for common sensitive paths (admin panels, API docs, .git/.env, backups, config files, ...) using a compact built-in wordlist or a caller-supplied one. Reports each path's status, size and content type. Intrusive: requires MOONMCP_ALLOW_INTRUSIVE and the host to be in scope.

ParametersJSON Schema

Name	Required	Description	Default
`target`	Yes
`wordlist`	No
`concurrency`	No

TDQS

A4.2/5.0

Behavior4/5

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

Discloses intrusive nature and required permissions. Reports what is returned (status, size, content type). No annotations provided, so description carries burden. Lacks details on concurrency and rate limiting, but overall good.

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?

Two well-structured sentences. First sentence states purpose and scope, second details behavior and requirements. No wasted words.

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

Completeness4/5

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

Fairly complete given no annotations or output schema. Covers purpose, permissions, parameters partially. Missing concurrency explanation, but overall adequate for agent selection.

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 0%, description adds meaning for 'target' (in-scope host) and 'wordlist' (built-in or caller-supplied). Does not explain 'concurrency' parameter.

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?

Description clearly states the tool probes an in-scope host for common sensitive paths, providing specific examples like admin panels, .git, etc. It distinguishes from siblings by focusing on sensitive path discovery.

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?

Provides clear context: requires MOONMCP_ALLOW_INTRUSIVE and host in scope. Mentions built-in vs caller-supplied wordlist. Does not explicitly state when not to use or alternatives.

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

cve_lookupA

Look up a single CVE by ID (e.g. CVE-2021-44228) from the NVD database.

Returns description, CVSS score/severity/vector, CWE mappings and references.

ParametersJSON Schema

Name	Required	Description	Default
`cve_id`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

No annotations provided, but the description adequately explains what the tool returns: description, CVSS score/severity/vector, CWE mappings, and references. It implies a read-only, non-destructive operation.

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?

Two sentences: first states purpose and syntax, second details outputs. No wasted words, front-loaded with the most important information.

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

Completeness4/5

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

For a single-parameter lookup tool with no output schema or annotations, the description provides sufficient information about purpose, input format, and output content. Missing details like rate limits or data source specifics, but acceptable for this complexity.

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 single parameter 'cve_id' is given an example format (e.g., CVE-2021-44228) in the description, which adds significant meaning beyond the schema's minimal title. Schema coverage is 0%, so the description compensates well.

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?

Description clearly states the tool looks up a single CVE by ID, specifies the resource (NVD database), and distinguishes from sibling tools like cve_search which likely perform broader searches.

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?

It explicitly says 'Look up a single CVE by ID', providing clear context for when to use this tool. While no explicit when-not-to-use or alternatives are given, the sibling list implies cve_search is for broader queries.

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

cve_searchA

Keyword-search the NVD for CVEs (e.g. 'apache log4j 2.14').

Results are sorted most-severe first by CVSS base score. Use this to map a fingerprinted product/version to known vulnerabilities.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`keyword`	Yes

TDQS

A3.8/5.0

Behavior3/5

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

Discloses that results are sorted by CVSS base score (descending). However, no annotations exist, and the description does not mention rate limits, pagination, or response format, leaving gaps in behavioral understanding.

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?

Two sentences with zero waste. Front-loaded with verb, resource, and example, making it immediately actionable.

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?

Covers core purpose and sorting behavior but lacks explanation of return fields, pagination, or result format. For a search tool with no output schema, this is a gap. Sibling tools like cve_lookup hint at additional functionality but not described.

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

Parameters2/5

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

Schema has two parameters (keyword, limit) with 0% description coverage. Description only illustrates 'keyword' via example and does not explain 'limit' or its default, failing to add significant meaning beyond the schema.

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?

Description clearly states 'Keyword-search the NVD for CVEs' with a concrete example, distinguishing it from siblings like cve_lookup (direct lookup) and vuln_scan (broader scanning).

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?

Explicitly says 'Use this to map a fingerprinted product/version to known vulnerabilities', providing clear context. Does not explicitly state when not to use or mention alternatives, but sibling tool cve_lookup implies a different use case.

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

dns_lookupA

Resolve a host's DNS records (A/AAAA, plus MX/NS/TXT/CNAME/SOA/CAA when dnspython is installed) and attempt a reverse PTR lookup on its A records. Requires the target to be in scope.

ParametersJSON Schema

Name	Required	Description	Default
`target`	Yes

TDQS

A4/5.0

Behavior4/5

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

The description discloses a dependency (dnspython for certain record types) and that it attempts a reverse PTR lookup. With no annotations provided, it carries the full burden and does so well, though it omits details on error handling or result format.

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?

Two sentences, no unnecessary words. Front-loaded with the main action and key details. Efficient and to the point.

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

Completeness4/5

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

Given the tool's simplicity (one required parameter, no output schema), the description covers the main functionality, dependency, and a secondary action (reverse lookup). It is complete enough for an agent to understand what to expect.

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 0%, so the description must compensate. It clarifies the 'target' parameter is a hostname for DNS resolution, but does not specify format (e.g., FQDN) or validate constraints beyond scope. Adds some meaning but not comprehensive.

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 'resolve' and the resource 'host's DNS records', listing specific record types (A/AAAA, MX/NS/TXT/CNAME/SOA/CAA) and reverse PTR lookup. This distinguishes it from sibling tools like 'enumerate_subdomains' or 'host_intel'.

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 mentions a prerequisite ('target must be in scope') but does not provide guidance on when to use this tool over alternatives like 'enumerate_subdomains' or 'host_intel'. Usage context is implied but not explicit.

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

enumerate_subdomainsA

Passively enumerate subdomains of a domain via free OSINT sources.

Queries certificate transparency (crt.sh), HackerTarget, AnubisDB and AlienVault OTX in parallel and merges the results. Passive — no packets are sent to the target itself. sources optionally restricts which providers to use (see server_status / available list: crtsh, hackertarget, anubis, otx).

ParametersJSON Schema

Name	Required	Description	Default
`domain`	Yes
`sources`	No

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations provided, the description discloses key behavioral traits: it is passive (no packets sent), queries multiple sources in parallel, merges results, and allows source restriction. It does not mention rate limits or data freshness, but for a read-only tool the disclosure is sufficient.

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 concise with three focused sentences, front-loading the core purpose. No superfluous words, and the information is well-structured for quick parsing.

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?

While the description covers purpose, parameters, and behavior, it lacks output details (e.g., format of results, additional metadata) and does not mention authentication requirements. Given no output schema, this missing information reduces completeness for an agent expecting to process results.

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 description adds meaning beyond the schema by explaining the `sources` parameter's purpose (restrict providers) and referencing `server_status` for available options. Although the schema has 0% description coverage, the description compensates well for both parameters.

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 specific verb 'enumerate subdomains' and the resource 'domain', and distinguishes it from sibling reconnaissance tools by specifying it is passive and uses OSINT sources. This makes the tool's purpose immediately clear and distinct.

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 provides clear context for when to use the tool (passive subdomain enumeration) and mentions optional provider restriction. However, it does not explicitly state when not to use it or suggest alternative tools for active enumeration, though this is implied.

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

external_toolsA

List the external security CLIs MoonMCP knows about and whether each is installed on PATH, plus the native MoonMCP fallback for each. Use before calling run_scanner or vuln_scan to know what is available.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description carries the burden. It implies a read-only listing operation with no side effects, and adds detail about the output (CLI list, install status, fallback). It does not explicitly state safety, but the behavior is clear from 'List'. Additional context about rate limits or auth is not needed for this simple listing tool.

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 consists of two concise sentences with no unnecessary words. The first states functionality, the second provides usage guidance. Every sentence adds value.

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

Completeness5/5

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

Given the tool has no parameters, no output schema, and no annotations, the description fully covers what the agent needs: what it returns and when to use it. It is complete for its purpose.

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

Parameters4/5

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

The tool has zero parameters, so the schema coverage is 100% by default. The baseline for such cases is 4. The description does not need to add parameter information.

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 lists external security CLIs known to MoonMCP, their installation status on PATH, and the native MoonMCP fallback for each. It uses specific verb 'List' and resource 'external security CLIs', and distinguishes from siblings run_scanner and vuln_scan by advising use before them.

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 explicitly advises use before calling run_scanner or vuln_scan to know what is available. This provides clear context, though it doesn't mention other scenarios or when not to use. Still, it's helpful guidance.

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

fingerprintA

Fetch a URL and fingerprint its technology stack: web server, CDN/WAF, language/runtime, frameworks, CMS and front-end libraries, with version hints and the evidence for each match. In scope only.

ParametersJSON Schema

Name	Required	Description	Default
`target`	Yes

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It explains the tool fetches a URL and returns version hints with evidence, but does not disclose potential rate limits, side effects, or permission requirements.

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 that efficiently conveys the tool's action and outputs, with no wasted words.

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

Completeness4/5

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

For a simple one-parameter tool, the description covers the purpose, scope constraint, and high-level return content (version hints and evidence). Without an output schema, it provides sufficient context, though details on error handling or out-of-scope behavior are missing.

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?

Schema coverage is 0%, so description compensates. It implies 'target' is a URL by stating 'Fetch a URL,' adding meaning beyond the schema's bare 'Target' title. More explicit format details would improve clarity.

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 fetches a URL and fingerprints its technology stack, listing specific categories (web server, CDN/WAF, etc.). This distinguishes it from sibling tools like analyze_headers or host_intel.

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 includes 'In scope only,' which gives a constraint on usage, but does not provide when to use this tool versus alternatives or when to avoid it.

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

host_intelA

Look up an IP's exposure via Shodan.

Uses Shodan's free InternetDB by default (open ports, hostnames, CPEs, known CVEs, tags); uses the full Shodan API automatically if a key is configured. Passive — queries Shodan, not the target.

ParametersJSON Schema

Name	Required	Description	Default
`ip`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

No annotations, so description carries burden. Discloses passive behavior, two modes (free InternetDB vs full API if key configured). Could mention rate limits or data freshness, but covers key points.

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?

Two short paragraphs, no redundant information. Every sentence adds value. Front-loaded with main action.

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

Completeness4/5

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

No output schema, so description should describe return values. It lists some free InternetDB data (ports, hostnames, etc.) but could explicitly state output format. Still complete enough for a simple lookup tool.

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?

Only one parameter 'ip' with 0% schema coverage. Description context implies the parameter is an IP address. No format details (IPv4/IPv6, CIDR), but purpose makes it clear. Adequate given simplicity, but schema coverage gap warrants slight deduction.

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?

Description clearly states 'Look up an IP's exposure via Shodan.' The verb 'look up' and resource 'IP's exposure' are specific. Distinguishes from siblings like 'port_scan' (active) and 'dns_lookup' (DNS records) by specifying Shodan as the source.

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?

Describes when to use: passive reconnaissance via Shodan. Mentions it is passive and queries Shodan, not the target, implying use case. Does not explicitly list when not to use or alternatives, but context from sibling names provides differentiation.

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

http_probeA

Send a single HTTP(S) request to an in-scope target and return a structured result: status, reason, response headers, timing, the full redirect chain, page title and body size. Accepts a bare host (defaults to https) or a full URL. The primary building block for web recon.

ParametersJSON Schema

Name	Required	Default
`method`	No	GET
`target`	Yes
`verify_tls`	No
`follow_redirects`	No

TDQS

A3.7/5.0

Behavior3/5

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

Without annotations, the description discloses key behaviors: single request, default HTTPS, return fields, and redirect chain. However, it omits error handling, rate limits, and scope enforcement 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?

Two sentences, dense with information, first sentence front-loads the action and return fields, second clarifies input flexibility. No wasted words.

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?

The description covers the core functionality and return values adequately for a simple tool, but lacks details on error cases, prerequisites, or scope handling that would be expected given no annotations or output schema.

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?

With 0% schema description coverage, the description adds value by explaining the target parameter (bare host vs full URL, default https) but does not explicitly describe method, verify_tls, or follow_redirects. The return fields hint at some behavior.

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 sends a single HTTP request and returns a structured result including specific fields. It distinguishes itself as 'the primary building block for web recon' among siblings like fingerprint or content_discovery.

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 basic HTTP probing but lacks explicit guidance on when to use this tool versus alternatives. No exclusions or prerequisites are mentioned.

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

port_scanA

TCP connect-scan an in-scope host. ports is 'top' (a curated common set) or a spec like '80,443,8000-8100'. Optionally grabs service banners. Unprivileged and non-malformed (full handshake). Intrusive: requires MOONMCP_ALLOW_INTRUSIVE and the host to be in scope.

ParametersJSON Schema

Name	Required	Default
`ports`	No	top
`target`	Yes
`timeout`	No
`grab_banner`	No

TDQS

A3.6/5.0

Behavior4/5

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

With no annotations, the description fully bears the burden. It discloses that the scan is 'unprivileged and non-malformed (full handshake)' and 'intrusive' requiring explicit permission. This gives good insight into behavior. Missing details about potential side effects or limitations are minor.

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 consists of three concise sentences, each adding information: scan type, port parameter, banner grabbing, and prerequisites. No extraneous content. Efficiently structured.

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 no output schema and no annotations, the description should explain the output format or what is returned (e.g., list of open ports, service banners). This is missing. Also, there is no mention of error conditions or result interpretation. For a scan tool, this is a significant gap.

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 0%, so the description must compensate. It explains the 'ports' parameter format ('top' or ranges) and mentions 'optionally grabs service banners' (grab_banner). However, 'timeout' and 'target' are not further explained, leaving gaps. Partial but useful guidance.

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

Purpose4/5

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

The description clearly specifies 'TCP connect-scan an in-scope host', indicating the verb (scan) and resource (host ports). It is distinct from siblings like 'vuln_scan' or 'dns_lookup', though no explicit differentiation is made. The purpose is clear and specific.

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 mentions prerequisites: requires MOONMCP_ALLOW_INTRUSIVE and host in scope. However, it does not provide guidance on when to use this tool versus alternatives such as 'vuln_scan' or 'content_discovery'. The context is clear but lacks exclusions or alternative recommendations.

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

recon_targetA

One-shot passive+light recon of an in-scope domain.

Chains the safe tools into a single report: subdomain enumeration, DNS resolution, TLS certificate (with SANs), an HTTP probe, security-header grade, and a technology fingerprint of the apex. No intrusive scanning is performed. Ideal as the first call against a new target.

ParametersJSON Schema

Name	Required	Description	Default
`domain`	Yes
`include_subdomains`	No

TDQS

A4/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It discloses non-intrusive, safe nature and that it chains other tools. However, it does not detail rate limits, error handling, or side effects, leaving gaps.

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?

Two concise sentences with no wasted words. The first sentence states the core purpose; the second elaborates without redundancy.

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

Completeness4/5

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

Description covers the key actions (subdomain enumeration, DNS, TLS, HTTP probe, header grade, tech fingerprint) adequately for a composite tool, though it lacks details on output format or error behavior. No output schema present.

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 0%. Description mentions 'domain' but does not explain the 'include_subdomains' parameter or provide additional detail beyond the schema, so it adds limited value for the boolean parameter.

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 explicitly states it performs 'one-shot passive+light recon' and lists specific tasks: subdomain enumeration, DNS, TLS, HTTP probe, header grade, and tech fingerprint. It clearly distinguishes from sibling tools by being a composite of safe tools.

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?

Description recommends it as 'the first call against a new target' and states 'no intrusive scanning'. It implicitly differentiates from more specific or intrusive tools, but does not explicitly list when not to use or name alternatives.

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

run_scannerA

Run an installed external security CLI and return its output.

tool must be one of the known tools (subfinder, httpx, nuclei, naabu, nmap, katana, ffuf, gau, dnsx, amass, waybackurls). args are passed through verbatim. If target is given it is scope-checked first. If the tool is missing, returns a structured note and the native fallback to use instead. JSONL output is auto-parsed. Gated by MOONMCP_ALLOW_EXTERNAL_TOOLS.

ParametersJSON Schema

Name	Required	Description	Default
`args`	Yes
`tool`	Yes
`target`	No

TDQS

A4.5/5.0

Behavior5/5

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

With no annotations, the description fully carries the burden. It discloses: allowed tool list, verbatim argument passing, optional target with scope check, missing tool fallback (structured note + native command), JSONL auto-parsing, and an environment variable gate. This is comprehensive.

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 two sentences: the first states the core purpose, the second elaborates key behaviors. Every phrase earns its place with no redundancy.

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

Completeness5/5

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

Given the tool's complexity (external command execution) and minimal schema, the description covers all critical aspects: allowed tools, argument handling, target scope, error behavior, output parsing, and access gating. No output schema exists, but the description adequately hints at return format.

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?

Schema coverage is 0%, so the description must compensate. It explains the allowed values for 'tool', the verbatim nature of 'args', and the optional 'target' with scope checking. While it doesn't detail argument syntax, it adds substantial meaning beyond the schema's bare type/title.

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 starts with a clear verb+resource: 'Run an installed external security CLI and return its output.' It distinguishes from sibling tools by specifying it runs known external tools, which sets it apart from other recon/scan 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 lists the allowed tools and provides some usage constraints (verbatim args, scope checking, env gating) but does not explicitly compare to siblings or state when not to use it. It implies a specific use case but lacks direct exclusions.

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

scope_addA

Authorize a target for active testing.

Accepts a domain (example.com matches the apex and every subdomain), a wildcard (*.example.com for subdomains only), an exact host (api.example.com), an IP, or a CIDR (10.0.0.0/8). Active tools refuse to touch anything not covered by the scope.

ParametersJSON Schema

Name	Required	Description	Default
`target`	Yes

TDQS

A4.6/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden. It discloses a key behavioral trait: active tools will not touch anything not covered by the scope. No contradictions or omissions noted.

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 concise paragraph, front-loaded with the primary action, and includes examples efficiently. Every sentence adds value.

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

Completeness5/5

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

Given the tool's simplicity (one parameter, no output schema), the description is fully complete. It covers what the tool does, how to use it, and the impact on active testing.

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

Parameters5/5

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

Schema coverage is 0%, so the description must compensate. It thoroughly explains the 'target' parameter with examples (domain, wildcard, exact host, IP, CIDR), adding essential meaning beyond the schema's bare 'string' type.

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 a specific verb ('Authorize') and resource ('target for active testing'), clearly stating the tool's function. It distinguishes from sibling tools like scope_remove and scope_exclude by focusing on adding scope.

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 explains when to use the tool (to add targets to active testing scope) and implies that active tools will refuse non-scoped targets. It lacks explicit mention of alternatives or when not to use it, but the context is clear.

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

scope_excludeA

Mark a target as out-of-scope. Exclusions always override the allowlist.

ParametersJSON Schema

Name	Required	Description	Default
`target`	Yes

TDQS

A3.6/5.0

Behavior3/5

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

Without annotations, the description carries the full burden. It discloses one important behavioral trait (exclusions override allowlist), but lacks information on persistence, reversibility, or permissions. More transparency is needed 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.

Conciseness5/5

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

Two sentences with no redundant information. The verb 'Mark' and resource 'target as out-of-scope' are front-loaded, and the sentence about override adds value efficiently.

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

Completeness3/5

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

For a simple tool, the description covers purpose and key behavior but omits context like target format, statefulness, and how to undo an exclusion. This gap may hinder agents unfamiliar with the domain.

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

Parameters2/5

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

With 0% schema description coverage for the single parameter 'target', the description adds no extra meaning about what constitutes a valid target (e.g., domain, IP). The schema only provides the name, leaving the agent to guess the format.

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 marks a target as out-of-scope, with a distinguishing behavioral note that exclusions override the allowlist. This differentiates it from sibling tools like scope_add and scope_remove.

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 exclusion but does not explicitly state when to use this tool versus scope_remove or scope_add, nor provides alternative guidance. The note about override is helpful but insufficient for clear decision-making.

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

scope_listA

List the current in-scope and out-of-scope entries.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.9/5.0

Behavior3/5

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

No annotations exist, so the description carries full burden. It only states 'list', indicating a read operation, but lacks details on authentication, real-time vs cached data, or output format. This is minimal but not contradictory.

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?

Single short sentence, front-loaded with action and object. No wasted words.

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 parameters and no output schema, the description is minimal but sufficient for a simple list. However, it lacks details about output representation or potential side effects, which would be helpful for an agent.

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?

Tool has zero parameters, so baseline score 4 applies. Description adds no parameter info, but no parameters exist to document.

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?

Description uses specific verb 'List' and resource 'scope entries', clearly distinguishing from sibling tools that add, exclude, or remove entries. It precisely states what the tool does.

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?

Description implies usage for viewing scope but provides no explicit context on when to use versus alternatives like recon_target or scope_add. No exclusions or prerequisites are mentioned.

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

scope_removeC

Remove a previously added scope entry (from allow or deny lists).

ParametersJSON Schema

Name	Required	Description	Default
`target`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description carries full burden but only states the action. It does not disclose what happens if the target does not exist, whether removal is irreversible, or any side effects on associated data.

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 with no filler words. Front-loaded with key information. Could be expanded slightly without harming 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 only one parameter, no output schema, and non-trivial sibling tools, the description is insufficient. It omits return behavior, error cases (e.g., missing target), and prerequisite conditions for safe invocation.

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

Parameters2/5

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

The sole parameter 'target' lacks format specification (e.g., domain, IP, regex). Schema description coverage is 0%, and the description only says 'previously added scope entry' without clarifying acceptable values.

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?

Description clearly states the verb 'remove', resource 'scope entry', and context 'from allow or deny lists'. It effectively distinguishes the tool from siblings like scope_add and scope_list.

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 explicit guidance on when to use this tool versus alternatives like scope_add or scope_exclude. The description only implies that the entry must have been previously added, but lacks contextual cues.

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

server_statusA

Report MoonMCP's configuration and capabilities.

Shows the active scope, whether enforcement/intrusive scanning are enabled, which optional enhancers (dnspython) are present, and which external security CLIs (nuclei, httpx, subfinder, nmap, ...) were detected on PATH. Call this first to understand what the server can do in the current environment.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.8/5.0

Behavior4/5

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

Without annotations, the description carries full burden. It details what is reported (scope, scanning flags, enhancers, CLIs) and implies non-destructive read. Could explicitly state it has no side effects, but high coverage earns a 4.

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?

Two efficient paragraphs with no filler. Every sentence adds value; front-loaded with purpose.

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

Completeness5/5

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

Despite no output schema, the description enumerates exactly what the tool reports. No gaps remain for a status tool.

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

Parameters5/5

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

No parameters exist, so schema coverage is 100%. Description adds no redundant info; baseline is met.

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?

Verb 'Report' and resource 'MoonMCP's configuration and capabilities' are clear. No sibling tool serves this status function, so it is well-distinguished.

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

Usage Guidelines5/5

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

Explicitly instructs 'Call this first to understand what the server can do' — provides clear usage context and implies sequencing relative to other tools.

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

tls_inspectA

Inspect a host's TLS certificate: subject, issuer, validity window, days until expiry, negotiated protocol/cipher, and — most useful for recon — the Subject Alternative Names, which often reveal sibling hostnames. In scope only.

ParametersJSON Schema

Name	Required	Description	Default
`port`	No
`target`	Yes

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It lists the types of information returned and constrains operation to in-scope targets, but it does not disclose whether the tool is read-only, any potential side effects, authorization requirements, or error handling behavior.

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 sentence that efficiently conveys the tool's purpose, key outputs, and a usage hint. It is front-loaded with the core action, though a slightly more structured format could improve readability.

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

Completeness4/5

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

For a tool with 2 parameters and no output schema, the description covers the main purpose and important outputs. It lacks details on return format or error cases, but given the tool's simplicity, it is reasonably complete.

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 0%, so the description must compensate. It implies 'target' is a host and mentions default port 443, but does not fully describe parameter semantics or constraints. It adds some value beyond the raw schema but not complete clarity.

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 inspects a host's TLS certificate and lists specific details returned (subject, issuer, validity, etc.), with a strong emphasis on Subject Alternative Names for recon. It distinguishes itself from sibling tools by focusing on TLS inspection and operating only on in-scope targets.

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 TLS certificate inspection and notes 'In scope only' as a constraint. However, it does not provide explicit guidance on when to use this tool versus alternatives like fingerprint or dns_lookup, nor does it specify conditions when not to use it.

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

vuln_scanA

Run a nuclei template-based vulnerability scan against an in-scope target.

Requires nuclei to be installed (there is no safe stdlib equivalent for template-based scanning). templates maps to nuclei -t and severity to -severity (e.g. 'critical,high'). Intrusive: requires MOONMCP_ALLOW_INTRUSIVE, MOONMCP_ALLOW_EXTERNAL_TOOLS and the host in scope.

ParametersJSON Schema

Name	Required	Description	Default
`target`	Yes
`severity`	No
`templates`	No

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description discloses intrusive behavior, external tool dependency, and parameter mapping. It does not detail output or side effects, but adequately characterizes the tool as a non-safe, external-scanning operation.

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?

Two short paragraphs, first sentence captures purpose, every sentence adds critical information (prerequisites, parameter mapping, restrictions). No wasted words.

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, the description lacks details about return values or result formatting, which could help an agent anticipate the response. Otherwise, it covers prerequisites and parameter usage adequately.

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?

Schema coverage is 0%, so the description must explain parameters. It maps 'templates' to nuclei -t and 'severity' to -severity with an example. 'Target' is implied by context but not further detailed; overall adds value beyond the schema.

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 'Run a nuclei template-based vulnerability scan against an in-scope target,' specifying the verb, resource, and tool. It distinguishes from siblings like port_scan and run_scanner by explicitly mentioning nuclei and templates.

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 provides prerequisites (nuclei installed, no safe stdlib equivalent), and intrusive nature requiring env vars. It implies when to use but does not explicitly name alternatives among siblings.

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

wayback_urlsA

Fetch historical URLs for a domain from the Internet Archive (Wayback).

Passive. Surfaces old endpoints, parameters and forgotten files. Flags 'interesting' URLs (backups, configs, .git, api, tokens, ...) separately.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`domain`	Yes
`include_subdomains`	No

TDQS

A3.6/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 that the tool is passive and that it flags interesting URLs. It does not mention rate limits, authentication needs, or output format. Provides basic behavioral context but lacks detail on non-destructive guarantees or limitations.

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?

Three sentences, no fluff. Front-loads the core purpose and key differentiator ('passive'). Efficiently communicates the tool's value and special feature (flagging interesting URLs). Every sentence contributes meaningfully.

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

Completeness3/5

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

For a tool with 3 parameters and no output schema, the description covers the main purpose and the interesting URL flagging feature. However, it does not explain the behavior of limit or include_subdomains, nor does it describe the output format or any operational constraints. Adequate for a simple tool but leaves gaps that could impact correct invocation.

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

Parameters2/5

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

Schema description coverage is 0%, and the description does not explain the 'limit' or 'include_subdomains' parameters. It briefly mentions 'domain' indirectly through the main purpose and 'flags' as a concept, but provides no syntax, defaults, or usage details for individual parameters. The description fails to compensate for the lack of schema documentation.

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?

Clearly states it fetches historical URLs for a domain from the Internet Archive. Explicitly mentions surfacing old endpoints, parameters, and forgotten files, with flagged interesting URLs. Distinguishes itself from sibling tools like content_discovery (active) and enumerate_subdomains (different scope).

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?

Describes the tool as 'Passive,' implying suitable for passive reconnaissance. However, it does not explicitly state when to use this tool vs. alternatives, nor does it provide exclusion criteria or alternative tool suggestions. Usage context is implied but not clearly specified.

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

well_knownA

Fetch and parse a host's disclosure files: robots.txt (extracting the referenced paths), sitemap.xml (extracting URLs), security.txt and humans.txt. A quick, low-noise way to discover structure. In scope only.

ParametersJSON Schema

Name	Required	Description	Default
`target`	Yes

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It transparently lists the files fetched and what is extracted from each (paths, URLs, etc.) and mentions scope restrictions. It does not elaborate on network behavior or rate limits, but the core actions are clear.

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 concise, front-loading the main action and then listing specifics. It could be slightly more structured (e.g., breaking into sentences for each file), but it is efficient and avoids fluff.

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

Completeness4/5

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

Given the tool's simplicity (one parameter, no output schema), the description provides a complete picture of what the tool does, including which files, what is extracted, and scope. It enables an agent to assess suitability for discovery tasks.

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

Parameters2/5

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

The only parameter 'target' is not described in the description. With 0% schema description coverage, the description should clarify what 'target' expects (e.g., hostname or URL), but it fails to do so, leaving ambiguity.

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 it fetches and parses well-known files (robots.txt, sitemap.xml, security.txt, humans.txt) and extracts specific elements from each. It distinguishes itself from the sibling 'content_discovery' by being focused on these specific disclosure files.

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 notes it is 'quick, low-noise' and 'in scope only,' implying it is ideal for initial reconnaissance. However, it does not explicitly state when not to use it or provide direct alternatives among siblings.

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. Dates show when Glama detected each change.

22 tool updatesv0.1.0Jul 8, 2026
- First observedanalyze_headers
- First observedcontent_discovery
- First observedcve_lookup
- First observedcve_search
- First observeddns_lookup
- First observedenumerate_subdomains
- First observedexternal_tools
- First observedfingerprint
- First observedhost_intel
- First observedhttp_probe
- First observedport_scan
- First observedrecon_target
- First observedrun_scanner
- First observedscope_add
- First observedscope_exclude
- First observedscope_list
- First observedscope_remove
- First observedserver_status
- First observedtls_inspect
- First observedvuln_scan
- First observedwayback_urls
- First observedwell_known

Install Server

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

TDQS

A4/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: analyze_headers audits HTTP security headers, content_discovery probes for sensitive paths, dns_lookup resolves DNS records, fingerprint identifies technology stacks, etc. No overlapping functionality.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., analyze_headers, dns_lookup, enumerate_subdomains, port_scan). There are no mixed conventions or irregularities.

Tool Count4/5

22 tools is on the higher side but appropriate for a comprehensive security reconnaissance server. Each tool covers a specific aspect of the workflow, and there are no redundant tools. Could potentially be trimmed slightly, but overall well-scoped.

Completeness5/5

The tool set covers the full reconnaissance lifecycle: passive OSINT (subdomain enum, DNS, CVE lookup), active scanning (port scan, HTTP probe, content discovery), vulnerability scanning (nuclei), scope management, and status/configuration. No obvious gaps for the intended domain of offensive security testing.

Maintenance

ActivitySlowing

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

mcp-server
com.pentest-tools
MCP server for Pentest-Tools.com: run scans, manage findings and reports via your preffered LLM.
Penetration Testing Security
23
MCP FortressOAuth
io.github.mcp-fortress
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
Security Testing & QA Tools Penetration Testing
2
revensi
com.revensi
MCP server for the Revensi API. Scan domains from any MCP client.
Web Scraping Penetration Testing
2
KodyOAuth
io.github.kentcdodds
Personal assistant MCP server with search, execute, packages, jobs, secrets, and integrations.
Developer Tools Code Execution Command Line
2534

Related MCP Servers

mcp-osint-server
Search Web Scraping Shell Access
himanshusanecha
F
license
Not graded
quality
D
maintenance
MCP server to perform various OSINT tasks by leveraging common network reconnaissance tools.
Updated a year ago (2025-03-12 16:44 UTC)
48
-
shodan-mcp
Penetration Testing Networking & Infrastructure
tobiasGuta
F
license
Not graded
quality
B
maintenance
Passive reconnaissance MCP server powered by Shodan, enabling host lookups, search, and DNS queries gated against HackerOne scope snapshots.
Updated 4 months ago (2026-05-01 02:09 UTC)
-
recon-mcp
Penetration Testing Web Scraping
tobiasGuta
A
license
Not graded
quality
C
maintenance
A local Python MCP server for safe, human-led bug bounty recon, providing lightweight helpers for scope checks, headers, robots.txt, sitemap.xml, JavaScript URL collection, endpoint extraction, URL deduplication, evidence notes, and manual test planning.
Updated 2 months ago (2026-07-13 18:05 UTC)
MIT
Bug Bounty Assistant MCP
Penetration Testing Security
rohitprasad-code
A
license
A
quality
B
maintenance
An MCP server that provides passive and low-impact active reconnaissance tools for authorized bug bounty and security assessments, enabling LLMs to perform structured recon and generate reports.
Updated 2 months ago (2026-07-10 03:38 UTC)
11
Apache 2.0

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Moonwuk/MoonMcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

🌙 MoonMCP

Why another recon MCP server?

Tool surface

🟢 Meta / scope

🔵 Passive OSINT (never touches the target)

🟡 Active — light (benign, in-scope requests)

🕸️ Web-app checks (light active, in-scope, structured findings)

🟠 Active — intrusive (gated by MOONMCP_ALLOW_INTRUSIVE)

🗄️ Databases, data stores & advanced injection

🧰 Interception (Burp-style, native — no external proxy)

🏗️ Behavioural infrastructure (infer the infra from response variance)

🔗 Orchestration & reporting

🧠 Shared memory hub (persistent, cross-agent)

🛠️ External tools

📚 Knowledge bases

Quickstart

Add to an MCP client

Use it from a shell-based agent (no MCP client needed)

Claude Code skill

Configuration

The scope model

Program profiles (one header per program)

How a tool call is processed

Augmenting with external CLIs

Architecture

Development

Ethics & legal

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

🟠 Active — intrusive (gated by `MOONMCP_ALLOW_INTRUSIVE`)