用于与 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.