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., "@WSLSnapit-MCP capture a screenshot of my VS Code window"
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.
WSLSnapit-MCP is a powerful Model Context Protocol (MCP) server that provides advanced screenshot capture and clipboard reading capabilities for Windows applications from within WSL environments. It enables AI assistants to capture screens, windows, and monitors with intelligent image processing and optimization, as well as read text and images from the Windows clipboard.
Monitor Selection: Capture all monitors, primary monitor, or specific monitor by number
Window Targeting: Capture specific windows by title (partial match) or process name
Smart Compression: Automatic image optimization to stay under 1MB with progressive quality adjustment
Direct Return: Images can be returned directly to AI assistants or saved to disk
DPI-Aware: Handles multi-monitor setups with different scaling factors correctly
Auto-Detection: Automatically detects whether clipboard contains text or image
Text Support: Read text content from Windows clipboard
Image Support: Capture images from clipboard with automatic compression
Format Control: Force specific format (text/image) or use auto mode
Efficient Processing: Memory-conscious handling of high-resolution captures
Progressive Compression: Dynamic quality adjustment (1920px → 1280px → 800px if needed)
Optimized Communication: Base64 encoding for reliable binary data transfer
Related MCP server: Desktop MCP
Windows 10/11 with WSL2 installed
Node.js 18.0.0 or higher
npm, yarn, or bun package manager
PowerShell (comes with Windows)
# Clone the repository
git clone https://github.com/yourusername/WSLSnapit-MCP.git
cd WSLSnapit-MCP
# Install dependencies
npm install
# or
yarn install
# or
bun installAdd the following to your Claude Desktop configuration file:
Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json
{
"mcpServers": {
"wslsnapit": {
"command": "wsl",
"args": [
"--cd",
"/mnt/h/dev/mcp/wslsnapit-mcp",
"node",
"index.js"
]
}
}
}Note: Adjust the path /mnt/h/dev/mcp/wslsnapit-mcp to match your installation location.
The take_screenshot tool supports various capture modes:
// Capture all monitors (default)
take_screenshot()
// Capture primary monitor only
take_screenshot({ monitor: "primary" })
// Capture specific monitor (1, 2, 3, etc.)
take_screenshot({ monitor: 2 })// Capture window by title (partial match)
take_screenshot({ windowTitle: "Visual Studio" })
// Capture window by process name
take_screenshot({ processName: "notepad" })
// Handle multiple matching windows
take_screenshot({ windowTitle: "Chrome", windowIndex: 2 })// Return image directly (default)
take_screenshot({ returnDirect: true })
// Save to file
take_screenshot({
returnDirect: false,
filename: "myshot.png",
folder: "/home/user/screenshots"
})
// Control JPEG quality (for direct return)
take_screenshot({
returnDirect: true,
quality: 90
})The read_clipboard tool supports both text and image content:
// Auto-detect clipboard content (default)
read_clipboard()
// Force text reading
read_clipboard({ format: "text" })
// Force image reading
read_clipboard({ format: "image" })Parameter | Type | Default | Description |
| string | "screenshot.png" | Filename when saving to disk |
| string|number | "all" | Monitor selection: "all", "primary", or monitor number |
| string | - | Capture window by title (partial match) |
| number | 1 | Which window to capture when multiple match |
| string | - | Capture window by process name |
| string | - | Custom folder path (supports WSL and Windows paths) |
| boolean | true | Return image to AI or save to disk |
| number | 80 | JPEG quality (1-100) for direct return |
Parameter | Type | Default | Description |
| string | "auto" | Format: "auto", "text", or "image" |
WSLSnapit-MCP is designed with security in mind:
Minimal Permissions: Windows executable runs with minimal permissions, only accessing screen capture and clipboard APIs
Local Processing: All clipboard data is processed locally without any network transmission
Process Isolation: PowerShell runs as a separate Windows process, preventing access to sensitive WSL environment
Input Validation: All user inputs are properly escaped to prevent injection attacks
Resource Limits: Memory limits and progressive compression prevent resource exhaustion
MCP Server: Implements the Model Context Protocol for AI assistant integration
PowerShell Bridge: Executes Windows-specific operations from WSL
Image Processor: Uses Sharp library for efficient image compression
Path Handler: Seamlessly converts between WSL and Windows paths
Node.js with ES modules
@modelcontextprotocol/sdk for MCP implementation
Sharp for image processing
PowerShell for Windows API integration
"No windows found" error
Ensure the target window is visible and not minimized
Try using a shorter or different part of the window title
Use process name instead of window title
Large screenshots fail to return
The tool automatically compresses images to stay under 1MB
If issues persist, try lowering the quality parameter
Clipboard reading returns empty
Ensure content is properly copied to clipboard
Try specifying the format explicitly instead of using auto-detect
Path not found errors
Verify the folder path exists
Remember WSL paths start with /mnt/c/ for C: drive
To run with debug output:
DEBUG=* node index.jsContributions are welcome! Please feel free to submit a Pull Request. For major changes, please open an issue first to discuss what you would like to change.
Fork the repository
Create your feature branch (git checkout -b feature/AmazingFeature)
Commit your changes (git commit -m 'Add some AmazingFeature')
Push to the branch (git push origin feature/AmazingFeature)
Open a Pull Request
This project is licensed under the MIT License - see the LICENSE file for details.
Built for use with Claude Desktop and the Model Context Protocol
Image processing powered by Sharp
Thanks to the MCP community for inspiration and support
🐛 Report bugs by opening an issue
💡 Request features through GitHub discussions
📧 Contact: your-email@example.com
Made with ❤️ for the WSL and MCP community
Read the current Windows clipboard content (text or image)
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | Format to read from clipboard (auto=detect best format, text=force text, image=force image) | auto |
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 reads clipboard content but fails to describe important behaviors like whether it requires specific permissions, how it handles errors, what happens if the clipboard is empty, or the format of returned data. The description is minimal and 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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple tool, though it could be slightly more informative without sacrificing brevity.
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 tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what the tool returns, how errors are handled, or any operational constraints. Given the tool's potential complexity (reading both text and images from the clipboard), more context is needed for effective use.
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 input schema has 100% description coverage, fully documenting the single parameter 'format' with its enum values and default. The description adds no additional parameter semantics beyond what's in the schema, but since schema coverage is high, the baseline score of 3 is appropriate.
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 ('Read') and resource ('current Windows clipboard content'), specifying it handles both text and image formats. It distinguishes itself from the sibling tool 'take_screenshot' by focusing on clipboard access rather than screen capture.
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, nor does it mention any prerequisites or context for usage. It simply states what the tool does without indicating appropriate scenarios or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WSLSnapIt: Smart screenshot capture for WSL. Capture monitors, windows by title/process, with direct image return and auto-compression.
| Name | Required | Description | Default |
|---|---|---|---|
| filename | No | Filename for the screenshot (default: screenshot.png). Ignored when returnDirect is true. | screenshot.png |
| monitor | No | Which monitor to capture: "all" (default), "primary", or monitor number (1, 2, etc.) | all |
| windowTitle | No | Capture a specific window by its title (partial match supported). If multiple windows match, you'll get a list to choose from. | |
| windowIndex | No | When multiple windows match the title, specify which one to capture (1 for first, 2 for second, etc.). Default: 1 | |
| processName | No | Capture a specific window by process name (e.g., "notepad.exe" or just "notepad") | |
| folder | No | Custom folder path to save the screenshot (supports both WSL and Windows paths). Ignored when returnDirect is true. | |
| returnDirect | No | If true, returns the image directly to Claude without saving to disk. Large images will be automatically resized and compressed to fit within 1MB limit. | |
| quality | No | JPEG quality (1-100). Only applies when returnDirect is true. Default: 80. Will be automatically reduced if needed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: 'direct image return' (output behavior), 'auto-compression' (processing behavior), and 'smart' capture with title/process matching. It doesn't mention potential side effects like screen flashing or permissions needed, but covers the core functionality adequately for a tool with no annotations.
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 - a single sentence that packs essential information: tool identity (WSLSnapIt), purpose (smart screenshot capture), context (for WSL), key features (capture options), and behavioral traits (direct return, auto-compression). Every word earns its place with zero redundancy.
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 tool with 8 parameters, 100% schema coverage, and no output schema, the description provides good contextual completeness. It covers the tool's purpose, key behaviors, and context. The main gap is lack of output format details (what exactly is returned when returnDirect is true/false), but given the schema's thorough parameter documentation, this is a minor omission.
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?
With 100% schema description coverage, the input schema already documents all 8 parameters thoroughly. The description adds minimal parameter semantics beyond the schema - it mentions 'monitors, windows by title/process' which aligns with parameters but doesn't provide additional context. This meets the baseline of 3 when schema coverage is high.
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 ('capture'), target ('screenshot'), and context ('for WSL'). It distinguishes itself from the only sibling tool 'read_clipboard' by focusing on image capture rather than clipboard operations. The description includes key capabilities like capturing monitors/windows and direct image return with compression.
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 clear context about when to use this tool ('smart screenshot capture for WSL') and implies usage scenarios through its feature list. However, it doesn't explicitly state when NOT to use it or mention alternatives to this specific screenshot tool. The sibling tool 'read_clipboard' is unrelated, so no explicit comparison is needed.
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. Dates show when Glama detected each change.
read_clipboardtake_screenshotThe two tools have completely distinct purposes: one reads clipboard content (text or image), while the other captures screenshots. There is no overlap in functionality, making it impossible to confuse them.
Both tools follow a consistent verb_noun naming pattern: 'read_clipboard' and 'take_screenshot'. The naming is clear, predictable, and uses the same convention throughout.
With only two tools, the server feels thin for a general-purpose utility server. While the tools are specific to clipboard and screenshot operations, the scope is limited, and more complementary tools (e.g., for image processing or file management) might be expected.
For a clipboard and screenshot utility, basic read/capture operations are covered, but there are notable gaps. For example, there is no tool to write to the clipboard, edit screenshots, or manage captured images, which could limit agent workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Generate images, GIFs, and PDFs from HTML, URLs, or templates — from your AI agent.
Screenshot any URL/HTML as PNG/JPEG/WebP, or read it as clean Markdown/text for LLMs.
Eyes and hands on real Windows PCs — observe, click, type via Glasswarp API.
OCR, transcription, file extraction, and image generation for AI agents via MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/peterparker57/WSLSnapit-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
