How do I use PowerShell Empire MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@PowerShell Empire MCP Server list all active agents" 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.

PowerShell Empire MCP Server

by schwarztim

Overview Schema Related Servers Score Discussions

JavaScript

Remote

PowerShell Empire MCP Server

A Model Context Protocol (MCP) server for interacting with PowerShell Empire, the post-exploitation framework maintained by BC-Security.

Note: This tool is intended for authorized security testing, red team operations, and educational purposes only. Ensure you have proper authorization before using this tool against any systems.

Features

This MCP server provides comprehensive access to Empire's REST API (v5+), enabling AI assistants to:

Listener Management: Create, list, enable/disable, and delete listeners
Stager Generation: Generate payloads using various templates (PowerShell, Python, C#, etc.)
Agent Control: List agents, execute commands, upload/download files
Module Execution: Search and run post-exploitation modules
Credential Management: View and store harvested credentials
Plugin System: Execute Empire plugins
C2 Profiles: Access malleable C2 profiles for HTTP/S listeners

Related MCP server: Cobalt Strike MCP Server

Installation

# Clone the repository
git clone https://github.com/schwarztim/sec-powershell-empire-mcp.git
cd sec-powershell-empire-mcp

# Install dependencies
npm install

# Build
npm run build

Configuration

Set the following environment variables:

Variable	Description	Default
`EMPIRE_URL`	Empire REST API URL	`http://localhost:1337`
`EMPIRE_USERNAME`	Empire username	`empireadmin`
`EMPIRE_PASSWORD`	Empire password	`password123`

Claude Desktop Configuration

Add to your Claude Desktop configuration (~/.claude/user-mcps.json or Claude Desktop settings):

{
  "mcpServers": {
    "powershell-empire": {
      "command": "node",
      "args": ["/path/to/sec-powershell-empire-mcp/dist/index.js"],
      "env": {
        "EMPIRE_URL": "https://your-empire-server:1337",
        "EMPIRE_USERNAME": "your-username",
        "EMPIRE_PASSWORD": "your-password"
      }
    }
  }
}

Available Tools

empire_listeners

Manage Empire listeners - list, create, enable, disable, or delete listeners.

Actions: list, get, templates, create, delete, enable, disable

empire_stagers

Generate and manage stagers/payloads for Empire agents.

Actions: list, templates, create, get, delete

empire_agents

List and manage active Empire agents.

Actions: list, get, kill, rename, checkins, files, tasks

empire_modules

Search and view Empire post-exploitation modules.

Actions: list, search, get, execute

empire_shell

Execute shell commands on an Empire agent.

empire_upload

Upload a file to an Empire agent.

empire_download

Download a file from an Empire agent.

empire_credentials

Manage harvested credentials in Empire.

Actions: list, create

empire_hosts

List hosts that agents are running on.

empire_downloads

List files downloaded from agents.

Actions: list, get

empire_plugins

Manage Empire plugins.

Actions: list, execute

empire_bypasses

List available AMSI/AV bypasses.

empire_profiles

List malleable C2 profiles for HTTP listeners.

empire_task_result

Get the result of a specific task.

Usage Examples

List Active Agents

Use empire_agents with action "list" to see all active agents.

Execute a Shell Command

Use empire_shell with agent_id "ABC123" and command "whoami" to run a command on an agent.

Generate a PowerShell Stager

Use empire_stagers with action "create", template "multi_launcher", name "test_stager",
and options including the Listener name.

Search for Modules

Use empire_modules with action "search" and search term "mimikatz" to find credential dumping modules.

Requirements

Node.js 18+
PowerShell Empire v5+ (BC-Security fork)
Empire REST API enabled

Security Considerations

Store credentials securely; avoid hardcoding in configurations
Use HTTPS for Empire API connections in production
Limit API access to authorized networks only
Follow your organization's security policies for red team tools

License

MIT License - see LICENSE file.

Disclaimer

This software is provided for authorized security testing and educational purposes only. Users are responsible for ensuring compliance with applicable laws and regulations. The authors assume no liability for misuse of this software.

References

Available Tools

14 tools

empire_agentsC

List and manage active Empire agents

ParametersJSON Schema

Name	Required	Description
`action`	Yes	Action to perform
`agent_id`	No	Agent ID or name (required for get, kill, rename, checkins, files, tasks)
`new_name`	No	New name for the agent (required for rename)

TDQS

C2.7/5.0

Behavior2/5

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

No annotations exist, so the description must disclose behavioral traits. It does not mention that actions like kill are destructive or that rename modifies state. The description is too brief to convey side effects or required permissions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is only six words, which is overly concise. It lacks essential detail about the tool's functionality and sacrifices completeness 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 the tool's complexity (3 parameters, 7 action enums) and no output schema, the description is insufficient. It does not explain the purpose of each action or the dependencies between parameters (e.g., agent_id required for most actions).

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 baseline is 3. The description adds no additional meaning beyond the parameter descriptions already present in 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 states the tool lists and manages active Empire agents, clearly identifying the resource and distinguishing it from sibling tools like empire_listeners or empire_hosts. However, 'manage' is vague and doesn't specify the range of actions (list, get, kill, etc.) shown in the schema.

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 lacks context about which actions are appropriate for different tasks and doesn't mention exclusions or prerequisites.

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

empire_bypassesA

List available AMSI/AV bypasses

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior2/5

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

With no annotations, the description carries full burden for behavioral disclosure. It only states it 'list[s]' bypasses, but doesn't clarify if listing is read-only, requires specific permissions, or other behavioral traits. This is insufficient for a tool operating in a security context.

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, concise sentence that conveys the tool's purpose without any extraneous information. It is well-structured and front-loaded.

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 no parameters and no output schema, the description is minimally adequate. However, it lacks details on what bypasses are included, any formatting, or constraints. More context would improve usability, especially alongside sibling tools.

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, so schema coverage is 100%. Per guidelines, baseline for 0 parameters is 4. The description adds no additional parameter information, but that's acceptable as there are none to describe.

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 'List available AMSI/AV bypasses' clearly states the tool's purpose with a specific verb ('List') and resource ('AMSI/AV bypasses'), and it distinguishes itself from sibling tools like empire_agents or empire_listeners.

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 the many sibling tools (empire_agents, empire_shell, etc.), the lack of usage context or exclusions is a significant gap.

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

empire_credentialsC

Manage harvested credentials in Empire

ParametersJSON Schema

Name	Required	Description
`action`	Yes	Action to perform
`credtype`	No	Credential type (hash, plaintext, etc.) - for create
`domain`	No	Domain - for create
`username`	No	Username - for create
`password`	No	Password or hash - for create
`host`	No	Host where credential was found - for create
`notes`	No	Notes - for create

TDQS

C2.4/5.0

Behavior2/5

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

With no annotations, the description carries full burden. 'Manage' does not disclose that the tool can create credentials (mutate state) or require any permissions. No mention of side effects, readonly aspects, 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.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Extremely concise (5 words) but under-specified. It provides minimal information, failing to convey the tool's capabilities or actions. This is more terse than efficiently informative.

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?

For a tool with 7 parameters and no output schema, the description is very incomplete. It does not explain how actions (list/create) relate to parameters, nor does it describe the return format or behavior. Significant gaps remain.

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 parameter descriptions. The description adds no extra meaning beyond the schema, which already documents each parameter well. Baseline 3 is appropriate.

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

Purpose3/5

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

The description states 'Manage harvested credentials in Empire', which gives a general area but fails to specify the supported actions (list, create) or differentiate it from sibling tools like empire_agents or empire_hosts. It is a functional verb+resource but lacks specificity for precise agent selection.

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 on when to use this tool versus alternatives. The description does not mention that it is for listing or creating credentials, nor does it exclude any context. Siblings cover related areas but no comparison is provided.

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

empire_downloadB

Download a file from an Empire agent

ParametersJSON Schema

Name	Required	Description	Default
`agent_id`	Yes	Agent ID or name
`remote_path`	Yes	Path on the target system to download

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral traits such as whether the tool is read-only, requires specific permissions, or modifies state. Without annotations, the description carries the full burden, but it only states the basic action. No side effects or constraints are mentioned.

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, direct sentence with no unnecessary words. It efficiently conveys the core purpose. No extraneous information.

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 (2 required params, no output schema, no annotations), the description is minimally adequate. However, it omits useful context such as where the file is saved locally or whether the path is absolute/relative. Completeness is acceptable for a low-complexity tool but could be improved.

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 descriptions for both parameters (agent_id, remote_path). The description does not add more meaning beyond the schema, so it meets the baseline of 3. It could provide examples or format hints but does not.

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?

Description clearly states the action ('Download a file') and the resource ('from an Empire agent'). It distinguishes from siblings like empire_upload (upload file) and empire_shell (execute commands). However, it could be more specific about the source (e.g., 'remote file from the agent's filesystem').

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 explicit guidance on when to use this tool versus alternatives. The description does not mention scenarios, prerequisites, or when not to use it. Sibling tools like empire_shell, empire_upload, and empire_task_result cover related but distinct actions, but no comparison is provided.

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

empire_downloadsC

List files downloaded from agents

ParametersJSON Schema

Name	Required	Description	Default
`action`	Yes	Action to perform
`download_id`	No	Download ID (for get)

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 bears full responsibility. It only says 'List files downloaded from agents', which is overly simplistic. It does not disclose that the tool also retrieves a specific download, whether it is read-only, requires authentication, or has any 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, no unnecessary words. However, it could be restructured to also mention the 'get' action, making it more complete without adding significant length.

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 complexity (2 parameters, no output schema, multiple sibling tools), the description is insufficient. It does not explain return values, how to distinguish from 'empire_download', or how the 'list' vs 'get' actions behave.

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 100% (both parameters described). The description adds no additional meaning beyond the schema's parameter descriptions, which are already clear. The baseline score of 3 is appropriate as the schema adequately documents the parameters.

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 states a clear verb and resource: 'List files downloaded from agents'. However, it omits the 'get' action supported by the input schema (action enum includes 'get'), making it only partially accurate. Also, the sibling 'empire_download' suggests a related but distinct tool, but no differentiation is provided.

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 given on when to use this tool versus alternatives like 'empire_download' or other sibling tools. The description does not mention prerequisites, context, or exclusions.

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

empire_hostsA

List hosts that agents are running on

ParametersJSON Schema

Name	Required	Description	Default
No 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 burden. It states the operation is a list (read) but offers no further behavioral details such as output format, sorting, or any side effects. For a simple list, this is minimally adequate.

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?

A single sentence that is perfectly concise and front-loaded with the key action and resource. No unnecessary 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 tool has no parameters and no output schema, the description covers the essential purpose. However, it could elaborate on what 'hosts' refers to (e.g., hostnames, IPs) or the format of the output. Still, it is complete enough for a simple list tool.

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 is empty (0 parameters), and schema description coverage is 100%. With no parameters, the description does not need to add parameter information, earning a baseline of 4.

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 'List hosts that agents are running on', with a specific verb ('List') and resource ('hosts'). This distinguishes it from sibling tools like empire_agents (list agents) and empire_listeners (list listeners).

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?

No explicit guidance on when to use this tool versus alternatives. The description implies it is for listing hosts with active agents, but does not mention when not to use it or provide comparisons to sibling tools.

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

empire_listenersC

Manage Empire listeners - list, create, enable, disable, or delete listeners

ParametersJSON Schema

Name	Required	Description
`action`	Yes	Action to perform
`listener_id`	No	Listener ID (required for get, delete, enable, disable)
`template`	No	Listener template name (required for create)
`name`	No	Listener name (required for create)
`options`	No	Listener options (for create)

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description carries full burden for behavioral disclosure. It lists mutating actions (create, delete, enable, disable) but reveals no side effects, permissions required, or reversibility. This is insufficient for safe invocation.

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, concise and to the point. It efficiently enumerates the actions, though it could be improved by front-loading the most common use case or structuring with bullet points for clarity.

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?

The description lacks contextual completeness: it does not explain how actions relate to required parameters, what the output looks like, or provide usage examples. With no output schema, the description should fill this gap but fails to do so.

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 provides 100% coverage with descriptions for all parameters, including enums. The tool description adds no additional parameter semantics beyond listing actions, which are already in the schema, so baseline 3 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 identifies the tool as managing Empire listeners and lists specific actions (list, create, enable, disable, delete), making it distinct from sibling tools that target other Empire components. However, the verb 'Manage' is generic and could be more precise.

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 empire_agents or empire_shell. The description does not mention prerequisites, limitations, or context for choosing this tool.

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

empire_modulesC

Search and view Empire post-exploitation modules

ParametersJSON Schema

Name	Required	Description
`action`	Yes	Action to perform
`search`	No	Search term for modules (for list/search)
`module_id`	No	Module ID (for get, execute)
`agent_id`	No	Agent ID to run module on (required for execute)
`options`	No	Module options (for execute)

TDQS

C2.3/5.0

Behavior2/5

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

No annotations provided. The description claims the tool is for searching and viewing, but the schema allows executing modules on agents, which is a significant behavioral trait not disclosed. This misrepresentation reduces transparency.

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 very concise (one sentence), but it omits important functionality (execute). It is front-loaded but inaccurate, so conciseness does not compensate 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?

Given the tool has 5 parameters including a nested object and no output schema, the description is too sparse. It does not explain the difference between actions, required fields for execute, or anything about the options object.

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 100%, so the schema already explains each parameter adequately. The description adds minimal value beyond the schema, not clarifying nuances like the relationship between action and other parameters.

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

Purpose2/5

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

The description states 'Search and view', but the action enum includes 'execute' (and 'get'), which goes beyond search and view. This omission makes the purpose unclear and potentially misleading. It does not fully describe what the tool does.

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 on when to use this tool versus siblings like empire_shell or empire_agents. There is no mention of prerequisites, when to use each action, or exclusions.

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

empire_pluginsD

Manage Empire plugins

ParametersJSON Schema

Name	Required	Description
`action`	Yes	Action to perform
`plugin_id`	No	Plugin ID (for execute)
`options`	No	Plugin execution options (for execute)

TDQS

D1.9/5.0

Behavior1/5

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

No annotations provided, so the description carries full burden. It only says 'Manage', which does not disclose whether operations are read-only or destructive, nor does it mention any side effects, authentication needs, 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.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three words is too concise for a tool with multiple actions and nested parameters. The description lacks structure and does not earn its place; it is under-specified.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and a complex tool with both listing and execution actions, the description is completely inadequate. It does not explain return values, side effects, or how to interpret results.

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 descriptions for all three parameters. The description adds no extra meaning beyond the schema, but the baseline for high coverage is 3.

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

Purpose2/5

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

The description 'Manage Empire plugins' is vague; the verb 'manage' does not specify what operations are supported. The schema reveals 'list' and 'execute' actions, but the description fails to communicate this specific purpose, making it unclear how this tool differs from siblings.

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 on when to use this tool versus alternatives like empire_shell, empire_listeners, etc. No context on prerequisites for executing plugins or typical use cases.

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

empire_profilesB

List malleable C2 profiles for HTTP listeners

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are present, so the description bears full responsibility. It only states the action is a list, but does not disclose any behavioral details such as pagination, permissions, or what happens if no profiles exist.

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 concise sentence with no wasted words. It is appropriately brief for a simple list operation.

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 no output schema and no annotations, the description is too sparse. It fails to explain what the returned list contains or any additional context needed for reliable invocation.

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 no parameters, and schema description coverage is 100%. With zero parameters, the baseline is 4, and the description adds no parameter info since none are 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 specific verb 'List' and the resource 'malleable C2 profiles for HTTP listeners', distinguishing it from sibling tools like empire_listeners and empire_modules which list different entities.

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 (e.g., empire_listeners or empire_modules). The usage context is only implied by the resource name.

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

empire_shellB

Execute shell commands on an Empire agent

ParametersJSON Schema

Name	Required	Description	Default
`agent_id`	Yes	Agent ID or name to execute on
`command`	Yes	Shell command to execute

TDQS

B3.3/5.0

Behavior2/5

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

No annotations provided, so the description must cover behavioral aspects. It fails to disclose critical details like execution context, output retrieval, alert potential, or success criteria.

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?

Single sentence conveys the core purpose efficiently without unnecessary words, though slightly more detail could be added without harming conciseness.

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?

No output schema exists and description omits return value information (e.g., stdout/stderr, exit code), leaving agents uninformed about what to expect after execution.

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?

Input schema has 100% description coverage with clear parameter meanings. The tool description adds no additional parameter info beyond the schema, meeting the baseline expectation.

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 'Execute' and the resource 'shell commands on an Empire agent', distinguishing it from sibling tools like empire_download or empire_upload.

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?

No explicit guidance on when to use this tool versus alternatives; usage is implied by the name and description but could be improved with context about 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.

empire_stagersC

Generate and manage stagers/payloads for Empire agents

ParametersJSON Schema

Name	Required	Description
`action`	Yes	Action to perform
`stager_id`	No	Stager ID (for get, delete)
`template`	No	Stager template name (required for create)
`name`	No	Stager name (required for create)
`options`	No	Stager options including Listener (for create)
`save`	No	Whether to save the stager (default true)

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 must carry the full burden of behavioral disclosure. It merely states 'Generate and manage' without explaining what happens during creation (e.g., listener requirement, network impact), safety, or destruction. This is insufficient for a tool with multiple actions including delete.

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, concise sentence with no redundant words. However, it could be slightly more informative (e.g., listing supported actions) without becoming verbose, so it gets a 4 rather than a 5.

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 tool has 6 parameters, 5 actions (including delete), and an actions-based workflow, the description fails to tie these together. It does not explain that 'action' determines behavior or that a listener is required for creation, leaving the agent underinformed.

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 has 100% description coverage for all 6 parameters, so the schema already documents parameter meaning. The description adds no extra context beyond the schema, fitting the baseline of 3.

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 provides a verb+resource: 'Generate and manage stagers/payloads for Empire agents,' which is clear and distinguishes the tool from siblings like empire_agents or empire_listeners. However, it does not explicitly differentiate from similar tools like empire_modules or empire_profiles, so it falls short of a perfect 5.

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?

There is no guidance on when to use this tool versus its siblings. The description does not mention when to choose empire_stagers over empire_agents or empire_listeners, leaving the agent without context for selection.

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

empire_task_resultB

Get the result of a specific task

ParametersJSON Schema

Name	Required	Description	Default
`agent_id`	Yes	Agent ID or name
`task_id`	Yes	Task ID to get result for

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, and the description only states the tool's function without revealing behavior such as blocking, polling, error handling, or side effects. The agent gains no insight beyond the basic action.

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 with no unnecessary words. It front-loads the core purpose, but could be slightly expanded to include usage context 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?

For a simple two-parameter tool, the description is minimal. It does not explain return format or error scenarios. Given the absence of an output schema, more detail would help the agent understand what to expect.

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 descriptions for both parameters, so the schema already documents their meaning. The description adds no additional context or constraints beyond what is in the input schema.

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 'Get' and the resource 'result of a specific task'. It directly reflects the tool's name and is distinct from sibling tools like empire_shell or empire_download, which handle different operations.

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. It does not indicate prerequisites (e.g., task must be complete) or contrast with related tools like empire_agents or empire_shell.

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

empire_uploadB

Upload a file to an Empire agent

ParametersJSON Schema

Name	Required	Description
`agent_id`	Yes	Agent ID or name
`remote_path`	Yes	Path on the target system to upload to
`file_data`	Yes	Base64-encoded file content

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided, and the description does not disclose behavioral traits like overwrite behavior, size limits, or if authentication is required. The description carries the full burden and adds little beyond the basic action.

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 concise sentence with no redundancy, but it could benefit from slightly more structure (e.g., listing parameters or expected outcomes).

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 3 required parameters and no output schema. The description does not mention return values or confirm upload success. For a simple file upload tool, it is adequate but could be more complete.

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 100%, so the baseline is 3. The tool description does not add meaning beyond what the schema already provides for each parameter.

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 'Upload' and the resource 'file' to an 'Empire agent', distinguishing it from sibling tools like empire_download.

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 on when to use this tool versus alternatives, such as when a file transfer is needed vs. running a module. No prerequisites or exclusions mentioned.

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.

14 tool updatesv1.0.0Jun 10, 2026
- First observedempire_agents
- First observedempire_bypasses
- First observedempire_credentials
- First observedempire_download
- First observedempire_downloads
- First observedempire_hosts
- First observedempire_listeners
- First observedempire_modules
- First observedempire_plugins
- First observedempire_profiles
- First observedempire_shell
- First observedempire_stagers
- First observedempire_task_result
- First observedempire_upload

Install Server

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

TDQS

B3.2/5.0

Disambiguation5/5

Each tool targets a distinct aspect of Empire: agents, bypasses, credentials, file operations, listeners, modules, etc. No two tools have overlapping purposes.

Naming Consistency4/5

All tools share the 'empire_' prefix, but some are verbs (download, upload) while most are nouns. The pattern is predictable, though not perfectly uniform.

Tool Count5/5

14 tools cover the core functionality of a C2 framework without being excessive. Each tool serves a clear role in the agent lifecycle.

Completeness4/5

Major operations (agent management, listeners, modules, stagers, file transfer, credentials) are present. Minor gaps like advanced evasion or detailed logging are absent but acceptable.

Maintenance

ActivityInactive

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

mcp-server
com.pentest-tools
MCP server for Pentest-Tools.com: run scans, manage findings and reports via your preffered LLM.
Penetration Testing Security
23
nexusOAuth
com.civic
Zero-setup MCP gateway securely connecting AI to your tools with authentication and workflows
Agent Orchestration Developer Tools App Automation
2
jumpcloud-genaiOAuth
com.jumpcloud
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Cloud Platforms Security Developer Tools
2
mcp-serverOAuth
com.httpstatus
AI-callable tools for API mocking, testing, monitoring, security, and automation.
API Testing Testing & QA Tools App Automation
2

Related MCP Servers

Metasploit MCP Server
Penetration Testing Autonomous Agents Shell Access
GH05TCREW
A
license
Not graded
quality
D
maintenance
Provides a bridge between large language models and the Metasploit Framework, enabling AI assistants to access and control penetration testing functionality through natural language.
Updated 7 months ago (2026-02-05 16:43 UTC)
720
Apache 2.0
Cobalt Strike MCP Server
Security Penetration Testing Autonomous Agents
MickeyDB
F
license
Not graded
quality
D
maintenance
Enables management of Cobalt Strike red team operations through natural language commands, providing access to 200+ tools for beacon control, listener management, credential operations, and payload generation.
Updated 9 months ago (2025-11-26 11:38 UTC)
-
Burp Suite MCP Server
Penetration Testing Security API Testing
jayluxferro
F
license
A
quality
D
maintenance
Exposes Burp Suite's REST API to AI assistants, enabling users to trigger vulnerability scans, monitor progress, and manage security tasks through natural language. It also provides programmatic access to Burp's security knowledge base for querying vulnerability definitions and remediation advice.
Updated 4 months ago (2026-05-08 13:43 UTC)
8
1
-
Cobalt Strike MCP Serverofficial
Penetration Testing Command Line Shell Access
Cobalt-Strike
A
license
Not graded
quality
D
maintenance
Bridges large language models with the Cobalt Strike C2 framework, enabling AI assistants to control adversary simulation workflows through natural language.
Updated 2 months ago (2026-07-07 07:53 UTC)
46
Apache 2.0

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/schwarztim/sec-powershell-empire-mcp'

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

PowerShell Empire MCP Server

Features

Installation

Configuration

Claude Desktop Configuration

Available Tools

empire_listeners

empire_stagers

empire_agents

empire_modules

empire_shell

empire_upload

empire_download

empire_credentials

empire_hosts

empire_downloads

empire_plugins

empire_bypasses

empire_profiles

empire_task_result

Usage Examples

List Active Agents

Execute a Shell Command

Generate a PowerShell Stager

Search for Modules

Requirements

Security Considerations

License

Disclaimer

References

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Cobalt Strike MCP Serverofficial

Latest Blog Posts

MCP directory API