What can you do with this server?

MLNops is a local-first cyber reconnaissance MCP server that equips AI clients with a comprehensive suite of infrastructure assessment and security analysis tools. * whois_lookup — Retrieve domain registration details, expiry dates, registrar, and name servers. * dns_enumeration — Enumerate DNS records (A, AAAA, MX, NS, TXT, CNAME, SOA) and common subdomains. * port_scan — Run Nmap scans with configurable profiles (basic, service, os, full, vuln) to discover open ports, services, and versions. * ssl_inspect — Inspect TLS/SSL certificate chains, issuers, SANs, cipher suites, protocols, and expiry details. * tech_stack_detect — Identify a website's technology stack including web server, CMS, frameworks, CDN, analytics, and security header posture. * asn_lookup — Resolve a domain or IP to its ASN, BGP prefix, country, and hosting organization (no API key required). * email_security_check — Check SPF, DKIM, and DMARC records to assess email anti-spoofing configuration with remediation guidance. * cert_transparency — Search Certificate Transparency logs via crt.sh (with passive DNS fallback) for subdomain discovery. * ip_reputation — Check whether an IP is flagged as malicious via AbuseIPDB (requires API key). * headers_analyzer — Analyze HTTP security headers for presence, values, issues, and severity ratings. * cve_lookup — Search the NVD for known CVEs by software name and version. * cloud_exposure_check — Check for publicly exposed cloud storage buckets (AWS S3, Azure Blob, GCS) derived from a domain name. * trace_redirects — Trace full redirect chains hop-by-hop, flagging TLS downgrades, redirect loops, and private-IP destinations. * robots_txt_inspect — Fetch and parse robots.txt to reveal disallowed paths, hidden directories, and sitemaps. * full_recon — Execute all tools in dependency-aware waves, extract normalized security signals, and produce a structured threat analysis payload with executive summary, severity-ranked findings, risk score, and remediation roadmap.

MLNops

by Milindu-Weerawarna

Overview Schema Related Servers Score Discussions

Python

Local

Python 3.12+ MCP License: MIT MLNops MCP server

What is MLNops?

MLNops is a Python MCP server that equips AI clients with live infrastructure reconnaissance tools. It combines domain registration, DNS, TLS, network, web, email-security, certificate-transparency, and reputation evidence into one structured workflow.

MLNops does not replace professional judgment. It collects evidence and exposes it through MCP; the connected AI client decides which tool to invoke and how to explain the result.

operator request
      │
      ▼
MCP client ──► MLNops tool registry
                   │
         ┌─────────┼─────────┐
         ▼         ▼         ▼
      passive    active    external
      records    probes    intelligence
         └─────────┼─────────┘
                   ▼
          normalized signals
                   ▼
       correlated threat report

MLNops runs locally, but reconnaissance still creates outbound traffic to target systems and third-party services. Use it only on assets you own or are explicitly authorized to assess.

Related MCP server: Bug Bounty Assistant MCP

Capability matrix

Full reconnaissance pipeline

full_recon executes dependency-aware waves and returns raw evidence, tool coverage, normalized signals, and a prompt-ready summary.

Signal	What MLNops inspects
Ownership	WHOIS registration, expiry, registrar, and name servers
DNS	A, AAAA, MX, NS, TXT, CNAME, SOA, and common subdomains
TLS	Certificate chain, issuer, SANs, cipher, protocol, and expiry
Email	SPF, DKIM, DMARC, score, and remediation guidance
Network	ASN, BGP prefix, country, registry, and network organization
Exposure	Nmap ports, services, and detected versions
Web stack	Server, CMS, frameworks, CDN, analytics, and header posture
Discovery	Certificate Transparency subdomains with passive-DNS fallback
Reputation	AbuseIPDB confidence and malicious-IP indicators

Focused tools

Tool	Purpose
`headers_analyzer`	Detailed HTTP security-header analysis
`cve_lookup`	NVD CVE search by software and version
`cloud_exposure_check`	Checks likely public S3, Azure Blob, and GCS names
`trace_redirects`	Maps redirect chains and flags downgrade, loop, and private-IP risks
`robots_txt_inspect`	Parses directives, paths, crawl delays, hosts, and sitemaps

MCP prompt

threat_analysis turns full_recon signals into a structured report with:

an executive security posture;
confirmed and likely findings separated by severity;
a transparent 100-point risk score;
an immediate, weekly, and monthly remediation roadmap;
explicit insufficient-data handling when a tool is blocked or fails.

Quick start

Requirements

Python 3.12+
uv
Nmap for port scanning
An MCP-capable client such as Claude Desktop, Cursor, or VS Code

Install

git clone https://github.com/Milindu-Weerawarna/MLNops.git
cd MLNops
uv sync --locked

