Agent MCP - Active Deployments

Rogue Arena ships an MCP plugin for Claude Code, OpenAI Codex, Grok, and other MCP-capable agents. It gives your agent direct, tool-level access to the platform: 190+ MCP tools and 9 skills in total. The other skills cover scenario building, curriculum building, and plugin development, each documented in its own section. This page focuses on the two skills that operate inside a deployed VM scenario.

Those two skills give your agent direct access to your live lab through a shared toolkit, with no SSH or RDP. This page covers the toolkit first, then walks through each skill.

Install MCP Tools

Grab the Rogue Arena MCP plugin for your agent from GitHub to get started.

github.com/rogue-labs-cyber/rogue-arena-mcp

The MCP Toolkit

Once the plugin is loaded, your agent has direct API access to every deployment you own. Here is the shape of what it can do. The list is not exhaustive: the Hub serves the full tool catalog to your agent at runtime, and you can ask your agent to list every tool it has if you want the canonical view.

• VM control: start, stop, and revert VMs or the entire environment, without opening a console
• Snapshot management: create, revert, and delete snapshots on any VM for safe iteration
• GUI automation: click, drag, type, send key presses, chain multi-step UI sequences, and capture full-screen screenshots of any machine
• Script execution: run PowerShell or Bash scripts inline or as background jobs, with status polling and cancellation
• Filesystem access: list directories, read file contents, and grep across files on any VM
• File transfer: push files into a VM or pull artifacts back out, with progress tracking
• Process inspection: list running processes and inspect system state
• Inventory: enumerate every scenario you’ve deployed and every VM inside each one
• Lab course: read the lab’s context and course progress, read unlocked chapters and the hint for a locked one, and submit a key you found to unlock it (deployment_get_context, deployment_curriculum_overview, deployment_curriculum_chapter, deployment_curriculum_unlock_hint, deployment_curriculum_unlock). Locked content and unlock keys stay hidden, and each submission uses one of your unlock attempts.
• Team deployments (Lab Admins): list your teammates’ deployments with deployment_list_team, then operate them with the same tools. See Team VM Sharing.

Note

Your agent runs commands only through these MCP tools, so everything executes inside the lab VM. Nothing runs in your local shell.

The Two Skills

Skills layer on top of the toolkit. They bundle the right tools, the right context, and the right workflow for a specific job so your agent doesn’t have to be re-briefed each session.

/rogue-active-deployment

The core “spin up your agent” skill. Loading it primes your agent with everything it needs to operate inside a Rogue Arena deployment from the first message:

• How Rogue Arena works: scenarios, VMs, snapshots, and how state is scoped
• Which MCP tool to call for each kind of action, so your agent routes correctly (for example, run-script for commands versus gui-click for UI work) without you spelling it out
• Your live deployment context: the skill scans your deployment on load to pull every VM’s name, role, IP, OS, and credentials, so your agent has the full inventory before you say anything
• Operational limits and conventions: when to snapshot and what’s safe to run without confirmation

You describe what you want done, and your agent picks the right tool, runs it on the right VM, and announces the category of action before acting. You don’t re-brief it or copy-paste context.

Loading the /rogue-active-deployment skill: the agent registers the tools, lists every deployment you own, and asks which one to operate in.

Common workflows once the skill is loaded:

• Command execution: run shell and PowerShell scripts across any VM in the scenario, inline or as background jobs
• GUI control: capture screenshots and drive GUIs when a CLI isn’t enough (click, type, key, drag, multi-step sequences)
• File transfer: move files in and out of any machine without setting up SCP or shares
• Safe iteration: snapshot before a risky step and revert if something goes wrong
• Chained multi-step jobs: ask once and your agent orchestrates the whole flow. Example: “Download, install, and configure Notepad++ on win11-target, then start hunting for a DLL hijack with Sysinternals.” The agent pulls the installer, runs the GUI install, drops Procmon and the right Sysinternals tools, captures a trace while Notepad++ launches, and surfaces the missing DLLs as hijack candidates, all without you driving each step.

Mid-operation: the agent takes a snapshot of the target VM, polls until it’s ready, then proposes a step-by-step persistence test against it.

/rogue-maldev

Extends the active deployment skill for red-team tool testing and detection research. Built around a structured test loop:

1. Snapshot the target VM
2. Execute the payload or technique
3. Query the SIEM for detections, correlated by a unique test marker per technique
4. Revert to the pre-execution snapshot
5. Iterate: modify the payload and repeat

The skill can start from wherever you are in the process:

Starting point	Entry
You have a ready tool or payload	Jump straight to execution
You have a list of MITRE technique IDs	Generate a playbook first
You’re researching a TTP category	Pull Atomic Red Team YAML and build from there
No fixed target yet	Browse TTP categories and pick a scope

At the end of a session your agent produces a per-technique report with an expected-vs-observed rule matrix: what the detection should have fired on, what triggered, and what evaded.

Tip

For payload-scoped detections (AMSI, ETW, shellcode, reflective DLL injection) real payloads are required. Your agent won’t substitute benign traffic for those, because the detection fires on the payload itself, so traffic that only imitates its behavior won’t trigger it.

If you want a specific implant or deployment technique (for example, drop your own C2 beacon, use a particular loader, or deliver via DLL sideloading instead of an EXE), tell your agent up front and it’ll use that. Otherwise it picks a reasonable default for the technique under test.