AI モデルが Windows のコマンドライン機能と安全かつ効率的に対話できるようにする、安全なモデル コンテキスト プロトコル (MCP) サーバー。
Windows コマンドライン MCP サーバーは、AI モデルと Windows システム操作の間に堅牢かつ安全なブリッジを提供します。厳格なセキュリティプロトコルを維持しながら、コマンドの実行、プロジェクトの作成、システム情報の取得を制御できます。
Related MCP server: Windows CLI MCP Server
包括的なコマンド許可リスト
厳格な入力検証
破壊的なシステム操作の防止
設定可能なセキュリティレベル
React、Node.js、Python のプロジェクト作成
安全な開発環境のインタラクション
開発ワークフローのコマンドサポートの拡張
Windows CLIコマンドを実行する
PowerShellスクリプトを実行する
システムとネットワーク情報を取得する
プロセスとサービスを管理する
Smithery経由で Claude Desktop 用の Windows コマンドライン MCP サーバーを自動的にインストールするには:
npx -y @smithery/cli install @alxspiker/Windows-Command-Line-MCP-Server --client claudeNode.js 16以降
npmまたはyarn
Windows オペレーティング システム
git clone https://github.com/alxspiker/Windows-Command-Line-MCP-Server.git
cd Windows-Command-Line-MCP-Server
npm install
npm run buildデフォルトモード: 事前定義された安全なコマンドを使用する
--allow-all : 拡張モードで実行（追加の予防措置付き）
カスタムコマンドリストを引数として指定できる
組み込みのプロジェクト作成ツールを使用して、安全に新しいプロジェクトを作成します。
サポートされているプロジェクトタイプ: React、Node.js、Python
サンドボックス化された~/AIProjectsディレクトリに作成されたプロジェクト
execute_command : Windows CLI コマンドを実行する
execute_powershell : PowerShell スクリプトを実行する
create_project : 新しい開発プロジェクトを安全に作成する
list_running_processes : アクティブなシステムプロセスを取得する
get_system_info : システム構成の詳細を収集する
get_network_info : ネットワークアダプタ情報を取得する
get_scheduled_tasks : システムタスクの一覧表示とクエリ
get_service_info : Windows サービスの管理とクエリ
list_allowed_commands : サーバーで実行できるすべてのコマンドを一覧表示します
このサーバーをClaude for Desktopで使用するには:
上記のセットアップ手順に従ってサーバーを構築します
これをclaude_desktop_config.jsonに追加します。
{
"mcpServers": {
"windows-cmd": {
"command": "node",
"args": ["/path/to/dist/index.js"]
}
}
}/path/to/dist/index.js 、 distディレクトリに構築されたindex.jsファイルへの絶対パスに置き換えます。
デスクトップ版のClaudeを再起動
クロードにWindowsシステム操作を依頼することでツールを使用できるようになりました
デフォルトでは、安全なコマンドのみが許可されます。
システム情報の取得
ネットワーク構成
プロセス管理
開発ツールの相互作用
次のような危険なコマンドは常にブロックされます:
ディスクのフォーマット
ユーザー管理
システムのシャットダウン
重要なレジストリの変更
許可されたコマンドを指定するか、構成フラグを使用して、サーバーの動作をカスタマイズします。
# Run with default safe commands
node dist/index.js
# Run with specific allowed commands
node dist/index.js dir echo npm git
# Run in extended mode (use with caution)
node dist/index.js --allow-allリポジトリをフォークする
機能ブランチを作成します（ git checkout -b feature/amazing-feature ）
変更をコミットします ( git commit -m 'Add some amazing feature' )
ブランチにプッシュする ( git push origin feature/amazing-feature )
プルリクエストを開く
このプロジェクトは MIT ライセンスに基づいてライセンスされています - 詳細についてはLICENSEファイルを参照してください。
モデルコンテキストプロトコル仕様に触発されて
セキュリティと柔軟性を考慮して開発
0.3.0 : README に記載されているすべてのツールを実装しました (システム情報、ネットワーク情報、プロセス管理、サービス情報)
0.2.0 : プロジェクト作成機能の追加、開発ツールの拡張
0.1.0 : 基本的なコマンド実行機能を備えた最初のリリース
問題、質問、または提案については、GitHub で問題を開いてください。
Execute a Windows command and return its output. Only commands in the allowed list can be executed. This tool should be used for running simple commands like 'dir', 'echo', etc.
| Name | Required | Description | Default |
|---|---|---|---|
| command | Yes | The command to execute | |
| workingDir | No | Working directory for the command | |
| timeout | No | Timeout in milliseconds |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the allowed-list constraint and suggests simple commands, but lacks critical details: it doesn't specify security implications (e.g., permissions required), error handling, output format, or potential side effects (e.g., whether commands can modify the system). For a command execution tool with zero annotation coverage, this is inadequate.
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?
The description is concise (two sentences) and front-loaded with the core purpose. The second sentence adds useful constraints and examples, but could be slightly more structured (e.g., separating constraints from examples). Overall, it's efficient with minimal waste.
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?
Given the complexity (command execution with security implications), lack of annotations, and no output schema, the description is incomplete. It mentions an allowed list and simple commands but omits critical context: what the output looks like, error conditions, safety warnings, or how to check allowed commands (via 'list_allowed_commands'). This leaves significant gaps for an AI agent to use it correctly.
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?
Schema description coverage is 100%, so the schema already documents all three parameters ('command', 'workingDir', 'timeout') with descriptions. The description adds no additional parameter semantics beyond what's in the schema, such as examples of allowed commands or timeout behavior. Baseline is 3 when schema coverage is high and no extra param info is provided.
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?
The description clearly states the tool's purpose: 'Execute a Windows command and return its output.' It specifies the verb ('execute'), resource ('Windows command'), and outcome ('return its output'). However, it doesn't explicitly differentiate from sibling tools like 'execute_powershell' or 'list_allowed_commands', which would be needed for a score of 5.
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?
The description provides some usage context: 'Only commands in the allowed list can be executed' and 'This tool should be used for running simple commands like 'dir', 'echo', etc.' This implies when to use it (for simple commands) and hints at constraints, but it doesn't explicitly state when NOT to use it or name alternatives (e.g., use 'execute_powershell' for PowerShell scripts), so it falls short of explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a PowerShell script and return its output. This allows for more complex operations and script execution. PowerShell must be in the allowed commands list.
| Name | Required | Description | Default |
|---|---|---|---|
| script | Yes | PowerShell script to execute | |
| workingDir | No | Working directory for the script | |
| timeout | No | Timeout in milliseconds |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions that the tool returns output and has a prerequisite (PowerShell in allowed commands), but lacks details on security implications, error handling, execution environment, or potential side effects. For a tool that executes arbitrary scripts, this is a significant gap in transparency.
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?
The description is appropriately concise with two sentences that each serve a purpose - the first states the core functionality, the second adds an important constraint. It's front-loaded with the main purpose and avoids unnecessary elaboration.
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?
Given this is a potentially dangerous script execution tool with no annotations and no output schema, the description is insufficient. It doesn't explain what kind of output to expect, error conditions, security implications, or execution limitations. For a tool that could have significant system impact, more context is needed.
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?
Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it mentions script execution generally but provides no additional context about parameter usage, constraints, or examples.
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?
The description clearly states the tool executes a PowerShell script and returns output, specifying the verb 'execute' and resource 'PowerShell script'. It distinguishes from sibling tools like execute_command by specifying PowerShell specifically, though it doesn't explicitly contrast with them.
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?
The description implies usage context by stating 'PowerShell must be in the allowed commands list', suggesting a prerequisite. However, it doesn't provide explicit guidance on when to use this tool versus alternatives like execute_command or other system tools, leaving usage context somewhat implied rather than clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve network configuration information including IP addresses, adapters, and DNS settings. Can be filtered to a specific interface.
| Name | Required | Description | Default |
|---|---|---|---|
| networkInterface | No | Optional interface name to filter results |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While it states what information is retrieved, it doesn't describe important behavioral aspects like whether this requires administrative privileges, what format the information is returned in, whether it's a read-only operation, or any rate limits or constraints. The description is insufficient for a tool that presumably accesses system-level network configuration.
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?
The description is efficiently structured in two sentences that each serve clear purposes: the first establishes the core functionality, and the second adds the filtering capability. There's no wasted language or redundancy, making it appropriately sized and front-loaded with essential information.
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?
Given that there are no annotations and no output schema, the description is incomplete for a tool that retrieves system network configuration. It doesn't explain what format the information is returned in, what permissions are required, whether it's safe to use, or what specific data structures to expect. For a system-level information retrieval tool, this leaves significant gaps in understanding.
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?
Schema description coverage is 100%, so the schema already fully documents the single optional parameter. The description adds marginal value by mentioning the filtering capability ('Can be filtered to a specific interface'), which aligns with the schema's description of 'Optional interface name to filter results.' No additional parameter semantics beyond what the schema provides are included.
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?
The description clearly states the tool's purpose with specific verbs ('retrieve') and resources ('network configuration information'), and lists concrete examples of what information is retrieved (IP addresses, adapters, DNS settings). It distinguishes itself from siblings like get_system_info by focusing specifically on network configuration rather than general system information.
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?
The description implies usage context by mentioning filtering capability ('Can be filtered to a specific interface'), but doesn't explicitly state when to use this tool versus alternatives like get_system_info or other sibling tools. No guidance is provided about when NOT to use this tool or what specific scenarios warrant its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve information about scheduled tasks on the system. Can query all tasks or get detailed status of a specific task.
| Name | Required | Description | Default |
|---|---|---|---|
| action | No | Action to perform | query |
| taskName | No | Name of the specific task (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions retrieving information, which implies a read-only operation, but doesn't disclose behavioral traits such as permissions required, potential rate limits, whether it returns real-time or cached data, or error conditions. For a system tool with zero annotation coverage, this is a significant gap in transparency.
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?
The description is two sentences, front-loaded with the core purpose and followed by key usage details. Every word earns its place without redundancy, making it highly efficient and easy to parse.
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?
Given no annotations and no output schema, the description is minimally adequate for a read-only tool with well-documented parameters. It covers the basic purpose and parameter implications but lacks details on return values, error handling, or system-specific constraints. For a tool interacting with system tasks, more context would be beneficial.
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?
Schema description coverage is 100%, with clear descriptions for both parameters (e.g., 'Action to perform' for 'action' and 'Name of the specific task' for 'taskName'). The description adds some value by explaining that 'query' retrieves all tasks and 'status' gets detailed info for a specific task, but this mostly reiterates what the enum and schema imply. Baseline 3 is appropriate since the schema does the heavy lifting.
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?
The description clearly states the verb ('Retrieve information') and resource ('scheduled tasks on the system'), making the purpose unambiguous. It distinguishes between querying all tasks and getting detailed status of a specific task, which is helpful. However, it doesn't explicitly differentiate from sibling tools like 'get_service_info' or 'list_running_processes' that also retrieve system information, preventing a perfect score.
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?
The description implies usage guidelines by mentioning 'all tasks' vs. 'specific task', which correlates with the 'action' parameter. However, it lacks explicit guidance on when to use this tool versus alternatives like 'get_service_info' for services or 'list_running_processes' for processes. No exclusions or prerequisites are stated, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve information about Windows services. Can query all services or get detailed status of a specific service.
| Name | Required | Description | Default |
|---|---|---|---|
| action | No | Action to perform | query |
| serviceName | No | Service name to get info about (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While it mentions the tool can 'retrieve information' and 'query all services or get detailed status,' it doesn't disclose important behavioral aspects like whether this requires administrative privileges, what format the information returns in, potential rate limits, or error conditions. The description provides basic functionality but lacks operational context.
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?
The description is perfectly concise with just two sentences that efficiently convey the tool's purpose and main functionality. Every word earns its place, and the information is front-loaded with the core purpose stated immediately. No wasted words or redundant information.
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?
For a read-only information retrieval tool with 2 parameters and 100% schema coverage but no output schema, the description provides adequate basic context about what the tool does. However, it doesn't explain what information is returned, the format of the response, or how to interpret the results. Given the lack of output schema and no annotations, more detail about the return value would be helpful for completeness.
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?
The description adds some semantic context by explaining that the tool can 'query all services or get detailed status of a specific service,' which maps to the action parameter's enum values. However, with 100% schema description coverage where both parameters are well-documented in the schema, the description doesn't provide significant additional value beyond what's already in the structured schema. The baseline of 3 is appropriate when the schema does most of the parameter documentation work.
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?
The description clearly states the tool's purpose with specific verbs ('retrieve information', 'query', 'get detailed status') and identifies the resource ('Windows services'). It distinguishes between querying all services and getting status for a specific service, but doesn't explicitly differentiate from sibling tools like get_system_info or get_network_info that might also retrieve system information.
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?
The description implies usage scenarios (query all services vs. get status for specific service) through the action parameter explanation, but doesn't provide explicit guidance on when to use this tool versus alternatives like get_system_info or get_scheduled_tasks. No when-not-to-use guidance or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve system information including OS, hardware, and user details. Can provide basic or full details.
| Name | Required | Description | Default |
|---|---|---|---|
| detail | No | Level of detail | basic |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool can 'provide basic or full details,' which adds some context about output granularity, but fails to address critical aspects such as whether this is a read-only operation, potential performance impacts, or authentication requirements, leaving significant gaps.
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?
The description is highly concise and front-loaded, consisting of just two sentences that efficiently convey the core functionality and parameter options without any wasted words. Every sentence earns its place by adding relevant information.
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?
Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is minimally adequate but incomplete. It covers the basic purpose and parameter hint, yet lacks details on behavioral traits, usage context, or output format, which are needed for a more comprehensive understanding.
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?
The schema description coverage is 100%, with the parameter 'detail' fully documented in the input schema (including enum values and default). The description adds minimal value by mentioning 'basic or full details,' which aligns with the schema but doesn't provide additional semantic context beyond what's already structured.
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?
The description clearly states the tool's purpose with specific verbs ('retrieve') and resources ('system information including OS, hardware, and user details'), making it easy to understand what it does. However, it doesn't explicitly differentiate from sibling tools like 'get_network_info' or 'get_service_info', which prevents a perfect score.
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?
The description provides no guidance on when to use this tool versus alternatives like 'get_network_info' or 'execute_command', nor does it mention any prerequisites or exclusions. It only hints at usage through the 'detail' parameter options, but this is insufficient for effective tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all commands that are allowed to be executed by this server. This helps understand what operations are permitted.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It indicates this is a read operation ('List') for informational purposes, which is clear but lacks details on rate limits, authentication needs, or output format. No contradiction exists, but it's minimal beyond basic intent.
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?
The description is two concise sentences that front-load the core purpose and follow with a brief utility statement. Every word earns its place with no redundancy or fluff, making it highly efficient and well-structured.
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?
Given the tool's low complexity (0 parameters, no annotations, no output schema), the description is adequate but minimal. It covers the basic purpose and utility but lacks details on behavioral traits like response format or system-specific constraints, which could be helpful for an agent in this server context.
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?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter details, and it correctly aligns with this by not mentioning any parameters, earning a baseline score for parameterless tools.
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?
The description clearly states the tool's purpose with a specific verb ('List') and resource ('all commands that are allowed to be executed'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'execute_command' or 'get_system_info' beyond the general scope of permissions.
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?
The description implies usage by stating 'This helps understand what operations are permitted,' suggesting it's for checking permissions before executing commands. However, it lacks explicit guidance on when to use this versus alternatives like 'execute_command' or other system-info tools, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all running processes on the system. Can be filtered by providing an optional filter string that will match against process names.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | Optional filter string to match against process names |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While it mentions filtering capability, it doesn't describe what information is returned about each process, whether the list is real-time or cached, permission requirements, or potential system impact. For a system query tool with zero annotation coverage, this leaves significant behavioral gaps.
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?
Two clear, efficient sentences with zero waste. The first states the core purpose, the second adds the optional filtering capability. Perfectly front-loaded and appropriately sized for this simple tool.
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?
For a simple read-only query tool with one well-documented parameter, the description is minimally adequate. However, with no annotations and no output schema, it should ideally provide more context about what process information is returned and any system considerations.
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?
Schema description coverage is 100%, so the schema already fully documents the single optional filter parameter. The description adds no additional parameter semantics beyond what's in the schema, maintaining the baseline score for high schema coverage.
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?
The description clearly states the specific action ('List all running processes') and resource ('on the system'), with explicit mention of filtering capability. It distinguishes from siblings like execute_command or get_system_info by focusing specifically on process enumeration.
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?
The description implies usage for viewing running processes, but provides no explicit guidance on when to use this tool versus alternatives like get_service_info or list_allowed_commands. No exclusions or prerequisites are mentioned.
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.0list_allowed_commands1 field changedInput schema / additionalPropertiesRemoved value: -falseexecute_commandexecute_powershellget_network_infoget_scheduled_tasksget_service_infoget_system_infolist_allowed_commandslist_running_processesScored across 8 tools
Each tool has a clearly distinct purpose with no overlap: execute_command for basic commands, execute_powershell for scripts, get_network_info for networking, get_scheduled_tasks for tasks, get_service_info for services, get_system_info for system details, list_allowed_commands for permissions, and list_running_processes for processes. The descriptions clearly differentiate them, preventing misselection.
The naming is mostly consistent with a verb_noun pattern (e.g., execute_command, get_network_info, list_allowed_commands), but there is a minor deviation with 'list_running_processes' using 'running' as an adjective instead of a simple noun like 'processes'. This slight inconsistency does not significantly hinder readability.
With 8 tools, the count is well-scoped for a Windows command line server, covering essential operations like command execution, system queries, and permissions. Each tool earns its place without feeling excessive or insufficient for the domain.
The tool set provides good coverage for querying system state (e.g., network, services, tasks) and executing commands, but there are minor gaps such as no tools for managing or modifying these elements (e.g., starting/stopping services, creating tasks). Agents can work around this by using execute_powershell for such operations.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol server for Wix AI tools
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
Enable secure connectivity between Sentry issues and debugging data, and LLM clients, using a Model Context Protocol (MCP) server.