Confirm Nmap is available:

nmap --version

Connect an MCP client

Use absolute paths in your client configuration.

Windows

{
  "mcpServers": {
    "MLNops": {
      "command": "C:\\full\\path\\to\\MLNops\\.venv\\Scripts\\python.exe",
      "args": ["C:\\full\\path\\to\\MLNops\\server.py"],
      "env": {
        "ABUSEIPDB_API_KEY": "optional-key"
      }
    }
  }
}

macOS / Linux

{
  "mcpServers": {
    "MLNops": {
      "command": "/full/path/to/MLNops/.venv/bin/python",
      "args": ["/full/path/to/MLNops/server.py"],
      "env": {
        "ABUSEIPDB_API_KEY": "optional-key"
      }
    }
  }
}

ABUSEIPDB_API_KEY is optional and used only by ip_reputation. All other tools work without it.

Restart the MCP client after changing its configuration, then ask:

What MLNops security tools are available?

Operator examples

Run DNS enumeration on example.com.
Inspect the TLS posture of example.com.
Scan scanme.nmap.org with service detection.
Look up CVEs for Apache 2.4.49.
Trace redirects for https://example.com.
Run a complete authorized recon on my-domain.example.

For a correlated report, attach the threat_analysis MCP prompt and invoke full_recon.

Port-scan profiles

Profile	Nmap behavior	Typical use
`basic`	Fast scan of common ports	Rapid exposure check
`service`	Common ports plus version detection	Default full-recon profile
`os`	OS detection; elevated privileges may be required	Host characterization
`full`	All 65,535 TCP ports	Deep authorized assessment
`vuln`	Nmap vulnerability scripts on common ports	Focused validation

Architecture

server.py                     MCP entry point and tool registration
tools/                        Reconnaissance implementations
tools/signals/                Evidence normalization and warning extraction
tools/prompts/                Correlation prompt templates
utils/                        Shared validation and parsing helpers
tests/                        Unit and regression tests
mcp.json / server.json        MCP distribution metadata

The full-recon scheduler runs tools in waves:

Lightweight identity and configuration checks.
Active service inspection and passive discovery.
Reputation analysis after an IP address has been resolved.

A failed tool is recorded as failed or skipped without terminating the remaining scan.

Development

uv sync --locked
uv run pytest tests -q

Run the MCP development inspector:

uv run fastmcp dev inspector server.py

See contributing.md for tool contracts, signal extraction, testing, and registration guidance.

Responsible use

Scan only systems you own or have explicit written permission to test.
Use scanme.nmap.org when learning Nmap against a public target.
Treat heuristic findings as leads that require validation.
Do not interpret a missing response as proof of a vulnerability.
Follow the laws and organizational policies that apply to your environment.

License and lineage

MLNops is an independent fork and rebuild based on AynOps. It is distributed under the MIT License. The original copyright notice is retained in LICENSE, and subsequent MLNops modifications are identified there as well.

Maintained by Milindu Weerawarna.

Available Tools

12 tools

asn_lookupA

Find the Autonomous System Number (ASN) and network ownership for a domain or IP using Team Cymru WHOIS. Useful for identifying hosting provider and network ownership. No API key required.

ParametersJSON Schema

Name	Required	Description	Default
`target`	Yes	Domain or IP address

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

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 the full burden. It mentions that no API key is needed, which is useful, but does not disclose potential behaviors like rate limits, data freshness, or whether the tool is read-only. The description is adequate but lacks depth.

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 only two sentences, front-loaded with the core purpose, and every sentence adds value. No wasted words or 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?

Given the tool's simplicity (one parameter) and the presence of an output schema, the description covers the essentials: purpose, usage, and a key constraint. It could mention IPv6 support or limits, but it is largely complete for a straightforward lookup tool.

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 100% schema coverage, the baseline is 3. The description adds context about the data source and service ('using Team Cymru WHOIS') but does not significantly enhance the parameter meaning beyond what the schema already provides ('Domain or IP address').

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 the tool's action ('Find the Autonomous System Number (ASN) and network ownership') and target ('domain or IP'), making the purpose very clear. It also specifies the data source (Team Cymru WHOIS), which helps distinguish from sibling tools like whois_lookup.

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 includes a usage hint ('Useful for identifying hosting provider and network ownership') and a key constraint ('No API key required'). It does not explicitly exclude alternatives, but the context is sufficient for most agents to decide when to use this tool.

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

cve_lookupB

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

ParametersJSON Schema

Name	Required	Description	Default
`version`	Yes
`software`	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.

email_security_checkA

Check SPF, DKIM, and DMARC DNS records for a domain to assess basic email anti-spoofing configuration.

DKIM detection is best-effort here. It checks a fixed list of common selectors used by major email providers, since DKIM selectors cannot be discovered via DNS without already knowing them.

