Screen MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DISPLAY | No | Display environment variable available to the server process, required by mss on Linux for X11 sessions | |
| XAUTHORITY | No | X11 authority file path for X11 sessions | |
| WAYLAND_DISPLAY | No | Wayland display environment variable for Wayland sessions | |
| XDG_RUNTIME_DIR | No | Runtime directory for user-specific non-essential runtime files | |
| SCREEN_MCP_CAPTURE_RESPONSE_MODE | No | Response mode for capture_screenshot tool when using auto mode: base64 or image |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_monitorsA | List available monitors. Use this first when the caller does not know which monitor index to target.
|
| capture_screenshotA | Capture one screenshot in a single call. Prefer this tool for small/medium payloads when a one-shot response is desired.
For larger payloads or robust transport, use the session flow:
Args: monitor_index: 0 captures the virtual full desktop, 1..N capture a specific monitor. image_format: png or jpeg. max_width: optional resize target width while preserving aspect ratio. quality: JPEG quality in [1, 100]. Ignored for PNG. response_mode: 'base64' (default), 'image' (native MCP image block), or 'auto' (resolved from SCREEN_MCP_CAPTURE_RESPONSE_MODE env var). |
| capture_timelineA | Capture a timeline in a single call. Prefer this tool for short timelines when a one-shot JSON payload is acceptable.
For larger timeline payloads or safer transport, use the session flow:
|
| start_timeline_captureA | Capture a timeline and store it in a temporary chunked session. Use this as step 1 of the chunked timeline flow.
Next calls should be: |
| get_timeline_manifestA | Return timeline session metadata without the full payload. Use this as step 2 after |
| get_timeline_chunkA | Return one JSON text chunk for a timeline session. Use this after |
| release_timeline_captureA | Release a timeline session and free memory. Call this after reading all required chunks. |
| start_screenshot_captureA | Capture a screenshot and store it in a temporary server-side session. Use this as step 1 of the chunked screenshot flow.
Next calls should be: |
| get_screenshot_manifestA | Return screenshot session metadata and an ASCII preview. Use this as step 2 after |
| get_screenshot_chunkB | Return one base64 chunk for a screenshot session. Fetch chunks from |
| release_screenshot_captureA | Release a screenshot session and free memory. Call this after reading all required chunks. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 11 tools
Every tool has a clearly distinct purpose with no ambiguity. The screenshot and timeline tools are cleanly separated into one-shot and session-based variants, and the session flow tools (start/get/release) are clearly differentiated by their specific roles in the capture process. The list_monitors tool serves a unique discovery function.
The tool names follow a perfectly consistent verb_noun pattern throughout. All screenshot tools use 'screenshot' and all timeline tools use 'timeline' with consistent prefixes (capture_, start_, get_, release_). The pattern is maintained across all 11 tools with no deviations.
The 11 tools are well-scoped for a screen capture server. They provide complete coverage for both screenshot and timeline capture with both one-shot and session-based approaches, plus monitor discovery and session management. Each tool earns its place without redundancy or bloat.
The tool surface provides complete coverage for screen capture operations. It supports both screenshots and timelines, offers both simple one-shot and robust chunked transport methods, includes session lifecycle management (start/get/release), and provides monitor discovery. No obvious gaps exist for the stated domain.