Integrates with Nuclei vulnerability scanner from ProjectDiscovery's GitHub repository and references other GitHub-based MCP implementations
Provides Markdown as an output format option for security scan reports
Uses Pydantic for data validation and settings management in scan configurations and results
Implements security scanning functionality using Python 3.10+ with asyncio for concurrent vulnerability assessments
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Security Scanner MCP Server scan example.com for critical vulnerabilities"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Comprehensive security scanning using Nuclei vulnerability scanner with cluster-wide capabilities.
Part of the Agentic System - a 24/7 autonomous AI framework with persistent memory.
Comprehensive security scanning integration using Nuclei vulnerability scanner with cluster-wide capabilities.
Single Target Scanning: Scan individual URLs or IPs with customizable severity and templates
Network Scanning: Batch scan multiple targets or CIDR ranges
Cluster Integration: Scan all nodes in the agentic cluster
Template Management: List, filter, and update Nuclei templates
Scan History: Retrieve and analyze previous scan results
Scheduled Scans: Configure periodic security assessments
Multiple Output Formats: JSON, JSONL, or Markdown reports
Related MCP server: Guardian Ops
cd ${AGENTIC_SYSTEM_PATH:-/opt/agentic}/mcp-servers/security-scanner-mcp
source ${AGENTIC_SYSTEM_PATH:-/opt/agentic}/.venv/bin/activate
pip install -e .Add to ~/.claude.json:
{
"mcpServers": {
"security-scanner": {
"command": "${AGENTIC_SYSTEM_PATH:-/opt/agentic}/.venv/bin/python",
"args": ["-m", "security_scanner.server"],
"env": {
"NUCLEI_BIN": "${HOME}/go/bin/nuclei",
"SCAN_RESULTS_DIR": "${AGENTIC_SYSTEM_PATH:-/opt/agentic}/security-scans"
}
}
}
}Scan a single target with Nuclei vulnerability scanner.
Parameters:
target (required): URL or IP address
severity: Array of severity levels ["info", "low", "medium", "high", "critical"]
templates: Specific template paths or tags
rate_limit: Requests per second (default: 150)
timeout: Scan timeout in seconds (default: 300)
output_format: "json", "jsonl", or "markdown"
Example:
{
"target": "https://example.com",
"severity": ["high", "critical"],
"rate_limit": 100
}Scan multiple targets from a list or CIDR range.
Parameters:
targets: Array of target URLs/IPs
target_file: Path to file with targets (one per line)
severity: Severity filter
parallel: Number of concurrent scans (default: 5)
rate_limit: Requests per second per target
Scan all nodes in the agentic cluster for vulnerabilities.
Parameters:
scan_type: "network", "web", "api", or "full"
severity: Severity levels to check
List available Nuclei templates by tag, severity, or author.
Parameters:
tag: Filter by tag (e.g., "cve", "exposure")
severity: Filter by severity level
author: Filter by template author
Update Nuclei templates to the latest version.
Retrieve results from a previous scan by scan_id.
Parameters:
scan_id (required): Scan identifier
limit: Max results to return (default: 100)
severity: Filter by severity levels
List all previous security scans.
Parameters:
limit: Maximum number of scans to return
target: Filter by target
Schedule recurring security scans (requires agent runtime).
Parameters:
targets (required): List of targets to scan
interval_hours: Scan interval (default: 24)
severity_threshold: Minimum severity to report (default: "medium")
notify_on_new: Alert on new vulnerabilities (default: true)
The security scanner automatically detects and scans all nodes in the agentic cluster. Cluster nodes are loaded from configuration:
builder - Linux build node
orchestrator - Coordination node
coordinator - Multi-node coordinator
files - File server
Combine with the autonomous security scanning agent for:
Automated vulnerability assessment
Continuous security monitoring
Intelligent threat prioritization
Automatic remediation recommendations
Scan results are stored in enhanced-memory for:
Historical vulnerability tracking
Pattern recognition across scans
Causal relationship analysis
Learning from remediation outcomes
Results are stored in ${AGENTIC_SYSTEM_PATH:-/opt/agentic}/security-scans/:
scan_YYYYMMDD_HHMMSS_ID.json - Scan findings
scan_YYYYMMDD_HHMMSS_ID_metadata.json - Scan metadata
# Via Claude Code
scan_target({
"target": "192.0.2.196",
"severity": ["high", "critical"],
"templates": ["network", "exposure"]
})scan_cluster_nodes({
"scan_type": "full",
"severity": ["medium", "high", "critical"]
})list_scans({"limit": 10})
get_scan_results({"scan_id": "scan_20251118_110000_1234"})Scans generate network traffic - coordinate with network admin
Rate limiting prevents overwhelming targets
Results may contain sensitive information - restrict access
Authorized scanning only - verify permission before scanning external targets
Nuclei v3.5.1+
Python 3.10+
asyncio
aiofiles
pydantic
Nuclei - Main vulnerability scanner
nuclei-mcp - Reference MCP implementation
ExternalAttacker-MCP - Security testing MCP
This server integrates with other MCP servers for comprehensive AGI capabilities:
Server | Purpose |
4-tier persistent memory with semantic search | |
Persistent task queues and goal decomposition | |
Full AGI orchestration with 21 tools | |
Distributed task routing across nodes | |
Inter-node AI communication | |
Production-only policy enforcement |
See agentic-system-oss for the complete framework.
Use TPU-accelerated embeddings to detect anomalous security findings.
Compares findings against a baseline (previous scans or expected patterns) to identify unusual or novel vulnerabilities that may need urgent attention.
Args: scan_id: Current scan to analyze baseline_scan_id: Previous scan to compare against (optional) threshold: Similarity threshold - lower values = more anomalies detected
Returns: JSON with anomalous findings and analysis
| Name | Required | Description | Default |
|---|---|---|---|
| scan_id | Yes | ||
| threshold | No | ||
| baseline_scan_id | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the use of embeddings and baseline comparison, and explains the threshold effect. However, it omits details on side effects, authentication requirements, or performance impacts. Since annotations are absent, the description carries full burden but is only partially adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is mostly concise, front-loading the core purpose. The docstring-style listing of args is efficient, though the mention of 'TPU-accelerated embeddings' adds minor fluff. Overall, every sentence contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description's mention of 'JSON with anomalous findings and analysis' is sufficient. The 3 parameters are explained, and the behavior is clear for a detection tool. Some details on the baseline selection or edge cases are missing but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description adds meaningful explanations for each parameter: 'Current scan' for scan_id, 'previous scan to compare against' for baseline_scan_id, and 'lower values = more anomalies' for threshold. This compensates well for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: detecting anomalous findings using TPU-accelerated embeddings and comparing against a baseline. It specifies the resource (security findings) and action (detect anomalies), distinguishing it from sibling tools like list_scans or prioritize_findings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (comparing scans for anomalies) but does not explicitly state when to use this tool versus alternatives, nor does it provide when-not-to-use scenarios or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve results from a previous scan.
Args: scan_id: Scan ID to retrieve limit: Maximum number of results to return (default: 100)
Returns: JSON string with scan results
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| scan_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, description only mentions return type (JSON string) and parameters. Does not disclose side effects, error behavior, or auth needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Brief and well-structured with title sentence, Args, and Returns. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description sufficiently covers input parameters. Could mention error handling or default ordering, but overall complete for basic retrieval.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description fully explains both parameters: scan_id as 'Scan ID to retrieve' and limit as 'Maximum number of results to return (default: 100)', adding significant meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Retrieve results from a previous scan' with specific verb and resource, distinguishing it from siblings like list_scans and scan_target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage after a scan, but no explicit when-to-use, exclusions, or alternatives. Lacks guidance on prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all previous security scans.
Args: limit: Maximum number of scans to return (default: 50)
Returns: JSON string with scan list
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It implies a read-only operation but does not explicitly state safety, authentication needs, or potential side effects. The mention of returning a JSON string is minimal, and details like pagination or ordering are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: three sentences covering purpose, parameter, and return value. It is front-loaded with the primary action and contains no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, output schema exists), the description is largely complete. However, it could benefit from mentioning default sorting or whether scans are returned in reverse chronological order, which would aid the agent in using the results. The missing usage guidelines slightly reduce completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the only parameter 'limit' with its purpose and default value, adding meaning beyond the bare schema. Since schema description coverage is 0%, the description fully compensates by providing semantic context for the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all previous security scans, using a specific verb and resource. It distinguishes from sibling tools like get_scan_results (which retrieves results of a specific scan) and scan_target (which initiates a scan), making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as get_scan_results for detailed results or scan_target for initiating a scan. The description lacks context about prerequisites or exclusions, 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.
List available Nuclei templates by tag or severity.
Args: tag: Filter by tag (e.g., cve, exposure, misconfiguration) severity: Filter by severity (info, low, medium, high, critical)
Returns: JSON string with template list
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | ||
| severity | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 discloses the return type (JSON string with template list). As a read-only operation, it is transparent enough, though it could mention no side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for Args and Returns. It is concise but includes all necessary information. Minor improvement could be to tighten wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two optional parameters and an output schema (implied), the description covers both parameters and return type adequately. It is complete for its intended use without needing to explain returns further.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by listing each parameter with example values (tag: cve, exposure, misconfiguration; severity: info, low, medium, high, critical). This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists available Nuclei templates by tag or severity. The verb 'list' and resource 'Nuclei templates' are specific. This distinguishes it from sibling tools like 'list_scans' which list scans, not templates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains parameters and their possible values, implying usage for filtering templates. However, it does not explicitly state when to use this tool over siblings or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use TPU-accelerated importance scoring to prioritize security findings.
Scores each finding based on semantic similarity to critical security terms and patterns, helping focus remediation efforts.
Args: scan_id: Scan ID to prioritize
Returns: JSON with prioritized findings
| Name | Required | Description | Default |
|---|---|---|---|
| scan_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses use of TPU and semantic similarity, indicating a compute-intensive, ML-driven operation. However, it does not mention side effects, permissions, or whether it is read-only, which is relevant given no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with 'Args' and 'Returns' sections. Every sentence adds value, and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the scoring approach but lacks details on critical terms, sorting, or output structure. However, the presence of an output schema (indicated by context signals) partially mitigates the need for complete output description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description only restates the parameter name 'scan_id: Scan ID to prioritize' without adding format, source, or constraints, failing to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool prioritizes security findings using TPU-accelerated importance scoring, differentiating it from sibling tools like detection or listing. The verb 'prioritize' and resource 'findings' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It implies usage after a scan via scan_id but does not state prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan all nodes in the agentic cluster for vulnerabilities.
Args: scan_type: Type of scan - "quick", "comprehensive", "full", "web", or "api" severity: Comma-separated severity levels to check
Returns: JSON string with cluster scan results
| Name | Required | Description | Default |
|---|---|---|---|
| severity | No | medium,high,critical | |
| scan_type | No | comprehensive |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description only mentions scanning and returning JSON results. Does not disclose if the tool is read-only, requires permissions, is asynchronous, or has side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Succinct docstring format with main purpose in first sentence, followed by clear Args and Returns sections. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters and an output schema mentioned in context, the description covers the basic functionality. However, lacks details on timing or blocking behavior, which is important for a scanning tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning beyond schema by listing possible scan_type values (quick, comprehensive, etc.) and explaining severity as comma-separated levels. However, does not list valid severity levels and schema description coverage is 0%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Scan' and resource 'all nodes in the agentic cluster', with the purpose 'for vulnerabilities'. This distinguishes it from siblings like 'list_scans' and 'get_scan_results'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives like 'scan_target' or 'list_scans'. Does not mention prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan a target URL or IP with Nuclei vulnerability scanner.
Args: target: Target URL or IP address to scan severity: Comma-separated severity levels (info, low, medium, high, critical) rate_limit: Requests per second (default: 150) timeout: Scan timeout in seconds (default: 300)
Returns: JSON string with scan results
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | ||
| timeout | No | ||
| severity | No | medium,high,critical | |
| rate_limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description lacks disclosure of potential destructive impact, required permissions, or behavioral nuances beyond basic parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences + structured Args/Returns, no wasted words, front-loaded with core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers basic function, parameters, and return format, but lacks deeper context about when to use versus siblings, potential side effects, or required setup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage, but description explains each parameter meaningfully (e.g., severity levels, rate_limit as requests per second, timeout duration).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Scan a target URL or IP with Nuclei vulnerability scanner' – specific verb and resource, distinct from siblings like list_scans or get_scan_results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies scanning usage but gives no explicit when-to-use, when-not-to-use, or alternatives among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update Nuclei templates to latest version.
Returns: JSON string with update result
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the update action and return type, but does not explain whether updates are destructive, require connectivity, or overwrite existing templates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences front-load the action. Every word adds value; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal but adequate for a parameterless tool with an output schema. However, it lacks context on what 'templates' are, how the update works, and what the result string contains beyond 'update result'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (0 params, 100% coverage). Baseline is 4, and the description adds no param info, but also does not mislead. It correctly implies no input needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (update), the resource (Nuclei templates), and the target state (latest version). It is distinct from sibling tools, which have different purposes like scanning or listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Sibling tools are named but not compared. No prerequisites or context for using the 'update' action are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0detect_anomalous_findingsget_scan_resultslist_scanslist_templatesprioritize_findingsscan_cluster_nodesscan_targetupdate_templatesEach tool has a clearly distinct purpose: scanning, results retrieval, template management, and analysis. No overlap exists.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., scan_target, list_scans, detect_anomalous_findings). No mixing of conventions.
8 tools cover the domain well without being excessive. Each tool contributes meaningfully to scanning, results, templates, and analysis.
Core workflows are covered: scanning (targets, clusters), results retrieval, template management, anomaly detection, and prioritization. Minor gap: no tool to delete scans or clear data, but overall complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI pentesting: run scans, triage vulnerabilities, review PRs, manage schedules and assets.
Scan a website for vulnerabilities: OWASP Top 10, CVEs, SSL, headers - with plain-English fixes
Threat modeling, code/cloud/pipeline scanning, shadow-AI discovery, compliance checks and fixes.
Zero-config MCP security scanner for AI-generated apps. 25K+ vulnerability patterns.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/marc-shade/security-scanner-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
