What can you do with this server?

AynOps extends Claude with real-time cybersecurity reconnaissance capabilities, enabling professional-grade security assessments directly through Claude Desktop. * WHOIS Lookup — Retrieve domain registration data including owner, registrar, creation/expiry dates, and name servers. * DNS Enumeration — Enumerate DNS records (A, AAAA, MX, NS, TXT, CNAME, SOA) and perform common subdomain brute-forcing. * Port Scanning — Run Nmap-powered scans with multiple modes: basic (top 100 ports), service/version detection, OS detection, full 65535-port scan, or vulnerability scripts. * SSL/TLS Inspection — Inspect certificate details including issuer, validity, SANs, cipher strength, and TLS version. * Tech Stack Detection — Identify a website's web server, CMS, JavaScript frameworks, CDN, analytics tools, and security header scoring. * CVE Lookup — Search the NVD for known CVEs by software name and version (no API key required). * IP Reputation Check — Verify if an IP has been reported as malicious via AbuseIPDB (requires a free API key). * Full Recon — Run all core tools (WHOIS, DNS, port scan, SSL inspection, tech stack detection) in parallel and receive a combined security analysis in one shot.

Which integrations are available for this server?

Detects publicly accessible Google Cloud Storage buckets by testing common bucket naming patterns derived from the target domain.

AynOps

by AynOps

Overview Schema Source Related Servers Score Discussions Admin

Python

Local

📚 Table of Contents

Related MCP server: OSINT Tools MCP Server

🌐 Overview

Modern Large Language Models (LLMs) operate in sandboxed, non-deterministic execution environments devoid of native raw-socket access, packet crafting abilities, and live network reconnaissance primitives. When tasked with auditing an attack surface, AI agents are fundamentally constrained by static training cutoff boundaries and an inability to query live network interfaces.

AynOps bridges this operational divide. Built on top of the Model Context Protocol (MCP) specification using the FastMCP framework, AynOps exposes an extensible suite of deterministic cybersecurity reconnaissance tools directly to LLM agents (such as Cursor, VS Code, Claude Desktop, and custom MCP clients) over a standard JSON-RPC 2.0 stdio transport.

┌───────────────────────────┐         JSON-RPC 2.0 (stdio)         ┌────────────────────────────────────────────────────────┐
│     AI / LLM Client       │ ◄──────────────────────────────────► │                   AynOps MCP Server                    │
│ (Cursor, VS Code, Claude) │                                      │                   (Local Daemon)                       │
└───────────────────────────┘                                      └──────────────────────────┬─────────────────────────────┘
                                                                                              │
                                  ┌───────────────────────────────────────────────────────────┴──────────────────────────────┐
                                  ▼                                                           ▼                              ▼
                    ┌──────────────────────────┐                                ┌──────────────────────────┐   ┌──────────────────────────┐
                    │      Active Network      │                                │       DNS & OSINT        │   │    Web & Cloud Audits    │
                    │  • Nmap Port Scanner     │                                │   • Authoritative WHOIS  │   │   • SSL/TLS X.509 Parser │
                    │  • Team Cymru ASN BGP    │                                │   • dnspython Resolver   │   │   • HTTP Headers Linting │
                    │  • AbuseIPDB Threat Intel│                                │   • crt.sh CT Log Parser │   │   • Multi-Cloud Storage  │
                    └──────────────────────────┘                                │   • Subdomain Takeover   │   │   • Redirect Hop Tracer  │
                                                                                └──────────────────────────┘   └──────────────────────────┘

Architectural Highlights

🔒 Local-First & Zero-Telemetry Egress: AynOps runs entirely as a local daemon on your host or isolated container. Target queries, raw IP telemetry, and internal host details never transit through external telemetry collectors.
⚡ Wave-Based Concurrent Pipeline: Orchestrates complex reconnaissance tasks through an intelligent 3-wave async execution model, resolving foundational network primitives in parallel before dispatching dependent service, web, and threat intelligence probes.
🧠 Unified Heuristic Signal Extraction: Raw outputs from heterogeneous utilities (Nmap, dnspython, cryptography, socket APIs) are parsed and normalized into structured threat signals (tools/signals/) designed for direct ingestion by LLM reasoning layers.
🛠️ Standardized MCP Tool & Prompt Primitives: Fully compliant with the official Model Context Protocol standard, packaging ready-to-use tool declarations and meta-prompts (threat_analysis) for automated threat modeling workflows.

⚡ Features

AynOps is engineered from the ground up for cybersecurity engineers, red/blue teams, and security researchers seeking deterministic automation:

🔒 100% Local-First Execution: Self-hosted local daemon with zero telemetry leaks, preserving target confidentiality.
⚡ 3-Wave Asynchronous Recon Engine: Parallelized execution pipeline reducing end-to-end full recon duration by up to 70%.
🧠 Structured Heuristic Signal Extraction: Translates raw terminal outputs into normalized, machine-readable threat telemetry.
🌐 Comprehensive Perimeter Mapping: Authoritative WHOIS (RFC 3912), comprehensive DNS RR resolution, and multi-threaded dictionary subdomain brute-forcing.
📜 Certificate Transparency Log Extraction: Real-time querying of crt.sh append-only Merkle trees for passive subdomain and wildcard SSL discovery.
🛡️ Dangling DNS & Subdomain Takeover Detection: Resolves CNAME pointers against signatures for 8+ cloud providers (AWS S3, Azure, GitHub Pages, Heroku, Shopify, Fastly, Ghost, Pantheon) with active HTTP verification probing.
☁️ Multi-Cloud Storage Bucket Auditing: Generates domain keyword permutations and checks for unauthenticated public access across AWS S3, Azure Blob Storage, and Google Cloud Storage.
📧 RFC-Compliant Email Security Assessment: Audits SPF (v=spf1), DKIM selectors, and DMARC enforcement policies (p=reject/quarantine/none) with quantitative scoring (0–100).
🔍 Multi-Layer Web Technology Fingerprinting: 4-layer non-intrusive technology identification engine — HTTP response headers (Server, X-Powered-By, CDN markers), Set-Cookie cookie names, <meta name="generator"> tag parsing, and HTML/asset-path substring matching — returning structured detections with confidence scores (0–100) and evidence strings.
🔀 Deep HTTP Redirect Chain & TLS Downgrade Tracer: Hop-by-hop 3xx status analysis detecting SSL stripping, RFC 1918 internal IP address leaks, redirect loops, and cross-domain hops.
🎯 Real-Time NIST NVD v2 CVE Querying: Direct REST API integration with NIST National Vulnerability Database for CVSS v3.1/v2 base scores, CWE vectors, and exploit references without requiring API keys.
🤖 Cognitive Threat Analysis Meta-Prompt: Native MCP prompt template converting raw scan telemetry into prioritized vulnerability matrices and remediation roadmaps.
📦 Container-Ready Architecture: Bundles a production-ready Dockerfile with pre-installed Nmap and Python 3.12 for zero-dependency stdio deployment.

