Сервер Model Context Protocol для взаимодействия с PowerShell. Этот сервер предоставляет инструменты для выполнения команд PowerShell, получения системной информации, управления модулями и т. д.
Node.js 18+
PowerShell 5.1 или PowerShell Core 7+
Related MCP server: Command Executor MCP Server
Установить зависимости:
npm installСоздайте проект:
npm run buildИзменить конфигурацию: $HOME/Library/Application\ Support/Claude/claude_desktop_config.json
Добавить в mcpServers:
{
"mcpServers": {
"mcp-powershell": {
"command": "node",
"args": [
"/absolute/path/to/mcp-powershell/dist/index.js"
]
}
}
}Изменить конфигурацию: $HOME/Library/Application\ Support/Code/User/settings.json
Добавить в настройки:
"mcp": {
"servers": {
"mcp-powershell": {
"command": "node",
"args": [
"/absolute/path/to/mcp-powershell/dist/index.js"
]
}
}
}Изменить конфигурацию: $HOME/.cursor/mcp.json
Добавить в mcpServers:
{
"mcpServers": {
"mcp-powershell": {
"command": "node",
"args": [
"/absolute/path/to/mcp-powershell/dist/index.js"
]
}
}
}Этот сервер PowerShell MCP предоставляет следующие инструменты:
Выполните команду PowerShell и получите результат.
Parameters:
- command (string): PowerShell command to executeПример использования:
execute_ps(command: "Get-Process | Select-Object -First 5")Получите подробную информацию о системе, включая сведения об ОС, процессоре, памяти и версии PowerShell.
Parameters: NoneПример использования:
get_system_info()Выведите список всех установленных модулей PowerShell с указанием таких сведений, как имя, версия и тип.
Parameters: NoneПример использования:
list_modules()Получите подробную справку по конкретной команде PowerShell, включая синтаксис, параметры и примеры.
Parameters:
- command (string): PowerShell command to get help forПример использования:
get_command_help(command: "Get-Process")Поиск команд PowerShell по имени или шаблону.
Parameters:
- search (string): Search term for PowerShell commandsПример использования:
find_commands(search: "Process")Запустите файл скрипта PowerShell с дополнительными параметрами.
Parameters:
- scriptPath (string): Path to the PowerShell script file
- parameters (string, optional): Optional parameters to pass to the scriptПример использования:
run_script(scriptPath: "/path/to/script.ps1", parameters: "-Name 'Test' -Value 123")Для запуска в режиме разработки:
npm run devЧтобы добавить собственные инструменты PowerShell:
Редактировать src/index.ts
Добавить новые инструменты в метод registerTools()
Следуйте существующей схеме для последовательной обработки ошибок.
Сборка с помощью 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}`,
},
],
};
}
}
);Этот сервер выполняет команды PowerShell непосредственно в вашей системе.
Команды выполняются с теми же привилегиями, что и процесс, запускающий сервер MCP.
Будьте осторожны при раскрытии деструктивных операций
Рассмотрите возможность внедрения дополнительной проверки для конфиденциальных команд.
Ограничения политики выполнения PowerShell
Возможно, вам придется настроить политику выполнения PowerShell, чтобы разрешить выполнение скрипта.
Используйте Set-ExecutionPolicy RemoteSigned -Scope CurrentUser для разрешения локальных скриптов.
Ошибки «Путь не найден»
Убедитесь, что пути к файлам являются абсолютными или правильно указаны относительно рабочего каталога.
Используйте соответствующие разделители пути для вашей ОС.
Ошибки «Команда не найдена»
Некоторые команды могут потребовать установки определенных модулей.
Используйте Install-Module ModuleName для установки необходимых модулей.
Массачусетский технологический институт
| 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.