Skip to main content
Glama

screen-capture-mcp

npm version License: MIT

A quick and easy MCP server that gives Claude Code (or any MCP client) the ability to take screenshots of your screen or specific programs over any specified interval (e.g. "take a screenshot of Unreal Engine every 5 seconds for the next minute".) Useful when working on games, GUIs, or anything visual where Claude needs to see what you see.

Windows only — uses PowerShell and .NET for screen capture.

Why?

When you're working with Claude Code on something visual — a game, a UI, a 3D editor — Claude is blind. It can read your code but has no idea what the result actually looks like. You end up manually screenshotting, dragging images into the chat, and explaining what you're looking at.

This MCP server fixes that. Once installed, Claude can take screenshots on its own whenever it needs to see what's happening on screen.

Related MCP server: snip-mcp

Features

  • Full screen capture — captures your primary display

  • Window capture — capture a specific window by title (partial match)

  • Auto-resize — images are resized to 1280px wide to save tokens

  • Zero native dependencies — uses PowerShell/.NET built into Windows, no native compilation needed

Installation

npm install -g screen-capture-mcp

Then register it with Claude Code:

claude mcp add -s user -t stdio screen-capture-mcp -- screen-capture-mcp

Or add it manually to your ~/.claude.json:

{
  "mcpServers": {
    "screen-capture-mcp": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "screen-capture-mcp"]
    }
  }
}

From source

git clone https://github.com/kmoulder/screen-capture-mcp.git
cd screen-capture-mcp
npm install
npm run build
claude mcp add -s user -t stdio screen-capture-mcp -- node /path/to/screen-capture-mcp/dist/index.js

Restart Claude Code after registering.

Usage

Once registered, Claude Code can call the take_screenshot tool. You can ask for screenshots naturally:

"Take a screenshot"
"Take a screenshot of the Godot window"
"Show me what the game looks like right now"

Monitoring Over Time

Because Claude can call the tool repeatedly, you can ask it to watch your screen over time:

"Take a screenshot every 5 seconds for the next minute and describe what changes"
"Wait 30 seconds then take a screenshot"
"Watch the Unity window and let me know when the build finishes"
"Capture the game window every 10 seconds while I playtest — give me feedback on the UI"

This is especially useful for:

  • Playtesting feedback — run your game and get real-time observations from Claude as you play

  • Build monitoring — have Claude watch a long-running build or deployment and notify you when it's done

  • UI iteration — make changes in an editor and have Claude compare screenshots to track progress

  • Bug reproduction — ask Claude to capture screenshots while you reproduce a bug, then analyze the sequence

Bringing Visual Context Into Coding Tasks

You can also mix screenshots into normal development work:

"Look at the game window and then fix the player sprite so it faces the right direction"
"Take a screenshot of the editor, then update the CSS to match the mockup I have open"
"Check what the app looks like in the browser and fix any layout issues you see"

This closes the loop between writing code and seeing results — Claude can make a change, screenshot the result, and iterate.

Tool Schema

take_screenshot(window_title?: string)

Parameter

Type

Description

window_title

string (optional)

Window title to capture (partial match). Omit for full screen.

Returns a base64-encoded PNG image.

Privacy

Screenshots are captured and processed entirely on your local machine. Nothing is uploaded, saved to disk, or sent to any external service by this tool.

The captured image is:

  1. Taken locally via PowerShell/.NET

  2. Resized in-memory using sharp

  3. Passed directly to Claude Code via the MCP protocol as base64

No screenshots are written to your filesystem — they exist only in memory for the duration of the MCP tool call. The image data is sent to the Claude API as part of your conversation (the same as if you had dragged a screenshot into the chat yourself), but it is never stored or logged by this server.

If you want to verify this, the entire server is a single file — src/index.ts.

How It Works

  • Uses PowerShell with System.Drawing and System.Windows.Forms to capture the screen

  • For window-specific capture, uses user32.dll GetWindowRect via P/Invoke to find and capture the target window

  • Images are resized to 1280px wide using sharp before being returned to keep token usage reasonable

  • No temp files or disk writes — everything happens in memory

Requirements

  • Windows 10/11

  • Node.js 18+

  • PowerShell (included with Windows)

License

MIT

Available Tools

1 tool
take_screenshotA

Captures a screenshot of the primary display or a specific window. Returns the image as a PNG. If window_title is provided, captures only that window (partial title match). Otherwise captures the full screen.

ParametersJSON Schema
NameRequiredDescriptionDefault
window_titleNoOptional window title to capture (partial match). If omitted, captures the full primary screen.

TDQS

A4.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the burden. It discloses the basic behavior (captures primary display or window, returns PNG) but does not mention file size, permissions required, or whether it is a safe read-only operation. It adequately describes the core behavior without contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise—two sentences that front-load the main action ('Captures a screenshot...') and then clarify the optional parameter behavior. Every sentence is necessary and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with one optional parameter and no output schema or nested objects, the description is nearly complete. It could mention that the screenshot is of the primary display only (not multiple monitors) or specify resolution, but these are minor gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers the parameter fully (100% coverage). The description adds the important detail that window_title uses partial matching, which is not in the schema. This adds value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool captures a screenshot of the primary display or a specific window, and returns a PNG. It distinguishes between full-screen and window capture based on the optional parameter.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to provide window_title (to capture a specific window) and when not (for full screen). No sibling tools exist, so no need for alternatives. It could be clearer on prerequisites or limitations, but it's adequate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 1 tool updatev1.0.1
    • First observedtake_screenshot

TDQS

A4.4/5.0
Disambiguation5/5

With only one tool, there is no risk of ambiguity or confusion. The tool's purpose is clearly defined.

Naming Consistency5/5

A single tool named 'take_screenshot' uses a clear verb_noun pattern, consistent with itself.

Tool Count5/5

One tool is entirely appropriate for a screen-capture server, covering the core functionality without unnecessary bloat.

Completeness4/5

The tool covers the primary use cases (full screen and window capture) but lacks features like region selection or format options, which are minor gaps.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/kmoulder/screen-capture-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server