🛠️ Tools & Prompts

AynOps provides 17 specialized reconnaissance tools alongside structured MCP prompt templates.

1. Multi-Wave Automated Reconnaissance Pipeline (`full_recon`)

The full_recon tool orchestrates a 3-wave concurrent pipeline designed to minimize scan latency while preserving dependency order across tools:

Target Domain
     │
     ├──► [Wave 1: Base Perimeter] ──► whois_lookup + dns_enumeration + ssl_inspect + email_security_check + asn_lookup
     │
     ├──► [Wave 2: Service & Web]  ──► port_scan (service) + tech_stack_detect + headers_analyzer + cert_transparency
     │
     └──► [Wave 3: Threat Feeds]   ──► ip_reputation (AbuseIPDB - dynamically bound to resolved IP address)
     │
     ▼
Signal Aggregator (tools/signals/) ──► Unified Heuristic Security Telemetry Payload

2. Core Reconnaissance Tool Inventory (Included in `full_recon`)

Documentation status: Detailed reference pages are currently available for tools marked Available. Tools marked Pending are implemented and included in the inventory, but their dedicated documentation pages are not yet available.

Tool	Parameters	Underlying Mechanics / Standards	Telemetry Output	Docs
`whois_lookup`	`domain: str`	RFC 3912 socket lookup via `python-whois`	Registrar metadata, registration/update/expiry timestamps, nameservers, registrant organization, and ICANN domain status codes.	Available
`dns_enumeration`	`domain: str`	Multi-record DNS resolver (`dnspython`) + concurrent dictionary brute-forcing	Core Resource Records (`A`, `AAAA`, `MX`, `NS`, `TXT`, `CNAME`, `SOA`, `CAA`), enterprise SRV records (`_sip`, `_ldap`, `_xmpp-server`, `_kerberos`, `_autodiscover`), and active subdomains.	Available
`port_scan`	`target: strscan_type: strtimeout: int`	Nmap integration via `python-nmap` with configurable profiles	Port state (`open`/`filtered`), service banner detection (`-sV`), OS fingerprinting (`-O`), full-port scanning (`-p-`), and Nmap Scripting Engine vulnerability checks (`--script vuln`).	Available
`ssl_inspect`	`domain: strport: int = 443`	Direct TLS handshake & X.509 certificate parsing via `cryptography`	Certificate subject, issuer, serial number, validity window, days to expiration, Subject Alternative Names (SANs), negotiated cipher suite, and TLS protocol version; wildcard and self-signed detection, public key algorithm (`RSA`, `ECDSA`, `Ed25519`, …), TLS and cipher strength classification (`Strong`/`Good`/`Weak`), weak-version and weak-cipher flags, certificate status (`Healthy`/`Expiring Soon`/`Expired`), an overall security rating (`Excellent`/`Good`/`Fair`/`Poor`) with point-based scoring, and certificate extension URLs (OCSP, CA Issuer, CRL).	Available
`email_security_check`	`domain: str`	DNS record validation against RFC 7208, RFC 6376, and RFC 7489	SPF record parsing (`v=spf1`), DKIM selector probing, DMARC enforcement policy evaluation (`p=reject`/`quarantine`/`none`), anti-spoofing score (0–100), and remediation guidance.	Pending
`tech_stack_detect`	`domain: str`	4-layer engine: HTTP headers · `Set-Cookie` cookies · `<meta name="generator">` · HTML/asset-path substrings — with HTTPS → HTTP fallback and 512 KB body cap	Structured detections with confidence scores and evidence strings across 6 categories: web servers (nginx, Apache, IIS, Caddy), programming languages (PHP, Python, Ruby, Java, ASP.NET), CMS platforms (WordPress, Drupal, Joomla, Shopify, Wix, Ghost, Webflow, Magento), JS frameworks (React, Vue, Angular, Next.js, Nuxt.js, Svelte, jQuery, Bootstrap, Tailwind), CDN/hosting (Cloudflare, Fastly, Akamai, Vercel, Netlify, AWS CloudFront, Azure, GCP), and analytics (GA, GTM, Hotjar, Mixpanel, Segment, Facebook Pixel, Plausible, Matomo).	Pending
`cert_transparency`	`domain: str`	Append-only public Merkle tree log querying via `crt.sh`	Discovered subdomains, wildcard certificates, historical TLS certificate issuance records, and Certificate Authority log metadata without active target scanning.	Pending
`asn_lookup`	`target: str`	Team Cymru IP-to-ASN WHOIS service over TCP port 43	Autonomous System Number (ASN), BGP routing prefix, AS organization name, allocation registry (ARIN, RIPE, APNIC, LACNIC, AFRINIC), country code, and allocation date.	Pending
`ip_reputation`	`ip_address: str`	AbuseIPDB v2 REST API integration (Requires API Key)	Abuse confidence score (0–100%), total distinct abuse reports, usage classification (Data Center, ISP, Commercial), ISP metadata, and malicious activity classifications.	Pending
`headers_analyzer`	`domain: str`	HTTP/HTTPS response header linting against modern web security standards	Evaluation of `Strict-Transport-Security` (HSTS), `Content-Security-Policy` (CSP), `X-Frame-Options`, `X-Content-Type-Options`, `Referrer-Policy`, `Permissions-Policy`, and Cross-Origin isolation headers with severity ratings.	Pending
`full_recon`	`domain: str`	Multi-wave async execution of all 10 core reconnaissance engines	Aggregated, structured telemetry payload cross-correlating domain ownership, network infrastructure, host services, TLS configurations, and security headers.	Pending

