PowerShell과 상호 작용하기 위한 모델 컨텍스트 프로토콜 서버입니다. 이 서버는 PowerShell 명령 실행, 시스템 정보 검색, 모듈 관리 등의 도구를 제공합니다.
노드.js 18+
PowerShell 5.1 또는 PowerShell Core 7+
Related MCP server: Command Executor MCP Server
종속성 설치:
지엑스피1
프로젝트를 빌드하세요:
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")OS 세부 정보, 프로세서, 메모리, 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 사용하세요.
경로를 찾을 수 없음 오류
파일 경로가 절대 경로인지 또는 작업 디렉토리에 대한 상대 경로인지 확인하십시오.
OS에 맞는 경로 구분 기호를 사용하세요.
명령을 찾을 수 없음 오류
일부 명령에는 특정 모듈을 설치해야 할 수도 있습니다.
Install-Module ModuleName 사용하여 필요한 모듈을 설치합니다.
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.