ParametersJSON Schema

Name	Required	Description	Default
`domain`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.9/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 honestly discloses that DKIM detection is best-effort due to a fixed list of common selectors, explaining the limitation. This adds value beyond the schema. However, it could also note any potential issues with SPF and DMARC checks.

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 purpose clearly, and the second provides a key behavioral detail. It is front-loaded and contains no extraneous 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 presence of an output schema, the description does not need to detail return values. It covers purpose and a key limitation. Adding a brief note about what SPF, DKIM, and DMARC checks entail would improve completeness, but it is adequate for a simple tool.

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 should compensate. It mentions 'domain' in context but does not explain the parameter's format, requirements, or examples. The only added meaning is that the domain is the target for the security check.

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 checks SPF, DKIM, and DMARC DNS records for a domain, with the specific purpose of assessing basic email anti-spoofing configuration. This is a specific verb-resource combination that distinguishes it from sibling tools like dns_enumeration or whois_lookup.

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 email security checks but does not explicitly state when to use this tool versus alternatives, nor does it mention when not to use it. It provides no exclusions or comparisons to siblings like dns_enumeration.

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

full_reconB

Execute all registered reconnaissance tools in dependency-aware waves, extract security signals, and build the final threat analysis payload.

ParametersJSON Schema

Name	Required	Description	Default
`domain`	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?

No annotations are provided, so the description carries the full burden. It mentions 'wave-based' execution and 'extract signals' but lacks details on whether changes are made (destructive), rate limits, or error behavior. The transparency is insufficient for a complex orchestration tool.

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 that front-loads the main action. It is appropriately concise with no wasted words, though it could benefit from breaking down the three stages for clarity.

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 complexity (orchestrating multiple sub-tools), the description is minimal. It does not cover prerequisites, output shape (though an output schema exists), or error conditions. For a complex tool, this is adequate but not complete.

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 only parameter 'domain' is a simple string with no schema description (0% coverage). The tool description does not elaborate on the parameter's meaning, format, or constraints, failing to add value beyond the bare schema definition.

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's purpose: executing all registered reconnaissance tools in waves, extracting security signals, and building a threat analysis payload. It uses specific verbs and resources, distinguishing itself from sibling tools which are individual reconnaissance operations.

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 this is a meta-tool for running all reconnaissance together, but it does not provide explicit guidance on when to use it versus individual tools, nor does it mention any exclusions or prerequisites. The context is implied but not explicitly stated.

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

headers_analyzerA

Analyze HTTP security headers for a domain.

Returns a dict with header analysis including present/absent status, actual values, issues found, and severity ratings.

ParametersJSON Schema

Name	Required	Description	Default
`domain`	Yes	The domain to analyze (e.g. "example.com")

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are provided, so the description should disclose behavioral traits. It mentions the return format but does not state that the tool makes HTTP requests to the domain, any side effects, rate limits, or authorization requirements. The description could be more transparent.

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 two sentences, front-loaded with the main action, and contains no extraneous 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?

Given the tool's simplicity (one parameter) and the existence of an output schema, the description covers the main aspects. It mentions the return format (dict with present/absent, values, issues, severity). However, it could mention that the tool performs an HTTP request to the domain, which is relevant for understanding its operation.

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?

The input schema already provides full coverage (100%) for the single parameter 'domain' with a clear description. The tool description does not add additional meaning beyond what the schema provides, so a baseline score of 3 is appropriate.

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

Purpose5/5

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

The description clearly states the verb 'Analyze' and the resource 'HTTP security headers for a domain', and distinguishes this tool from its siblings (e.g., whois_lookup, dns_enumeration) by focusing specifically on HTTP security headers.

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 analyzing security headers but does not provide explicit guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions.

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.

robots_txt_inspectB

Fetch and parse the robots.txt file for a given domain to reveal hidden directories and sitemaps.

ParametersJSON Schema

Name	Required	Description	Default
`domain`	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?

No annotations are provided, so the description must fully disclose behavioral traits. It mentions 'fetch and parse' implying a network request, but does not discuss rate limits, error handling, data freshness, or whether the tool is read-only. Minimal disclosure.

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 immediately conveys the action and purpose. It is front-loaded and efficient, though slightly more structure (e.g., separating fetch from parse) could improve clarity without bloat.

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 has an output schema, the description does not need to detail return values. However, the lack of usage guidelines and parameter details leaves gaps for a simple tool. Adequate but not comprehensive.

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, the description must compensate. It specifies 'for a given domain' but adds no additional meaning beyond the schema (type string). Does not clarify expected format (e.g., with or without protocol) or validation rules.

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

Purpose5/5

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