3. Standalone Offensive Tools

Tool	Parameters	Underlying Mechanics / Standards	Telemetry Output	Docs
`cve_lookup`	`software: strversion: str`	NIST National Vulnerability Database (NVD) v2 REST API interface	Known CVE IDs, CVSS v3.1 / v2 base severity scores, vector strings, CWE classifications, vulnerability summaries, and official exploit/advisory references. (No API key required)	Pending
`cloud_exposure_check`	`domain: str`	Keyword permutation & unauthenticated HTTP bucket probing	Publicly accessible AWS S3 buckets (`s3.amazonaws.com`), Azure Blob Storage containers (`blob.core.windows.net`), and Google Cloud Storage buckets (`storage.googleapis.com`).	Pending
`trace_redirects`	`url: str`	Hop-by-hop HTTP 3xx redirect chain tracer (RFC 7231)	Complete redirect trajectory, status codes (301, 302, 307, 308), TLS protocol downgrades (HTTPS → HTTP), RFC 1918 private IP address leaks, redirect loops, and cross-domain hops.	Pending
`robots_txt_inspect`	`domain: str`	HTTP retrieval & standards-compliant `robots.txt` directive parsing	Disallowed endpoints, administrative consoles, hidden staging/API routes, crawl-delay parameters, and declared XML sitemap paths.	Pending
`subdomain_takeover`	`domain: str`	Bounded CNAME-chain resolution + cloud provider fingerprint matching + HTTP probe confirmation	Identifies dangling DNS pointers mapped to de-provisioned cloud infrastructure (GitHub Pages, Heroku, AWS S3, Azure App Services, Ghost, Shopify, Fastly, Pantheon), with each traversed chain returned in `cname_chains`.	Pending
`hibp_check`	`query: str`	Have I Been Pwned (HIBP) API v3 integration (Requires API Key)	Compromised domain and email accounts across public data breaches, paste-site exposures, compromised data classes, and breach timeline statistics.	Pending

4. Specialized AI Prompt Templates

Prompt	Context Tool	Description
`threat_analysis`	`full_recon`	Injects an expert threat analyst cognitive frame into the LLM agent to correlate raw `full_recon` telemetry into an actionable threat intelligence report with vulnerability prioritization, attack vector analysis, and defensive hardening roadmaps.

📸 Demo

Single Tool Execution — CVE Vulnerability Lookup

Query known Common Vulnerabilities and Exposures (CVEs) directly against the NIST National Vulnerability Database (NVD) v2 API for specific software components and patch revisions without requiring API authentication:

Full Reconnaissance Pipeline — Parallelized Security Assessment

Trigger the 3-wave parallel execution engine to synthesize network perimeter state, DNS resource records, SSL/TLS posture, email anti-spoofing enforcement, HTTP headers, and software stack fingerprints into a single structured report:

📋 Prerequisites

Ensure your host environment meets the following runtime requirements before starting the server:

Python Runtime: Python >= 3.12 (Download Python)
Network Scanner: Nmap binary installed and accessible in the system PATH (Download Nmap)
Environment & Package Manager: uv (Recommended for high-performance virtual environments, Install uv) or pip
Version Control: Git (Download Git)
MCP Client: Cursor, VS Code (MCP extension), Claude Desktop, Continue.dev, Zed, or any client implementing the MCP JSON-RPC protocol.
Container Runtime (Optional): Docker Engine / Docker Desktop (Download Docker)

⚙️ Installation

Method 1: Local Virtual Environment Setup (Recommended)

Step 1: Clone the Repository

git clone https://github.com/AynOps/AynOps.git
cd AynOps

Step 2: Provision Virtual Environment and Install Dependencies

Using uv (Fastest):

uv sync

Alternatively, using standard Python tooling:

python -m venv .venv

# On Linux/macOS:
source .venv/bin/activate

# On Windows (PowerShell):
.venv\Scripts\Activate.ps1

pip install -e .

Step 3: Install and Configure Nmap

Nmap must be installed locally and registered in your system PATH for the port_scan tool:

Download and run the setup installer from nmap.org/download.html.
Add Nmap to your System PATH:
- Open Start → Search Environment Variables → Click Edit the system environment variables.
- Under System Variables, select Path → Click Edit → Click New.
- Add the installation path: C:\Program Files (x86)\Nmap (or C:\Program Files\Nmap).
- Confirm all dialogs by clicking OK.
Open a new PowerShell terminal and verify:
```
nmap --version
```

Install via Homebrew:

brew install nmap
nmap --version

Install via your system package manager:

# Debian / Ubuntu / Kali
sudo apt update && sudo apt install -y nmap

# Fedora / RHEL
sudo dnf install -y nmap

# Arch Linux
sudo pacman -S nmap

Step 4: Configure Your MCP Client

Locate and edit your client's MCP configuration file (e.g., Claude Desktop, Cursor, or VS Code):

Operating System	Configuration File Path (Claude Desktop)
Windows	`%APPDATA%\Claude\claude_desktop_config.json`
macOS	`~/Library/Application Support/Claude/claude_desktop_config.json`
Linux	`~/.config/Claude/claude_desktop_config.json`

