Reported issues for AynOps

Pod holds 16 of 20 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to AynOps.

Most discussed

Enhancement: Update project tags in `mcp.json` and `server.json`

Summary

The current tags in both mcp.json and server.json no longer accurately represent the capabilities of the AynOps MCP server.

Since the project has grown significantly and now includes 16 reconnaissance and security-focused tools, the metadata should be updated to improve discoverability in MCP registries and better reflect the project's scope.

Problem

The existing tags are:

[
  "cybersecurity",
  "reconnaissance",
  "whois",
  "dns",
  "nmap",
  "ssl",
  "cve",

[Read the thread](https://github.com/AynOps/AynOps/issues/148) · 2026-08-05 · closed · 4 comments

### Docs: Add dedicated documentation for each reconn tool

## Summary

AynOps currently provides 16 MCP tools covering reconnaissance tools. While the README gives a high-level overview, there is no dedicated documentation explaining each tool in detail.

Adding individual documentation pages for every tool would make the project easier to use, improve discoverability, and provide contributors with a single source of truth for tool behavior.

## Proposed Structure

```text
docs/
└── tools/
    ├── README.md
    ├── whois_lookup.md
    ├── dns_enumeratio

[Read the thread](https://github.com/AynOps/AynOps/issues/143) · 2026-08-03 · open · 4 comments

### Infra: Dockerfile exposes unused port 8000

### Summary

The `Dockerfile` includes:

```dockerfile
EXPOSE 8000

but nothing in this codebase actually listens on that port, or any port. server.py starts the MCP server with no transport argument:

mcp = FastMCP("AynOps")
...
if __name__ == "__main__":
    mcp.run()

FastMCP.run() with no arguments defaults to stdio transport, not HTTP/SSE. This is confirmed by the project's own metadata — both server.json and mcp.json explicitly declare:

"transport": [

[Read the thread](https://github.com/AynOps/AynOps/issues/74) · 2026-07-11 · closed · 4 comments

### Enhancement: Add timeout handling to port_scan tool to prevent indefinite blocking

**Labels:** `bug`, `reliability`

## Summary

`tools/portscan_tool.py` invokes `python-nmap` without any timeout:

```python
scanner = nmap.PortScanner()
args = scan_args[scan_type]
scanner.scan(hosts=target, arguments=args)

scanner.scan() is a blocking call that waits for the underlying nmap process to complete. The current implementation does not enforce any execution limit:

No timeout= handling
No --host-timeout passed to nmap
No external deadline around the subprocess

Read the thread · 2026-07-11 · closed · 4 comments

Enhancement: `robots_txt_inspect` to preserve per-User-agent directives and rule groups

Context

The robots_txt_inspect tool currently parses User-agent, Allow, Disallow, Sitemap, Crawl-delay, and Host directives. While Crawl-delay is now parsed correctly, the parser does not preserve per-User-agent directives or rule groups that do not contain Allow or Disallow entries.

For example, the following robots.txt file is perfectly valid and commonly used by websites:

User-agent: SemrushBot*
Crawl-delay: 10

User-agent: Applebot
Crawl-delay: 10

User-age

[Read the thread](https://github.com/AynOps/AynOps/issues/110) · 2026-07-19 · closed · 3 comments

### Refactor: `cert_transparency` Tool to Perform Pure Certificate Transparency Lookups

## Description

The current implementation of the `cert_transparency` tool uses `crt.sh` as the primary Certificate Transparency (CT) source and falls back to HackerTarget's passive DNS API when `crt.sh` fails or times out.

This introduces an inconsistency in the tool's behaviour because HackerTarget does not provide Certificate Transparency data. As a result, the tool may return passive DNS subdomain information while exposing CT-specific fields such as certificate counts, issuers, and validit

[Read the thread](https://github.com/AynOps/AynOps/issues/104) · 2026-07-18 · closed · 3 comments

### ## Docs: Connect Claude with AynOps MCP server and update README with demo video

### Overview
We need to establish a seamless connection between the Claude desktop client (or Claude API) and our **AynOps Model Context Protocol (MCP) server**. Additionally, once the integration is fully functional, we need to update the project's documentation to include a video demonstration showing the MCP server handling requests in real-time.

### Tasks
- [ ] Configure the local `claude_desktop_config.json` (or equivalent environment setup) to register the AynOps MCP server.
- [ ] First a

[Read the thread](https://github.com/AynOps/AynOps/issues/70) · 2026-07-08 · closed · 3 comments

### Enhancement: port_scan scan_type validation should return an error instead of silently falling back

## Current Behavior

In tools/portscan_tool.py:
```python
    scan_args = {
        "basic":   "-F",
        "service": "-sV -F",
        "os":      "-O -F",
        "full":    "-p-",
        "vuln":    "--script vuln -F"
    }

args = scan_args.get(scan_type, "-F")  # ← silently falls back to basic

If someone passes scan_type="aggresive" (typo) or scan_type="intensive" (wrong name), the tool silently runs a basic scan and returns scan_type="aggresive" in the response — making it look li

Read the thread · 2026-06-12 · closed · 3 comments

Most recent

Docs: Add missing `subdomain_takeover` tool to README standalone tools table

Summary

The project currently exposes 17 MCP tools, but the main README.md lists only 16 tools in its tool tables.

The subdomain_takeover tool is currently missing from the Standalone Tools table, resulting in an incomplete tool inventory in the primary project documentation.

The tool is currently defined with the following interface:

{
  "name": "subdomain_takeover",
  "description": "Check discovered subdomains for takeover vulnerabilities — resolves CNAMEs, matc

[Read the thread](https://github.com/AynOps/AynOps/issues/177) · 2026-08-24 · closed · 2 comments

### full_recon can never get security headers from headers_analyzer: it is not in the signal registry

### Describe the bug

`full_recon`'s `missing_security_headers` signal can never be populated by `headers_analyzer`, because `headers_analyzer` is not in the signal registry at all — so `full_recon` never runs it.

Verified on `main`:

- `tools/signals/registry.py` — `TOOL_REGISTRY` has exactly nine entries: `whois`, `dns`, `ssl`, `email_security`, `asn`, `ports`, `techstack`, `ct_logs`, `ip_reputation`. `grep -c "headers"` over that file returns **0**.
- The only two writes to `signals["missing

[Read the thread](https://github.com/AynOps/AynOps/issues/139) · 2026-07-31 · closed · outside contributor · 2 comments

### Enhancement: transform full recon  threat analysis prompt into official mcp prompt

## Summary

Currently, the `full_recon` tool returns an `instructions` field that contains the prompt used to guide LLMs in generating a correlated threat intelligence report.

Since MCP supports **official prompts**, this analysis prompt should be exposed as a dedicated MCP Prompt instead of embedding it inside the tool response.

## Problem

Returning prompt instructions as tool output has several drawbacks:

- LLMs treat the embedded instructions as untrusted tool output or prompt injection.

[Read the thread](https://github.com/AynOps/AynOps/issues/93) · 2026-07-14 · closed · 2 comments

### Docs: Change `mcp.json` example config from `"cybersecurity"` to `"AynOps"` in line 117

**Description**
 
The README's Claude Desktop config examples correctly use `"AynOps"` as the MCP server key. `mcp.json`, however, has:
 
```json
"claude_desktop_config": {
  "mcpServers": {
    "cybersecurity": { ... }
  }
}

Anyone copy-pasting from mcp.json instead of the README will get an inconsistently named server entry.

Suggested fix

Change the key in mcp.json to "AynOps" to match the README.

Files affected: mcp.json

Read the thread · 2026-07-11 · closed · 2 comments

Feature: Add Cloud Infrastructure Exposure Checker Tool

Why This Tool Matters

Modern targets host infrastructure on AWS, GCP, and Azure. A common and impactful recon finding is misconfigured public cloud storage — S3 buckets, Azure Blob containers, GCP buckets — that expose sensitive files to the public internet.

When an expert asks "does example.com have any exposed cloud storage?", the agent today has no answer. This tool answers that question by probing common bucket naming patterns derived from the target domain.

This is a standard passive

Read the thread · 2026-06-12 · closed · 3 comments

Feature: Add GitHub Dorking / Secret Scanner Tool

Why This Tool Matters

When an expert asks "has anything sensitive from example.com been leaked publicly?", there's currently no way for the answer. This tool searches GitHub for accidentally committed secrets, API keys, config files, and credentials linked to a target domain or org name.

This is a standard step in every real-world recon workflow — it's called "GitHub dorking" and security teams do it manually today using the GitHub search UI. This tool replaces that manual process.

Tool

Read the thread · 2026-06-12 · closed · 2 comments

Docs: Improve Documentation & Add MCP Configuration

To improve usability, discoverability, and MCP client compatibility of this repository, we should enhance documentation and add a standard MCP configuration file.

This will make the project easier to use for contributors and compatible with MCP-based tools (e.g., FastMCP clients, Cursor, VS Code MCP integrations).

Tasks

1. Add `mcp.json`

Add a project-level MCP configuration file to improve compatibility with MCP clients.

It should include:

Server name and description
Entry

Read the thread · 2026-06-04 · closed · 2 comments

Add ASN Lookup Tool

Description: Find the Autonomous System Number (ASN) and organization for a domain or IP. Useful for identifying hosting provider and network ownership.

Free API (no key required): https://ipapi.co/{ip}/json/ or https://api.bgpview.io/ip/{ip}

Expected tool signature: def asn_lookup(target: str) -> dict

Expected output: { "success": True, "ip": "142.250.193.78", "asn": "AS15169", "org": "Google LLC", "isp": "Google", "country": "US", "region": "California", "city": "Mountain

Read the thread · 2026-05-24 · closed · 0 comments

The remaining reports are on the project's issue tracker.

Reported issues for AynOps

Most discussed

Enhancement: Update project tags in mcp.json and server.json

Summary

Problem

Enhancement: robots_txt_inspect to preserve per-User-agent directives and rule groups

Context

Most recent

Docs: Add missing subdomain_takeover tool to README standalone tools table

Summary

Feature: Add Cloud Infrastructure Exposure Checker Tool

Why This Tool Matters

Feature: Add GitHub Dorking / Secret Scanner Tool

Why This Tool Matters

Tool

Docs: Improve Documentation & Add MCP Configuration

Tasks

1. Add mcp.json

Add ASN Lookup Tool

Enhancement: Update project tags in `mcp.json` and `server.json`

Enhancement: `robots_txt_inspect` to preserve per-User-agent directives and rule groups

Docs: Add missing `subdomain_takeover` tool to README standalone tools table

1. Add `mcp.json`