Un servidor de Protocolo de Contexto de Modelo para interactuar con PowerShell. Este servidor proporciona herramientas para ejecutar comandos de PowerShell, recuperar información del sistema, administrar módulos y mucho más.
Node.js 18+
PowerShell 5.1 o PowerShell Core 7+
Related MCP server: Command Executor MCP Server
Instalar dependencias:
npm installConstruir el proyecto:
npm run buildEditar configuración: $HOME/Library/Application\ Support/Claude/claude_desktop_config.json
Agregar a mcpServers:
{
"mcpServers": {
"mcp-powershell": {
"command": "node",
"args": [
"/absolute/path/to/mcp-powershell/dist/index.js"
]
}
}
}Editar configuración: $HOME/Library/Application\ Support/Code/User/settings.json
Agregar a la configuración:
"mcp": {
"servers": {
"mcp-powershell": {
"command": "node",
"args": [
"/absolute/path/to/mcp-powershell/dist/index.js"
]
}
}
}Editar configuración: $HOME/.cursor/mcp.json
Agregar a mcpServers:
{
"mcpServers": {
"mcp-powershell": {
"command": "node",
"args": [
"/absolute/path/to/mcp-powershell/dist/index.js"
]
}
}
}Este servidor MCP de PowerShell proporciona las siguientes herramientas:
Ejecute un comando de PowerShell y obtenga el resultado.
Parameters:
- command (string): PowerShell command to executeEjemplo de uso:
execute_ps(command: "Get-Process | Select-Object -First 5")Recupere información detallada del sistema, incluidos detalles del sistema operativo, procesador, memoria y versión de PowerShell.
Parameters: NoneEjemplo de uso:
get_system_info()Enumere todos los módulos de PowerShell instalados con detalles como nombre, versión y tipo.
Parameters: NoneEjemplo de uso:
list_modules()Obtenga ayuda detallada para un comando específico de PowerShell, incluida sintaxis, parámetros y ejemplos.
Parameters:
- command (string): PowerShell command to get help forEjemplo de uso:
get_command_help(command: "Get-Process")Busque comandos de PowerShell por nombre o patrón.
Parameters:
- search (string): Search term for PowerShell commandsEjemplo de uso:
find_commands(search: "Process")Ejecute un archivo de script de PowerShell con parámetros opcionales.
Parameters:
- scriptPath (string): Path to the PowerShell script file
- parameters (string, optional): Optional parameters to pass to the scriptEjemplo de uso:
run_script(scriptPath: "/path/to/script.ps1", parameters: "-Name 'Test' -Value 123")Para ejecutar en modo de desarrollo:
npm run devPara agregar sus propias herramientas de PowerShell:
Editar src/index.ts
Agregar nuevas herramientas en el método registerTools()
Siga el patrón existente para un manejo consistente de errores
Construir con npm run build
// In the registerTools() method:
this.server.tool(
"my_ps_tool",
{
param1: z.string().describe("Description of parameter 1"),
param2: z.number().optional().describe("Optional numeric parameter"),
},
async ({ param1, param2 }) => {
try {
// Your PowerShell command
const command = `Your-PowerShell-Command -Param1 "${param1}" ${param2 ? `-Param2 ${param2}` : ''}`;
const { stdout, stderr } = await execAsync(`powershell -Command "${command.replace(/"/g, '\\"')}"`);
if (stderr) {
return {
isError: true,
content: [
{
type: "text" as const,
text: `Error in my_ps_tool: ${stderr}`,
},
],
};
}
return {
content: [
{
type: "text" as const,
text: stdout,
},
],
};
} catch (error) {
return {
isError: true,
content: [
{
type: "text" as const,
text: `Error in my_ps_tool: ${(error as Error).message}`,
},
],
};
}
}
);Este servidor ejecuta comandos de PowerShell directamente en su sistema
Los comandos se ejecutan con los mismos privilegios que el proceso que ejecuta el servidor MCP
Tenga cuidado al exponerse a operaciones destructivas
Considere implementar una validación adicional para comandos sensibles
Restricciones de la política de ejecución de PowerShell
Es posible que necesite ajustar su política de ejecución de PowerShell para permitir la ejecución de scripts
Utilice Set-ExecutionPolicy RemoteSigned -Scope CurrentUser para permitir scripts locales
Errores de ruta no encontrada
Asegúrese de que las rutas de archivo sean absolutas o relativas al directorio de trabajo
Utilice separadores de ruta adecuados para su sistema operativo
Errores de comando no encontrado
Algunos comandos pueden requerir la instalación de módulos específicos
Utilice Install-Module ModuleName para instalar los módulos necesarios
Instituto Tecnológico de Massachusetts (MIT)
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | PowerShell command to execute |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| search | Yes | Search term for PowerShell commands |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | PowerShell command to get help for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
| Name | Required | Description | Default |
|---|---|---|---|
| parameters | No | Optional parameters to pass to the script | |
| scriptPath | Yes | Path to the PowerShell script file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0execute_psfind_commandsget_command_helpget_system_infolist_modulesrun_scriptScored across 6 tools
Each tool has a clearly distinct purpose with no overlap: execute_ps runs commands, find_commands searches for commands, get_command_help provides documentation, get_system_info retrieves system data, list_modules shows available modules, and run_script executes script files. The verbs and nouns clearly differentiate their functions.
All tool names follow a consistent snake_case verb_noun pattern (e.g., execute_ps, find_commands, get_command_help). The naming is uniform throughout with no deviations in style or convention.
With 6 tools, the count is reasonable for a PowerShell server, covering core operations like command execution, help, and system info. It might benefit from additional tools for more advanced PowerShell features, but it's well-scoped for basic functionality.
The tools cover essential PowerShell operations like executing commands, getting help, and listing modules, but there are notable gaps such as no tools for managing processes, services, or files, which are common in PowerShell workflows. The surface is functional but incomplete for full domain coverage.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol server for Wix AI tools
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to control Unreal E…
Remote MCP server exposing your Node Command fleet (files, shell, processes, browser) to AI hosts.