Insert the AynOps server stanza:

Windows (claude_desktop_config.json):

{
  "mcpServers": {
    "AynOps": {
      "command": "C:\\full\\path\\to\\AynOps\\.venv\\Scripts\\python.exe",
      "args": ["C:\\full\\path\\to\\AynOps\\server.py"],
      "env": {
        "ABUSEIPDB_API_KEY": "your-abuseipdb-api-key-here",
        "HIBP_API_KEY": "your-hibp-api-key-here"
      }
    }
  }
}

macOS / Linux (claude_desktop_config.json):

{
  "mcpServers": {
    "AynOps": {
      "command": "/full/path/to/AynOps/.venv/bin/python3",
      "args": ["/full/path/to/AynOps/server.py"],
      "env": {
        "ABUSEIPDB_API_KEY": "your-abuseipdb-api-key-here",
        "HIBP_API_KEY": "your-hibp-api-key-here"
      }
    }
  }
}

IMPORTANT

Always supply theabsolute filesystem path to your .venv Python binary and server.py file to prevent the client from binding to a mismatched global Python runtime.

NOTE

ABUSEIPDB_API_KEY is optional and only required for ip_reputation (Obtain free at abuseipdb.com). HIBP_API_KEY is optional and only required for hibp_check (Obtain at haveibeenpwned.com/API/Key). All other tools operate with zero API keys.

Step 5: Launch Client and Validate Registration

Terminate all running client processes completely (ensure no background instances remain in Task Manager / Activity Monitor).
Re-open your MCP client.

Verify tool availability by querying:

What cybersecurity tools do you have available?

Method 2: Containerized Deployment via Docker

AynOps ships a production-ready Dockerfile bundling Python 3.12, uv, and nmap, eliminating host dependency requirements.

Step 1: Build the Image

git clone https://github.com/AynOps/AynOps.git
cd AynOps
docker build -t aynops:latest .

Step 2: Verify Stdio Transport

Run a one-shot container execution. The container will initialize and listen for MCP JSON-RPC messages on stdin:

docker run --rm -i aynops:latest
# Press Ctrl+C to exit

Step 3: Configure Client for Docker Execution

Configure your client to spawn the container directly:

{
  "mcpServers": {
    "AynOps": {
      "command": "docker",
      "args": [
        "run",
        "--rm",
        "-i",
        "-e", "ABUSEIPDB_API_KEY=your-abuseipdb-api-key-here",
        "-e", "HIBP_API_KEY=your-hibp-api-key-here",
        "aynops:latest"
      ]
    }
  }
}

TIP

The container must run in interactive mode (-i) without detached flags (-d) to preserve the standard I/O communication pipe required by the MCP protocol.

🚀 Usage

Natural Language Tool Invocations

Once connected, you can interact with individual reconnaissance tools or prompt compound analytical queries:

# Domain & DNS Reconnaissance
"Perform a WHOIS query on target-organization.com"
"Enumerate all DNS resource records and brute-force common subdomains for example.com"
"Query Certificate Transparency logs for *.internal.corp.com"

# Network & Host Fingerprinting
"Run a service version port scan on scanme.nmap.org"
"Execute an ASN lookup for IP 1.1.1.1 and identify the BGP prefix"
"Analyze the IP reputation of 198.51.100.42"

# Web Application & Perimeter Security
"Inspect the SSL/TLS certificate of payment.gateway.io on port 443"
"Audit the HTTP security headers of enterprise-app.com and report misconfigurations"
"Fingerprint the CMS, JavaScript frameworks, and CDNs running on target.com"
"Trace the HTTP redirect chain for http://insecure-portal.com"
"Inspect robots.txt on admin.target.com for unindexed endpoints"

# Vulnerability & Threat Audits
"Look up known CVEs for OpenSSH version 8.2p1"
"Check if cloud storage buckets exist for domain fincorp-assets.com"
"Detect dangling CNAME records susceptible to subdomain takeover on cloudapp.net"
"Query Have I Been Pwned for breaches associated with security@enterprise.com"

Port Scan Profiles

The port_scan tool supports multiple scanning strategies tailored to operational velocity and assessment depth:

Profile (`scan_type`)	Nmap Flag Equivalent	Execution Scope
`basic`	`-F`	Scans top 100 most common TCP ports
`service`	`-sV --version-light`	Top ports + banner grabbing & version identification
`os`	`-O`	TCP/IP stack fingerprinting (Requires elevated privileges)
`full`	`-p-`	Full transmission audit across all 65,535 TCP ports
`vuln`	`--script vuln`	NSE vulnerability detection scripts against open services

Example invocation:

Scan target scanme.nmap.org using the 'service' profile.

End-to-End Threat Modeling with `threat_analysis` Prompt

For optimal threat intelligence synthesis in supported MCP clients:

In your MCP client (e.g. Claude Desktop), click the + icon in the prompt input area.
Select Connectors → Add from AynOps.
Choose the threat_analysis prompt template.

Execute your target reconnaissance prompt:

Do a complete security recon on scanme.nmap.org

The LLM will invoke full_recon, process the normalized signals, and generate a correlated matrix mapping open ports to potential CVEs, missing headers, email spoofability, and infrastructure risk factors.

💡 Examples

Scenario 1: CVE Patch Validation and Vulnerability Correlation

User: Run a service scan on our perimeter host and cross-reference detected software with NVD for CVEs.

Agent: [Invokes port_scan with scan_type="service"]
       Discovered Open Services:
       • Port 80/tcp: Apache httpd 2.4.49
       • Port 22/tcp: OpenSSH 7.4

       [Invokes cve_lookup for software="apache", version="2.4.49"]
       Critical Findings:
       • CVE-2021-41773 (CVSS 9.8) — Remote Code Execution via Path Traversal.
       
       Remediation: Upgrade Apache to >= 2.4.51 immediately.

