A
licenseNot graded
qualityC
maintenanceA secure tool-execution plane for agentic AI that enforces JWT authentication, rate limiting, prompt-injection inspection, and audit logging, while ingesting downstream OpenAPI endpoints as MCP tools.
MIT
NullSec-RedTeam-AI
by Panda1847
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., "@NullSec-RedTeam-AIcreate a passive reconnaissance campaign targeting the internal staging network for audit"
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.
NullSec-RedTeam-AI
Authorization-first, MCP-governed security execution for explicitly approved environments.
NullSec-RedTeam-AI is a single-host control plane for governed security-tool workflows. It records a campaign’s approved scope, actor context, policy decision, durable job lifecycle, audit trail, and evidence reference before a worker is allowed to execute a job. Its default posture is sandbox-required and fail-closed: a required sandbox never degrades to host execution.
Use only with explicit written authorization. This project is early-stage security software, not an autonomous red-team system, a substitute for an engagement agreement, or a multi-tenant service. Run it in isolated test environments or on assets you are expressly authorized to assess.
Why NullSec?
Principle | What it means in practice |
Authorization before execution | Every job is evaluated against a campaign, caller identity, target scope, capability tier, time window, policy decision, idempotency key, and trace identifier. |
Containment that fails closed | Sandbox-required work needs an immutable image, an available container runtime, least-privilege configuration, and a bounded workspace. Missing controls fail the job rather than executing locally. |
Auditable operations | SQLite-backed jobs retain lifecycle events, leases, cancellation state, actor and campaign linkage, policy context, and evidence metadata. |
Bounded AI collaboration | AURA separates planning, policy review, execution permission, and evidence review. A planner cannot directly call a runner. |
Truthful AI security testing | The AI Security Lab labels simulation output as |
Related MCP server: runeward
Architecture at a Glance
A user or MCP client reaches the transport layer only after authentication and caller-context construction. The campaign policy engine decides whether a typed request is in scope. The durable job store coordinates leases and audit events; a lease-aware worker can then request a least-privilege sandbox run. AURA remains above the execution boundary, with a separate evidence-review stage.
The source-controlled Mermaid diagram is available at docs/assets/control-plane-architecture.mmd. Read the architecture rationale in ADR-001.
Quick Start for Safe Local Development
The development workflow uses mocks and simulated fixtures; it does not install, download, or execute security tools.
git clone https://github.com/Panda1847/NullSec-RedTeam-AI.git
cd NullSec-RedTeam-AI
python3 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install -e '.[dev]'
pytest
ruff check .For local API-development work, use project-local state, a non-production token, and loopback binding only.
mkdir -p .nullsec/logs .nullsec/jobs
export NULLSEC_LOG_DIR="$PWD/.nullsec/logs"
export NULLSEC_JOB_DIR="$PWD/.nullsec/jobs"
export API_TOKEN="local-development-token"
export NULLSEC_LOCAL_ACTOR_ID="local-operator"
export NULLSEC_LOCAL_ACTOR_ROLES="operator"
hexstrike-server --host 127.0.0.1 --port 8888The service rejects non-loopback binding unless NULLSEC_ALLOW_NON_LOOPBACK=true is explicitly set. Treat that setting as a deployment change requiring an authenticated reverse proxy and an approved network policy.
Safe Campaign Flow
A campaign records authorization and scope. The following loopback-only example creates a campaign record; it does not run a tool.
curl --request POST http://127.0.0.1:8888/api/campaigns \
--header "Authorization: Bearer $API_TOKEN" \
--header 'Content-Type: application/json' \
--data '{
"campaign_id": "local-demo-001",
"allowed_targets": ["127.0.0.0/8"],
"allowed_capabilities": ["passive"],
"starts_at": "2026-08-18T09:00:00+00:00",
"ends_at": "2026-08-18T17:00:00+00:00"
}'Job submission requires that campaign, a supported capability tier, and an idempotency key. With the default sandbox_required mode, a job remains safe to queue but fails closed at execution unless an operator has supplied a reviewed immutable image and rootless runner configuration.
curl --request POST http://127.0.0.1:8888/api/tools/execute \
--header "Authorization: Bearer $API_TOKEN" \
--header 'Content-Type: application/json' \
--header 'X-Trace-Id: local-demo-trace-001' \
--data '{
"tool": "nmap",
"target": "127.0.0.1",
"options": "-sV",
"campaign_id": "local-demo-001",
"capability": "passive",
"idempotency_key": "local-demo-request-001"
}'Do not place bearer tokens in shell history, source control, screenshots, or CI logs.
AI Security Lab
The AI Security Lab distinguishes a simulation from an actual provider evaluation. Its default output has mode: simulation and status: not_evaluated; it does not claim a model is vulnerable, resistant, or scored. Provider evaluation stays unavailable until an organization supplies a consented adapter, a versioned dataset, protected credentials, evidence storage, and a scoring method.
ai-lab --list
ai-lab --model consented-test-model --technique PROMPT_INJECTION --mode simulationThe project deliberately does not generate bypass payloads. Any provider-backed assessment should use a reviewed, versioned dataset in an isolated environment.
Quality Gates
Every contribution should satisfy test, code-quality, security, packaging, and review expectations before release.
The public workflow covers tests with focused coverage, Ruff linting, focused type checking, static security analysis, dependency auditing, and PEP 517 package builds. The quality-gate diagram source is docs/assets/quality-gates.mmd.
Project Status and Roadmap
Area | Current state | Next meaningful milestone |
Identity | Local single-host actor adapter | Deployment-specific OAuth/OIDC or equivalent identity adapter |
Policy | Campaign scope, capability, window, and target checks | Persistent policy repository and approval workflow |
Execution | Local lease-aware worker with fail-closed sandbox profile | Reviewed rootless runtime profile and signed immutable runner image |
AURA | Typed, bounded workflow state machine | Persisted sessions, durable evidence links, and policy-governed provider adapters |
Evidence | Job audit events and evidence references | Managed evidence storage with retention and integrity controls |
See ROADMAP.md for the maintained implementation sequence and IMPLEMENTATION_SUMMARY.md for the 7.1 modernization record.
Documentation
Document | Use it for |
Authorization, containment, and operator responsibilities | |
Private vulnerability reporting and response process | |
Development setup, review standards, and safe adapter requirements | |
Community participation standards | |
Single-host deployment and rollback workflow | |
Rootless runner, image, and containment review | |
Evidence provenance, retention, and incident preservation | |
Versioned changes and release notes |
Contributing
Contributions must preserve the authorization-first posture. New integrations need a typed request model, risk tier, capability scope, safe execution profile, deterministic tests, and an evidence parser or documented limitation. Do not add arbitrary shell execution, unbounded option strings, live-target tests, credentials, target inventories, or generated scan artifacts.
Open a design issue or propose an architecture decision record before broad changes. Review CONTRIBUTING.md first, and use SECURITY.md instead of public issues for vulnerability reports.
License
This project is licensed under the MIT License. The license does not grant authorization to assess a system. Operators remain responsible for applicable law, contracts, organizational policy, written authorization, and engagement constraints.
Available Tools
6 toolsdiagnose_issueB
Diagnose a specific error and suggest fixes.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| error_message | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
B3.1/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a safe, read-like behavior (suggesting fixes, not mutating state), but with no annotations provided, it bears the full burden of disclosure. It does not mention whether the tool has side effects, requires specific permissions, or has rate limits. The lack of explicit behavioral detail is a gap, but it does not contradict any annotations since none exist.
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 with 6 words, which is concise but arguably underspecified. It lacks structure to highlight key details like the tool's scope or output. While brevity is valued, the sentence could be expanded to include context such as what kind of errors it handles or what the output contains, without becoming verbose.
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 tool has one parameter and an output schema, reducing the need for extensive description of returns. However, given its complexity (diagnosis and fix suggestions), the description does not cover what the response includes (e.g., severity, steps, references) or how error messages should be formatted. The presence of an output schema helps, but the description could be more complete for an agent to use it effectively.
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 single required parameter 'error_message' has no schema description coverage (0%), so the description must compensate. The description states it diagnoses a specific error, which implies the parameter is an error message string. This adds some meaning beyond the schema, but it is vague—it does not clarify the expected format, length, or source of the error message. For a single parameter, this is acceptable but not exemplary.
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's purpose: diagnosing a specific error and suggesting fixes. The action verb 'diagnose' combined with the resource 'specific error' makes the function clear. However, it does not differentiate itself from siblings like 'scan_target' or 'run_security_tool', which could also analyze errors, missing a chance to clarify its unique role.
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 guidance on when to use this tool versus alternatives. Given siblings like 'scan_target' and 'run_security_tool', an agent would benefit from understanding that this tool is for troubleshooting a known error message, not for security scanning or status checks. The absence of such context reduces its utility for proper tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_job_statusC
Check status of a previously queued job.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 carries full burden for behavioral disclosure. It doesn't mention whether the tool is destructive (it's not, but this is unstated), whether it blocks/polls, what the output format is (though output schema exists), or any rate limits or authentication needs. The simple description is incomplete for an agent to understand operational 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, front-loaded sentence with no filler. It efficiently communicates the core purpose. A score of 5 would require even tighter wording or additional value, but 4 is appropriate for brevity.
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 this is a low-complexity tool (1 param, has output schema), the description is incomplete. The output schema exists but the description doesn't clarify what statuses to expect or how to interpret them (e.g., pending, completed, failed). An agent needs more context to effectively parse the result. The description lacks completeness for a useful tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description must compensate. However, with only one parameter (job_id), the description implies the job_id is the identifier for the queued job, which adds minimal semantic value beyond the schema. The baseline is 3 given low coverage, but the description doesn't explain the format or constraints of job_id (e.g., required length, prefix).
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 verb ('Check status') and resource ('a previously queued job'). It distinguishes itself from siblings by focusing on job status, not system status, scanning, or diagnostics. A score of 5 would require explicit comparison to siblings or mention of what makes this unique, but 4 is strong.
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 guidance on when to use this tool vs alternatives. It doesn't specify prerequisites (e.g., that a job must have been queued first via another tool) or mention when not to use it. With siblings like 'run_security_tool' and 'diagnose_issue', an agent would benefit from knowing this tool is for polling asynchronous operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_system_statusB
Check health of all NullSec components.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 full responsibility for behavioral disclosure. The description implies a read-only health check but does not state that explicitly, nor does it mention whether the tool has side effects, requires authentication, or has rate limits. The lack of clarity on behavior is a significant gap for a tool with 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence—short and to the point. It conveys the core purpose without fluff. No wasted words, though it could be slightly more structured (e.g., adding a period at the end or front-loading the intent better).
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 zero parameters but an output schema exists, the description is adequate but not rich. It doesn't hint at the output shape or how to interpret the health status, leaving an agent to infer behavior from the output schema alone. For a simple health check with no inputs, the description is minimally viable but could be more helpful by explaining what 'health' entails.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the description provides complete clarity about the lack of inputs. There are no schema descriptions needed beyond what is already 100% covered by the parameter count. The description suffices for the input semantics.
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 purpose is to 'Check health of all NullSec components', specifying a concrete verb ('check') and resource ('health of all NullSec components'). It differentiates from siblings like 'diagnose_issue' which implies a narrower scope, and 'run_security_tool' which is more action-oriented. A slight deduction for not being more specific about what 'health' means (e.g., uptime, latency).
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 offers no guidance on when to use this tool versus alternatives like 'diagnose_issue' or 'scan_target'. For example, it doesn't explain whether this is a quick status check vs. a deep diagnostic. There are no prerequisites, context for appropriate use cases, or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_available_toolsA
List all available security tools with descriptions.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
A3.6/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 convey behavioral traits. It only states 'list all available security tools with descriptions,' omitting crucial details such as whether the operation is read-only, if pagination applies, or any authorization requirements. The agent cannot infer safety or side-effect profile from this minimal text.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of five words that immediately communicates the tool's core action. No wasted words; every part is essential.
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 zero parameters and an output schema (not shown), the description is mostly complete for a simple listing tool. It could benefit from mentioning the output format (e.g., an array of tool names and descriptions) to reduce uncertainty, but the current text is sufficient for basic understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% schema coverage, so the baseline is 4. The description adds value by clarifying the purpose beyond the empty schema, but no parameter-level detail is needed.
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 'List' and the resource 'security tools with descriptions,' making the tool's purpose immediately obvious. It distinguishes itself from sibling tools like run_security_tool and get_job_status by focusing on listing rather than execution or status checks.
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. For example, it doesn't suggest using this tool before run_security_tool to discover available options, nor does it indicate when not to use it. The description lacks contextual cues for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_security_toolC
Execute a security tool via the HexStrike orchestration server.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Target IP, hostname, or URL | |
| options | No | Additional command-line options | |
| tool_name | Yes | Tool to run (nmap, sqlmap, gobuster, hydra, nuclei, ffuf, nikto, dirsearch) |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 carries full responsibility for disclosure. It fails to mention whether execution is synchronous or asynchronous, what authentication or permissions are required, or any side effects (e.g., network scanning may be destructive). The single sentence lacks essential behavioral context for a tool that orchestrates external security tools.
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, front-loaded sentence that efficiently states the tool's purpose. No unnecessary words are present, but the conciseness comes at the cost of missing critical detail. It earns a high score for structure but not for 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?
Despite having an output schema and sibling tools like 'get_job_status' (implying potential asynchronous behavior), the description omits any context about how results are returned, whether execution is blocking, or how errors are reported. The tool's role in an orchestration workflow is undefined, leaving a significant gap in understanding for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter is already documented with a description in the input schema. The tool description does not add additional meaning beyond what the schema provides. Given the baseline for high schema coverage is 3, and the description adds no new parameter insights, this score is appropriate.
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 verb 'Execute' and the resource 'a security tool via the HexStrike orchestration server', making the primary action and context unambiguous. However, it does not distinguish this tool from sibling tools like 'scan_target' or 'list_available_tools', which could have overlapping functionality.
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 'scan_target' or 'list_available_tools'. The description does not mention prerequisites, exclusions, or the appropriate context for invocation, leaving the agent to infer usage solely from the tool name and parameter list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scan_targetC
Run a comprehensive security scan on a target.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | IP or hostname to scan | |
| scan_type | No | quick, full, or stealth | quick |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full responsibility. It does not disclose whether the scan is read-only, destructive, or requires special permissions. It omits potential side effects (e.g., network load, detection) and does not explain what happens after the scan (e.g., are results stored?). The presence of a sibling 'get_job_status' hints at asynchronous behavior, but the description is silent on this.
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, front-loaded sentence that immediately conveys the action and resource. It is efficient with no wasted words, though it could be slightly more informative without sacrificing conciseness.
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 simplicity and the presence of an output schema, the description is reasonably complete for basic understanding. However, it fails to address the asynchronous nature (inferred from sibling 'get_job_status'), the difference between scan types, or how results are retrieved. The missing context leaves the agent uncertain how to handle the tool's lifecycle.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters already documented in the input schema (target as 'IP or hostname', scan_type as 'quick, full, or stealth'). The description adds only the generic word 'comprehensive', which does not enhance understanding of parameter meaning or constraints. It provides no additional semantics beyond the schema.
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 runs a 'comprehensive security scan' on a target, which is a specific action with a defined resource. However, it does not differentiate this tool from the sibling 'run_security_tool', which may have overlapping functionality. A higher score would require explicit distinction.
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 like 'run_security_tool' or 'diagnose_issue'. There is no mention of prerequisites, typical scenarios, or exclusions. The description only says what it does, not when or why to choose it.
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.
6 tool updates
v7.1.0- First observed
diagnose_issue - First observed
get_job_status - First observed
get_system_status - First observed
list_available_tools - First observed
run_security_tool - First observed
scan_target
TDQS
B3.4/5.0
Disambiguation4/5
Most tools are clearly distinct, but run_security_tool and scan_target have overlapping purposes—both involve executing security operations—though descriptions clarify that the former is for arbitrary tools and the latter for a predefined comprehensive scan.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern in snake_case (e.g., run_security_tool, get_job_status), with no mixing of conventions or inconsistent verb styles.
Tool Count5/5
With 6 tools, the set is well-scoped for a red team AI server, covering core operations without being overly large or trivial.
Completeness3/5
The tool set covers basic actions like running tools and scanning, but lacks critical lifecycle operations such as canceling jobs, retrieving full results, or managing targets, leaving notable gaps for a complete red team workflow.
Maintenance
ActivityMaintained
ResponsivenessNo issues
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Control plane for autonomous software labor. Agents claim objectives over MCP with audit trail.
Zero-secret MCP gateway for AI agents: risk-scored, audited calls with human-in-the-loop approval.
Compliance frameworks (SOC 2, ISO 27001, CMMC, NIST, more) delivered to AI agents as MCP tools.
1- gatewayOAuthai.sealgate
MCP gateway with runtime security policy, tool-call-level control, and audit of agent actions.
Related MCP Servers
- AlicenseNot gradedqualityAmaintenanceGoverned execution cells for AI agents via MCP; provides shell, code, file, and browser tools inside isolated, policy-enforced Citadels with deny-by-default security, human-in-the-loop approvals, and tamper-evident audit trails.1Apache 2.0
- AlicenseNot gradedqualityAmaintenanceMCP server for AI-driven VAPT orchestration, enabling agents to plan and execute authorized security scans through a control plane that enforces scope, sanitization, budget, rate limits, human approval, and audit logging.MIT
- AlicenseBqualityBmaintenanceA security-first MCP gateway that enables AI assistants to safely inspect and interact with GitHub repositories through a controlled, auditable tool layer with policy enforcement and human approval for mutations.27MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/Panda1847/NullSec-RedTeam-AI'
If you have feedback or need assistance with the MCP directory API, please join our Discord server