The description clearly states the action ('Fetch and parse'), the resource ('robots.txt file for a given domain'), and the purpose ('reveal hidden directories and sitemaps'). It distinguishes from sibling tools like whois_lookup or dns_enumeration by being specific to robots.txt inspection.

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 does not provide any guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or context. The agent is left to infer usage from the tool name and purpose alone.

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.

trace_redirectsA

Trace the full redirect chain for a URL, hop by hop.

Follows redirects manually (allow_redirects=False + loop) instead of relying on requests' built-in auto-follow, so each hop's own status code and destination are visible. Flags TLS downgrades, private-IP destinations, redirect loops, excessively long chains, and cross-domain hops along the way.

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.3/5.0

Behavior5/5

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

With no annotations, description fully discloses behavior: manual redirect loop, visibility of each hop's status and destination, and specific checks performed (TLS downgrades, private IPs, loops, chain length, cross-domain hops).

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?

Concise but informative; front-loaded with purpose. A few sentences that earn their place, though slightly verbose in the middle.

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 complexity of redirect tracing and presence of output schema, description adequately explains what happens at each hop and what anomalies are flagged.

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?

Single 'url' parameter with 0% schema coverage; description does not add format or constraints beyond stating it's a URL. Agent only knows it expects a URL string.

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 traces redirect chain hop by hop, with specific verb and resource. Distinguishes from siblings like whois_lookup or dns_enumeration by focusing on redirect behavior.

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?

Explanation of manual redirect following and flags (TLS downgrades, private IPs, loops) gives clear context for when to use. However, no explicit mention of 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.

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

4 tool updatesv0.1.1Jul 26, 2026
- Removedcert_transparency
- Removedcloud_exposure_check
- Addeddns_enumeration
- Addedwhois_lookup
4 tool updatesv0.1.0Jul 26, 2026
- Addedcloud_exposure_check
- Removeddns_enumeration
- Addedfull_recon
- Removedssl_inspect
12 tool updatesJul 26, 2026
- First observedasn_lookup
- First observedcert_transparency
- First observedcve_lookup
- First observeddns_enumeration
- First observedemail_security_check
- First observedheaders_analyzer
- First observedip_reputation
- First observedport_scan
- First observedrobots_txt_inspect
- First observedssl_inspect
- First observedtech_stack_detect
- First observedtrace_redirects

Install Server

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

TDQS

A3.5/5.0

Disambiguation4/5

Most tools have distinct purposes (e.g., port_scan vs. headers_analyzer), but there is minor overlap: dns_enumeration and email_security_check both query DNS, and tech_stack_detect and headers_analyzer both inspect HTTP responses. The 'full_recon' tool could blur boundaries. Overall, descriptions help differentiate.

Naming Consistency4/5

All tool names follow snake_case with a verb_noun pattern (e.g., whois_lookup, dns_enumeration), but there is a slight inconsistency: 'headers_analyzer' uses a noun form instead of verb 'analyze'. Otherwise, naming is clear and predictable.

Tool Count5/5

With 12 tools spanning WHOIS, DNS, port scanning, HTTP analysis, CVE lookup, IP reputation, email security, redirect tracing, and robots.txt parsing, the count is well-scoped for a reconnaissance server. Each tool serves a clear purpose without redundancy.

Completeness4/5

The tool set covers most common reconnaissance tasks: domain info, network scanning, web tech detection, vulnerability lookup, and email security. Missing are SSL certificate analysis and subdomain brute-forcing, but these are beyond the core scope. Overall, the surface is comprehensive.

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

meok-mcp-hardening-mcp
io.github.CSOAI-ORG
MEOK MCP Hardening MCP — automated security red-team for any MCP server. Maps OWASP LLM Top 10
Penetration Testing Security
1
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
mcp A
com.domainposture
Remote MCP server: 19 domain-hygiene and email-auth tools (DNS, SPF, DMARC, DKIM, TLS).
Security Networking & Infrastructure
222
runtime
com.formatho
Self-hosted MCP server: 26 deterministic dev, security, and EVM tools.
Developer Tools Blockchain Security
1

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
-
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
cyber-mcp-server
Penetration Testing Security
warnii
F
license
Not graded
quality
C
maintenance
A production-style MCP server providing AI models with cybersecurity tools including port scanning, WHOIS, DNS, threat intelligence, CVE lookup, and more.
Updated a month ago (2026-07-28 21:37 UTC)
-
recon-mcp
Penetration Testing Open Data Search
nekiyRichie
A
license
Not graded
quality
C
maintenance
An MCP server providing 15 OSINT tools over free, public sources for AI agents, enabling domain reconnaissance, subdomain discovery, DNS lookups, host profiling, CVE search, and more without API keys.
Updated a month ago (2026-08-01 17:36 UTC)
MIT

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/Milindu-Weerawarna/MLNops'

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