Scenario 2: Dangling DNS Subdomain Takeover Triaging

User: Check our domain company.com for dangling DNS records pointing to abandoned cloud services.

Agent: [Invokes subdomain_takeover for "company.com"]
       Resolved CNAME: blog.company.com -> company-blog.ghost.io
       HTTP Verification Probe: HTTP 404 - "Fastly error: unknown domain company-blog.ghost.io"
       Status: HIGH RISK — Dangling CNAME pointer detected for Ghost/Fastly infrastructure.
       Remediation: Remove the orphaned CNAME DNS record from your authoritative nameservers.

Scenario 3: Unauthenticated Multi-Cloud Storage Exposure

User: Does our company domain 'megacorp.io' expose any unauthenticated cloud storage containers?

Agent: [Invokes cloud_exposure_check for "megacorp.io"]
       Probing Permutations across AWS S3, Azure Blob, GCS...
       • https://megacorp-data.s3.amazonaws.com — AccessDenied (Secured)
       • https://megacorp-backup.s3.amazonaws.com — HTTP 200 OK (PUBLIC LISTING ENABLED)
         Found XML object keys: /db_dump_2025.sql.gz, /employee_records.csv
       • https://megacorp.blob.core.windows.net/public — HTTP 404 (Not Found)

Scenario 4: HTTP Redirect Chain & TLS Downgrade Analysis

User: Trace the redirect chain for http://legacy.portal.org

Agent: [Invokes trace_redirects for "http://legacy.portal.org"]
       Hop 1: http://legacy.portal.org (301 Moved Permanently)
       Hop 2: https://auth.portal.org/login (302 Found)
       Hop 3: http://internal-sso.portal.org/auth (302 Found) ⚠️ TLS DOWNGRADE DETECTED
       Hop 4: http://192.168.1.50/dashboard ⚠️ PRIVATE IP LEAK (RFC 1918)

📦 Registries & Ecosystem

AynOps is indexed and distributed across the following official registries:

Registry	Identifier / Link
Official MCP Registry	`io.github.AynOps/AynOps`
PyPI Package Index	`pypi.org/project/AynOps/`
Glama MCP Registry	`glama.ai/mcp/servers/AynOps/AynOps`

🤖 LLM Client Behavior & Security Considerations

AynOps acts strictly as an execution server over MCP. Tool invocation decisions, parameter synthesis, and prompt chaining are governed by the connected LLM client:

Model Guardrails & Safety Filters: Certain LLM providers (e.g., Anthropic, OpenAI) enforce heuristic safety filters. Queries like "Attack example.com" or even standard phrases like "Port scan example.com" can occasionally be declined by commercial frontends.
- Workaround 1: Phrase prompts defensively (e.g., "Audit the defensive security posture of our infrastructure at example.com").
- Workaround 2: Connect AynOps to developer-centric or unconstrained MCP clients (e.g., Cursor, Continue.dev with local models via Ollama, or our upcoming AynOps Dedicated Client).
Execution Timeouts: Large operations (such as full port scans across all 65,535 ports) may exceed default client JSON-RPC timeout thresholds (typically 60–120s). Configure tool timeouts appropriately or use the basic and service profiles.
Parameter Extraction Fidelity: Ensure your prompts provide fully qualified domain names (FQDNs) or valid IPv4/IPv6 addresses to prevent client-side schema validation errors.

⚖️ Legal & Ethical Usage

CAUTION

Only perform active network scans and vulnerability evaluations against infrastructure you own or have explicit, documented authorization to test.

Passive OSINT Tools (whois_lookup, dns_enumeration, asn_lookup, cert_transparency, headers_analyzer, cve_lookup, robots_txt_inspect): Operate purely against publicly advertised records and standard web responses.
Active Scanning Tools (port_scan, cloud_exposure_check, subdomain_takeover): Send active network traffic. Unauthorized scanning may violate the Computer Fraud and Abuse Act (CFAA), GDPR, and local cyber regulations.
Authorized Testing Host: For testing and demonstration purposes without production risk, use the officially designated Nmap test host: scanme.nmap.org.

⚠️ Known Limitations

OS Detection Privileges: Nmap OS fingerprinting (scan_type="os") relies on raw TCP/IP socket crafting (-O) and requires elevated root / Administrator privileges on the host system.
Upstream OSINT Rate Limiting: Tools interfacing with third-party endpoints (e.g., crt.sh Certificate Transparency logs, NIST NVD v2 REST API) are subject to upstream service availability and rate limits.
API Key Dependencies: ip_reputation and hibp_check require valid API keys configured in environment variables to return live telemetry.
Container Stdio Lifecycle: When deploying via Docker, the container must maintain an attached interactive stdio stream; running in detached daemon mode (-d) will terminate the MCP pipe.

🗂️ Project Structure

AynOps/
├── .github/                  # GitHub workflows, templates, and assets
│   ├── images/               # Documentation and demo media
│   ├── ISSUE_TEMPLATE/       # Issue templates
│   └── workflows/            # CI/CD workflows
├── docs/                     # Extended documentation
│   └── tools/                # Per-tool documentation
├── tests/                    # Unit and integration tests
├── tools/                    # MCP reconnaissance tools
│   ├── fingerprint/          # Web technology fingerprinting engine
│   ├── prompts/              # MCP prompt templates
│   └── signals/              # Signal extraction framework
├── utils/                    # Shared utilities and helpers
├── .env.example              # Environment variable template
├── .gitignore                # Git ignored files and directories
├── .python-version           # Mentions the Python version
├── CONTRIBUTING.md           # Contribution guidelines
├── Dockerfile                # Container configuration
├── glama.json                # Glama MCP configuration
├── LICENSE                   # MIT License
├── mcp.json                  # MCP metadata and tool manifests
├── pyproject.toml            # Project metadata and dependencies
├── README.md                 # Project documentation
├── SECURITY.md               # Security policy
├── server.json               # MCP server package schema
├── server.py                 # FastMCP server entrypoint
└── uv.lock                   # Dependency lockfile

