Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Windows-MCP delete the 'old-project' folder on my desktop"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
windows-mcp
MCP server for Windows desktop file/folder management via the Model Context Protocol.
📋 Table of Contents
Overview Requirements Installation Usage Available Tools Project Structure Development Security License
Overview windows-mcp is a Model Context Protocol (MCP) server that exposes tools to manage files and folders on the Windows Desktop. It communicates via stdio transport and is designed to be connected to any MCP-compatible client (e.g., Claude Desktop).
Requirements
Node.js >= 18 Windows OS (relies on USERPROFILE and Desktop path conventions) npm >= 8
Installation bash# Clone the repository git clone https://github.com/your-username/windows-mcp.git cd windows-mcp
npm install
npm run build
Usage Start the MCP server bashnpm start The server communicates over stdio and is ready to be connected to an MCP client. Connecting with Claude Desktop Add the following to your claude_desktop_config.json: json{ "mcpServers": { "windows-mcp": { "command": "node", "args": ["C:/path/to/windows-mcp/dist/index.js"] } } }
Available Tools delete_folder Deletes a file or folder located on the Windows Desktop. ParameterTypeRequiredDescriptionpathstring✅Relative path within the Desktop Example input: json{ "path": "old-project" } Example response: json{ "success": true, "deleted": "old-project" }
⚠️ Deletion is permanent and recursive. Use with caution.
Project Structure windows-mcp/ ├── src/ │ ├── index.ts # Entry point │ ├── server.ts # MCP server setup & request handlers │ ├── config/ │ │ └── paths.ts # Desktop path resolution │ ├── handlers/ │ │ └── deleteFolder.handler.ts # Business logic for delete tool │ ├── tools/ │ │ └── deleteFolder.tool.ts # Tool schema definition │ └── utils/ │ └── pathValidator.ts # Path safety validation ├── dist/ # Compiled output (generated) ├── tsconfig.json ├── package.json └── README.md
Development Scripts CommandDescriptionnpm run buildCompile TypeScript to dist/npm startRun the compiled servernpm testRun tests (not yet configured) Build bashnpm run build TypeScript sources in src/ are compiled to dist/ using the config in tsconfig.json (target: ES2022, module: NodeNext).
Security All file operations are restricted to the Windows Desktop directory. The server enforces:
Path traversal prevention — any path resolving outside the Desktop is rejected. Existence check — operations on non-existent paths return a descriptive error.
Paths like ../../Windows/System32 will be blocked with an error: Solo se permite borrar dentro del Escritorio
License MIT © 2026 Emilio José Ugeda Sanoja — see LICENSE for details.
Elimina archivos o carpetas dentro del Escritorio de Windows
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Ruta relativa dentro del Escritorio |
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 'Elimina' implies a destructive operation, the description doesn't specify whether deletion is permanent or reversible, what permissions are required, or how errors are handled. Significant behavioral details are missing for a destructive operation.
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 a single, efficient sentence that gets straight to the point without unnecessary words. However, it could be slightly improved by front-loading the most critical information more explicitly about the destructive nature of the operation.
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 destructive tool with no annotations and no output schema, the description is inadequate. It doesn't explain what happens after deletion, whether there's confirmation or undo capability, what errors might occur, or what the tool returns. The description should provide more complete context for such a potentially dangerous operation.
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 the single 'path' parameter. The description doesn't add any meaningful parameter semantics beyond what's in the schema - it mentions the Desktop context but doesn't clarify path format, wildcard support, or deletion scope. Baseline 3 is appropriate when schema does the 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 action ('Elimina' - deletes) and the target ('archivos o carpetas dentro del Escritorio de Windows'), providing a specific verb+resource combination. However, with no sibling tools mentioned, there's no opportunity to distinguish from alternatives, 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 provides no guidance on when to use this tool versus alternatives, prerequisites, or exclusions. It simply states what the tool does without context about appropriate usage scenarios or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
With only one tool, there is no possibility of ambiguity or overlap between tools. The tool's purpose is clearly distinct by default, as there are no other tools to compare it against.
The single tool name follows a clear verb_noun pattern (delete_folder), and since there is only one tool, consistency is inherently perfect with no deviations or mixed conventions.
A single tool for a server named 'Windows-MCP' suggests an extremely limited scope. This is likely too few tools for managing Windows operations, as it lacks basic CRUD or lifecycle coverage for files, processes, or system settings, making it feel incomplete for the implied domain.
The tool set is severely incomplete for a Windows management server. It only offers deletion of folders on the Desktop, with no tools for creating, reading, updating, or managing other aspects like files, processes, registry, or system information, leading to significant gaps and dead ends.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP Server for an Agent Task Marketplace
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/emilioejus/Windows-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