🗺️ Roadmap & Discussions

We have active GitHub Discussions set up for community ideas, RFCs, tool requests, and roadmap planning.

Check the current planned Roadmap

💬 Join the conversation: Share your feedback, suggest new tools, or vote on roadmap features in AynOps GitHub Discussions!

🤝 Contributing

Contributions, issues, and feature requests are welcome! See CONTRIBUTING.md for the development setup, project structure, and a guide to adding support for a new tool — that's currently the highest-value place to contribute.

Quick version:

Fork the repository
Create a feature branch (git checkout -b feature/amazing-feature)
Commit your changes
Push to the branch and open a Pull Request

If you find a bug or a security vulnerability, please report it directly to the developer.

📜 License

This project is licensed under the MIT License — see the LICENSE file for details. You are free to use, modify, distribute, and integrate this software in commercial and open-source environments.

👤 Author

Gaohar Imran

GitHub: @gaoharimran29-glitch
LinkedIn: Gaohar Imran

Special thanks to @SemTiOne, one of the early contributors to AynOps, for his valuable contributions, reviews, feedback, and continued support throughout the project. His help, especially during the early stages, is genuinely appreciated. ❤️
Special thanks to @Nitjsefnie for their continued and active involvement in AynOps through multiple contributions across the project. Their consistent effort, initiative, and willingness to improve the project are greatly appreciated. ❤️
With gratitude to all our contributors who have helped improve AynOps through code, documentation, testing, ideas, reviews, and feedback. Your contributions are genuinely appreciated. ❤️

Available Tools

8 tools

cve_lookupB

Look up known CVEs for a software name and version using the NVD API.

ParametersJSON Schema

Name	Required	Description	Default
`software`	Yes
`version`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description carries full behavioral burden. It only mentions using the NVD API, but omits information about rate limits, response size, or connectivity requirements. This is insufficient for an agent to anticipate tool 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, efficient sentence with no wasted words. It is front-loaded with the key action and resource.

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 two-parameter tool, the description is minimally viable. However, it lacks parameter details and behavioral context. The presence of an output schema reduces the need for return value explanation, but overall completeness is average.

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 0% description coverage for both parameters. The description mentions 'software name and version' but does not clarify expected formats, case sensitivity, or version syntax. It adds minimal value over the parameter names.

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 'Look up', the resource 'known CVEs', and the context 'for a software name and version using the NVD API'. It is specific and easily distinguishes this tool from sibling tools like whois_lookup or dns_enumeration.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives such as full_recon, or any prerequisites or limitations. The agent is given no context for decision making.

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

dns_enumerationB

Enumerate DNS records for a domain. Returns A, AAAA, MX, NS, TXT, CNAME, SOA records.

ParametersJSON Schema

Name	Required	Description	Default
`domain`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.4/5.0

Behavior3/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 the return record types but does not mention side effects, rate limits, authentication needs, or that it is a read-only operation. The term 'enumerate' implies safety.

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 highly concise: two sentences that immediately convey the verb, resource, and output. Every word is useful.

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 and the presence of an output schema, the description is mostly complete. It states the purpose and record types returned, though it could mention potential errors or domain prerequisites.

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?

There is only one parameter ('domain') with no schema description, and the description does not add meaning beyond stating the domain. Although the parameter is obvious, the description misses an opportunity to clarify valid formats or constraints.

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 states the tool enumerates DNS records and lists specific record types (A, AAAA, MX, NS, TXT, CNAME, SOA). It implies differentiation from sibling tools like whois_lookup or port_scan, but does not explicitly distinguish them.

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

Usage Guidelines2/5

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

The description provides no explicit guidance on when to use this tool vs. alternatives such as whois_lookup or port_scan. Usage is only implied by the tool's purpose.

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

full_reconA

Run all recon tools on a domain in parallel: WHOIS, DNS enumeration, port scan, SSL inspection, and technology stack detection.

Returns combined raw results. The MCP client (Claude) should generate summaries for each section.

ParametersJSON Schema

Name	Required	Description	Default
`domain`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.9/5.0

Behavior3/5

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

Without annotations, the description carries the burden. It states parallel execution and raw results, but lacks details on safety (e.g., read-only), rate limits, or return structure beyond 'combined raw results'. It does hint at client-side processing.

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 very concise: a one-line purpose, a bullet list of included tools, and a clear instruction for the client. No superfluous 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?

Given the tool's complexity (multiple sub-tools) and the presence of an output schema, the description adequately explains what is run and that results are raw. The instruction to generate summaries adds useful guidance.

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 'domain' is required but has no schema description (0% coverage). The description mentions 'a domain' but does not specify format, validations, or examples, leaving the agent to infer.

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 runs all recon tools in parallel on a domain, listing specific tools (WHOIS, DNS, etc.). This distinguishes it from individual sibling tools like dns_enumeration or port_scan.

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

Usage Guidelines4/5

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

The description implies when to use (comprehensive recon) and instructs the client to generate summaries. Although it doesn't explicitly exclude cases, the presence of sibling tools provides context for when not to use (e.g., when only one type of recon is needed).

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

ip_reputationC

Check whether an IP address is reported as malicious using AbuseIPDB. Requires ABUSEIPDB_API_KEY in the environment.

ParametersJSON Schema

Name	Required	Description	Default
`ip_address`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It implies a read-only operation ('Check') but does not explicitly state that the tool is non-destructive, nor does it disclose API rate limits, authentication details, or potential errors. The requirement for an API key is mentioned, but behavior beyond that is opaque.

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 two concise sentences (19 words) with the primary action front-loaded. It is efficient but arguably too sparse, lacking critical details. However, for a simple tool, this structure is acceptable and avoids redundancy.

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

Completeness3/5

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

Given the tool's low complexity (1 parameter) and existence of an output schema, the description covers the basic need. However, it fails to explain what 'malicious' means (e.g., categories, confidence) and does not mention that the tool makes an external API call, which could inform caching or rate-limit handling. An output schema exists but its richness is unknown.

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

Parameters1/5

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

The input schema has 0% description coverage, meaning the parameter 'ip_address' has no defined format or constraints. The description adds no additional meaning (e.g., specifying IPv4/IPv6, CIDR notation, or accepted formats). This leaves the agent guessing about valid input 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?

The description clearly states the verb 'Check' and the resource 'IP address is reported as malicious', and specifies the data source 'AbuseIPDB'. This distinguishes it from siblings like whois_lookup (whois) and dns_enumeration (DNS records), making the tool's unique purpose immediately clear.

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

Usage Guidelines2/5

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

The description mentions an environmental requirement (ABUSEIPDB_API_KEY) but provides no guidance on when to use this tool versus alternatives like whois_lookup or port_scan. There is no explicit when-to-use or when-not-to-use advice, leaving the agent without context for tool selection.

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

port_scanA

Perform Nmap port scan on a target IP or domain.

scan_type options:

"basic" : Top 100 ports, fast (-F)
"service" : Service & version detection (-sV -F)
"os" : OS detection, needs admin (-O -F)
"full" : All 65535 ports, slow (-p-)
"vuln" : Basic vulnerability scripts (--script vuln -F)

ParametersJSON Schema

Name	Required	Description	Default
`target`	Yes
`scan_type`	No		basic

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.5/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 of behavioral disclosure. It explains key behavioral traits: different scan types affect speed, detection capabilities, and require admin privileges for OS detection. It does not mention potential risks (e.g., intrusiveness, legal issues), but the core behaviors are adequately described.

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 extremely concise: one sentence for the main purpose followed by a compact list of scan_type options. Every sentence adds value with no redundancy. It is front-loaded and easy to parse.

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 has only two parameters and an output schema (not shown), the description adequately covers the primary behavior and parameter semantics. It does not mention rate limits or authorization needs, but these are not critical for an agent to use the tool correctly.

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?

The input schema has 0% description coverage, so the description must compensate. It fully explains the two parameters: target (IP or domain) and scan_type with five distinct options and their meanings, adding significant value beyond the bare schema types.

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 performs Nmap port scans on a target IP or domain, which is a specific verb+resource. It naturally distinguishes from sibling tools (e.g., whois_lookup, dns_enumeration) that serve different security purposes.

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

Usage Guidelines4/5

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

The description provides guidance on when to use each scan_type option with detailed effects, helping the agent choose appropriately. However, it does not explicitly state when NOT to use this tool or mention prerequisites like permission requirements.

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

ssl_inspectC

Inspect SSL/TLS certificate details for a domain. Returns cert validity, issuer, SANs, expiry, and cipher info.

ParametersJSON Schema

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

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

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. It only lists return fields but does not disclose potential failures (e.g., domain not found, timeout), network usage, or idempotency. For a read-only tool, this is insufficient transparency.

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 with no redundancy. The first sentence states the purpose, the second lists outputs. Every word adds value.

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?

An output schema exists, so return values are partially covered. However, given the lack of parameter descriptions and the complexity of certificate data, the description could add more context about error handling, output format, or side effects. It is minimally adequate.

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%, so the description must compensate. It mentions 'domain' implicitly but does not explain the 'port' parameter or its default (443). No details on accepted formats or constraints are provided.

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 states it inspects SSL/TLS certificate details for a domain, and lists specific return fields (validity, issuer, SANs, expiry, cipher info). This provides a specific verb and resource. However, it does not explicitly differentiate from the sibling tool 'cert_transparency', which could cause confusion.

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?

There is no guidance on when to use this tool versus alternatives like 'cert_transparency'. No when-not-to-use scenarios or prerequisites are mentioned, leaving the agent without context for selection.

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

tech_stack_detectC

Detect technology stack of a website. Identifies web server, frameworks, CMS, CDN, analytics, and security headers.

ParametersJSON Schema

Name	Required	Description	Default
`domain`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description must fully explain behavior. It only lists what is identified but omits any behavioral traits such as how the detection works (e.g., one page vs full crawl), performance implications, or rate limits.

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 short sentences, front-loaded with the main purpose, with no redundant information. Every sentence adds value.

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 lists identifiable items but does not mention the return format or structure. Given that an output schema exists, the description could be more complete, but it is adequate for a tool with one parameter.

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 coverage is 0%, so the description must compensate. It references 'domain' but adds no format details (e.g., protocol, handling of subdomains) beyond the schema's type. The parameter remains under-documented.

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 states it detects the technology stack of a website and lists specific elements (web server, frameworks, CMS, CDN, analytics, security headers). However, it does not differentiate from sibling tools like 'headers_analyzer' which may overlap in security headers detection.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. It only implicitly suggests use by describing the capability, but does not specify limited contexts or exclusions.

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

whois_lookupC

Perform WHOIS lookup for a domain.

ParametersJSON Schema

Name	Required	Description	Default
`domain`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

C2.6/5.0

Behavior2/5

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

With no annotations, the description bears full burden for behavioral disclosure. It states 'Perform WHOIS lookup' but omits critical details such as what data is returned (e.g., registrar, dates), rate limits, or privacy implications. This minimal description does not adequately inform the agent of the tool's behavior.

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

Conciseness3/5

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

The description is a single sentence, which is concise. However, it is under-specified, missing essential details that would make it informative. It is not verbose, but its economy sacrifices completeness.

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

Completeness2/5

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

Given the presence of an output schema, the description should help interpret results but does not reference it. The description fails to provide a complete picture of the tool's inputs, behavior, or outputs, leaving significant gaps for the agent.

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 coverage is 0%, requiring the description to explain the parameter. It only names 'domain' without specifying format (e.g., with/without TLD), constraints, or examples. The description adds marginal value over the parameter name.

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 states the action ('Perform WHOIS lookup') and the target ('for a domain'). However, it does not distinguish this tool from siblings like asn_lookup, which also operate on domains. The purpose is clear but lacks differentiation.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. The description does not mention any exclusions or context for optimal use, leaving the agent without decision support.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

8 tool updatesv0.1.0May 25, 2026
- First observedcve_lookup
- First observeddns_enumeration
- First observedfull_recon
- First observedip_reputation
- First observedport_scan
- First observedssl_inspect
- First observedtech_stack_detect
- First observedwhois_lookup

Install Server

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

TDQS

A3.6/5.0

Scored 2026-09-09 18:46 across 8 tools

Disambiguation5/5

Each tool targets a distinct recon data source: DNS, ports, TLS, web technology, WHOIS, CVEs, and IP reputation. full_recon is an explicit aggregate runner, so it does not create boundary confusion.

Naming Consistency4/5

All names are lowercase snake_case and mostly follow a noun_verb pattern like port_scan, ssl_inspect, and cve_lookup. A few names such as dns_enumeration, ip_reputation, and full_recon deviate slightly, but the overall pattern remains predictable.

Tool Count5/5

Eight tools form a focused reconnaissance toolkit with no filler; each covers a distinct capability. The full_recon aggregate is useful convenience rather than bloat.

Completeness5/5

The set covers the standard passive and active recon surface: DNS, WHOIS, ports, SSL/TLS, web technology, CVE enrichment, and IP reputation. There are no obvious dead ends for the apparent domain.

Maintenance

ActivityActive

ResponsivenessResponsive

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

royal-mcpOAuth
com.royalplugins
Security-first WordPress MCP server. 129 tools for Claude, ChatGPT, Gemini. Free on wp.org.
Content Management Systems Developer Tools
29
nyc-property-intel
io.github.ccedacero
MCP server giving Claude AI access to 22+ NYC public-record databases for real estate due diligence
Real Estate Government Data
27
mcp
dev.augments
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
Developer Tools Documentation Access
2128
Sleepwalker AOAuth
ai.sleepwalker
AI Visibility and Content Intelligence tools for Claude and MCP-compatible agents.
Agent Orchestration Developer Tools Marketing
19222

Related MCP Servers

CVE MCP Server
Security AI & Machine Learning Monitoring
mukul975
A
license
B
quality
B
maintenance
This MCP server transforms Claude into a comprehensive security analyst by providing access to 27 security tools across 21 APIs for vulnerability intelligence. It enables users to query multiple sources like NVD, EPSS, CISA KEV, and threat intelligence platforms in parallel to get correlated security insights and risk assessments for CVEs.
Updated a month ago (2026-08-05 08:09 UTC)
28
1,452
Apache 2.0
OSINT Tools MCP Server
Open Data Research & Data Security
frishtik
A
license
Not graded
quality
D
maintenance
A comprehensive MCP server that exposes multiple OSINT tools to AI assistants like Claude, enabling sophisticated reconnaissance and information gathering tasks using industry-standard OSINT tools.
Updated a year ago (2025-08-07 13:52 UTC)
237
MIT
spectral
Penetration Testing Networking & Infrastructure
zohaiblazuli
A
license
Not graded
quality
B
maintenance
MCP server for website reconnaissance. Gives Claude the ability to fingerprint tech stacks, audit security headers, map endpoints, analyze SSL certificates, enumerate DNS records, and scan ports.
Updated 2 months ago (2026-06-28 15:08 UTC)
10,557
MIT
Hunter
Penetration Testing Autonomous Agents Shell Access
GeniusHu-tgty
A
license
Not graded
quality
B
maintenance
AI-driven penetration testing MCP server that equips Claude with 13 tools for automated reconnaissance, analysis, vulnerability validation, and exploitation.
Updated a month ago (2026-08-02 16:42 UTC)
3
GPL 3.0

Appeared in Searches

A server for finding cyber security information and resources

📚 Table of Contents

🌐 Overview

Architectural Highlights

⚡ Features

🛠️ Tools & Prompts

1. Multi-Wave Automated Reconnaissance Pipeline (full_recon)

2. Core Reconnaissance Tool Inventory (Included in full_recon)

3. Standalone Offensive Tools

4. Specialized AI Prompt Templates

📸 Demo

Single Tool Execution — CVE Vulnerability Lookup

Full Reconnaissance Pipeline — Parallelized Security Assessment

📋 Prerequisites

⚙️ Installation

Method 1: Local Virtual Environment Setup (Recommended)

Step 1: Clone the Repository

Step 2: Provision Virtual Environment and Install Dependencies

Step 3: Install and Configure Nmap

Step 4: Configure Your MCP Client

Step 5: Launch Client and Validate Registration

Method 2: Containerized Deployment via Docker

Step 1: Build the Image

Step 2: Verify Stdio Transport

Step 3: Configure Client for Docker Execution

🚀 Usage

Natural Language Tool Invocations

Port Scan Profiles

End-to-End Threat Modeling with threat_analysis Prompt

💡 Examples

Scenario 1: CVE Patch Validation and Vulnerability Correlation

Scenario 2: Dangling DNS Subdomain Takeover Triaging

Scenario 3: Unauthenticated Multi-Cloud Storage Exposure

Scenario 4: HTTP Redirect Chain & TLS Downgrade Analysis

📦 Registries & Ecosystem

🤖 LLM Client Behavior & Security Considerations

⚖️ Legal & Ethical Usage

⚠️ Known Limitations

🗂️ Project Structure

🗺️ Roadmap & Discussions

🤝 Contributing

📜 License

👤 Author

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches

1. Multi-Wave Automated Reconnaissance Pipeline (`full_recon`)

2. Core Reconnaissance Tool Inventory (Included in `full_recon`)

End-to-End Threat Modeling with `threat_analysis` Prompt