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., "@mcp-screenshot take a screenshot of my active 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.
Русская версия ниже / Russian version below
A small Model Context Protocol (MCP) server that gives an LLM eyes on your desktop without burning context. It can take one-off screenshots, crop a region around the mouse cursor, and run timed streaming sessions that save frames to disk and only return image bytes when explicitly asked.
Most LLM workflows that need to "look at the screen" either:
Drop a full-resolution PNG into the model context every call — which eats tokens fast and slows the conversation.
Run a separate vision pipeline that the model can't directly query.
This server takes a middle road. Captures are persisted to disk; the MCP tools
return small metadata blobs (filePath, bytes, dimensions, cursor info)
plus the image only when you ask for includeBase64=true or call
stream_latest. Streaming sessions keep a bounded ring of recent frames in
memory so a 5-minute capture session at 1 fps doesn't blow memory either.
It also exposes the mouse cursor position and the title of the window under the cursor, so the model can ground its analysis ("you are looking at the window titled X at the top-right of the screen") without guessing.
Related MCP server: Webcam MCP
Tool | What it does |
| One-shot capture. Optional cursor-region crop, format, quality, resize. |
| Cursor coords + foreground window + window directly under the cursor. |
| Start a timed periodic capture (interval + duration). |
| Snapshot of a session: frame count, time remaining, recent frames. |
| Read the most recent frame from disk and return it as base64. |
| Stop a running session early. Frames already on disk are kept. |
| List all known sessions. |
| Forget a finished session (frees its in-memory ring). |
Defaults are tuned for legibility on 4K monitors:
Single screenshots — JPEG, quality 82, longest edge 2400px.
Streams — JPEG, quality 72, longest edge 1920px.
When cursorRadius>0 the cursor crop is kept at native resolution
(no resize) unless you override maxEdge explicitly.
Pass maxEdge: 0 to disable resizing entirely; pass any positive value
to override.
git clone https://github.com/beekamai/mcp-screenshot.git
cd mcp-screenshot
npm install
npm run buildWire it into any MCP-capable client by pointing it at node dist/index.js
over stdio. Most CLI-based clients have an mcp add subcommand:
your-mcp-client mcp add screenshot --scope user -- node /absolute/path/to/mcp-screenshot/dist/index.jsWindows: uses System.Drawing via PowerShell. No native binaries
shipped. Cursor probe and screen capture both work without admin rights.
Multi-monitor selection is supported via the display argument
(0 = first monitor, omit = full virtual screen).
macOS / Linux: capture falls back to screenshot-desktop if installed.
The cursor probe currently only reports x = -1, y = -1 outside of Windows;
contributions welcome.
Everything is local. The server runs as a stdio process, captures are saved
under ./captures/ next to the package by default, and nothing is sent over
the network unless your MCP client transports the bytes. Delete the
captures/ directory when you're done.
MIT.
Небольшой MCP-сервер, который даёт языковой модели возможность видеть рабочий стол, не съедая контекст. Он умеет делать одиночные скриншоты, вырезать область вокруг курсора и запускать сессии покадрового стриминга, которые пишут кадры на диск и возвращают пиксели только тогда, когда модель явно их запросила.
Стандартные подходы к "смотри на экран":
Передавать модели каждый раз PNG в полный размер — токены кончаются быстро, и диалог становится тормозным.
Использовать отдельный vision-конвейер, к которому модель не имеет прямого доступа.
Этот сервер идёт средним путём: каждый снимок сохраняется на диск, а MCP-тулы
возвращают компактный JSON (filePath, размер файла, разрешение,
информация о курсоре). Изображение приходит в ответе только если в screenshot
передан includeBase64=true или если позже вызван stream_latest. У стримов
есть ограниченное кольцо последних кадров в памяти, так что пятиминутная
сессия с частотой 1 fps не разнесёт RAM.
Дополнительно сервер сообщает координаты курсора и заголовок окна под ним — модель может опираться на это, не угадывая ("ты сейчас смотришь на окно X в правом верхнем углу").
Тул | Что делает |
| Одиночный снимок. Опционально — обрезка вокруг курсора, формат, качество. |
| Координаты курсора, активное окно и окно под курсором. |
| Запуск таймера с периодической съёмкой (интервал + длительность). |
| Снимок состояния сессии: число кадров, остаток времени, последние кадры. |
| Прочитать последний кадр с диска и вернуть base64. |
| Прервать сессию досрочно. Кадры на диске сохраняются. |
| Список всех сессий. |
| Забыть завершённую сессию (освобождает кольцо в памяти, файлы остаются). |
Дефолты подобраны под 4K-мониторы — текст на интерфейсах остаётся читаемым:
Одиночные снимки — JPEG, качество 82, длинная сторона 2400px.
Стримы — JPEG, качество 72, длинная сторона 1920px.
При cursorRadius>0 обрезка вокруг курсора сохраняется в нативном
разрешении (без ресайза), если явно не задан maxEdge.
maxEdge: 0 полностью отключает уменьшение, любое положительное значение —
переопределяет дефолт.
git clone https://github.com/beekamai/mcp-screenshot.git
cd mcp-screenshot
npm install
npm run buildПодключение к любому MCP-клиенту — указать запуск node dist/index.js
через stdio. У большинства CLI-клиентов есть подкоманда mcp add:
your-mcp-client mcp add screenshot --scope user -- node /абсолютный/путь/к/mcp-screenshot/dist/index.jsWindows: захват через System.Drawing (вызов из PowerShell), без
бандленных нативных бинарей. Курсорный пробник и скриншоты работают без
прав администратора. Мульти-мониторный выбор — параметр display
(0 — первый монитор, без аргумента — весь виртуальный экран).
macOS / Linux: захват — fallback на screenshot-desktop. Курсорный
пробник сейчас возвращает x = -1, y = -1 вне Windows; PR приветствуются.
Всё локально. Сервер крутится как stdio-процесс, кадры лежат в ./captures/
рядом с пакетом, ничего не уходит в сеть, пока ваш MCP-клиент сам не передаст
байты дальше. После работы — просто удалите каталог captures/.
MIT.
Return the current mouse cursor position, the foreground window title, and the title of the window directly under the cursor (Windows only; other platforms report position only when available).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses platform-dependent behavior and what data is returned. No annotations provided, so description carries full burden; it does so adequately.
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?
Single sentence with front-loaded main purpose and parenthetical details. No wasted words.
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?
Covers main functionality and platform constraints. Lacks explicit return format (e.g., coordinates as numbers), but tool is simple; no output schema but description is sufficient.
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?
No parameters exist; schema coverage is 100%. Description adds no param info but none needed. Baseline for 0 params is 4.
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?
Clearly states it returns mouse cursor position, foreground window title, and title under cursor. Includes platform-specific behavior. Distinct from sibling screenshot/stream tools.
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?
Provides platform constraints (Windows only for some fields; others report position only). Implicitly differentiates from siblings by describing unique functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture a single screenshot of the desktop. Persists the file to disk and optionally returns a base64 payload. Set cursorRadius>0 to crop a square region around the mouse cursor instead of the full screen.
| Name | Required | Description | Default |
|---|---|---|---|
| cursorRadius | No | If >0, crop a square of (2*radius)x(2*radius) px centered on the cursor. 0 = full screen. | |
| format | No | jpeg | |
| quality | No | ||
| maxEdge | No | Resize the longest edge to this many pixels. 0 disables resizing. Default 2400 for full screen; with cursorRadius>0 the cursor crop is kept at native resolution unless overridden. | |
| display | No | Optional display index for multi-monitor setups (omit for primary). | |
| includeBase64 | No | If true, include the image bytes inline in the response. Default true. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. It mentions file persistence to disk and optional base64 return, but omits details like file naming, overwrite policy, or permission requirements. The cropping behavior is well described, but the mutation side effects are under-specified.
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?
Three sentences with no waste. First sentence states main action, second adds persistence and base64, third adds cropping mode. Information is front-loaded and efficiently 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?
For a tool with 6 parameters, no output schema, and no annotations, the description covers core functionality but misses details like default file location, overwrite behavior, and output format specifics. It is minimally viable but incomplete for complex agents.
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 67% (4 of 6 params described). The description adds context for cursorRadius cropping and file persistence, but does not enhance understanding of format or quality parameters beyond schema. Baseline 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?
Description clearly states the action 'Capture a single screenshot' and the resource 'desktop'. It distinguishes from sibling stream tools by emphasizing 'single screenshot' vs continuous streaming, and from cursor_info by focusing on capture rather than info. Specific verb and resource.
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 when to use this tool (single screenshot) and contrasts with streaming via sibling names. However, it does not explicitly state when not to use or list alternatives, only hints via 'single' vs stream context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Forget a finished stream session (frees its in-memory ring; on-disk files are preserved).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses that the tool frees in-memory ring but preserves on-disk files, providing key behavioral context beyond the tool name.
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?
A single, front-loaded sentence with no wasted words, efficiently conveying the core purpose and behavioral nuance.
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?
While the tool is simple, the description omits important context such as the requirement that the session must be finished before calling this tool, and does not describe return values or error conditions.
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 sole parameter 'id' has no description in the schema (0% coverage) and the description does not elaborate on what 'id' refers to (e.g., session ID), failing to compensate for the low 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 action ('Forget a finished stream session') and resource ('in-memory ring'), distinguishing it from sibling tools like stream_start, stream_stop, and stream_list.
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 after a stream session is finished to free memory, but does not explicitly state when not to use or mention alternative tools for other actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the most recent frame of a stream from disk and return it as base64. Use sparingly - this is the path that actually puts pixels into the LLM context.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses a read operation from disk and warns about cost (pixels into context). However, it does not mention error conditions (e.g., nonexistent stream), authentication requirements, or the specific behavior of returning the latest frame. Adequate but not comprehensive.
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 sentences, front-loaded with the core action, followed by a succinct usage note. Every word adds value; no redundant or extraneous content.
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 simplicity (1 param, no output schema), the description covers the basic purpose and a cost warning. However, it omits prerequisites (e.g., active stream), error handling, or relationship to sibling tools (e.g., stream_start). Leaves some context gaps for an AI agent.
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 single parameter 'id' has no description in the schema (0% coverage). The description only adds 'of a stream', implying the stream identifier but not clarifying the format or how to obtain it. This is minimal improvement over the bare schema.
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 ('Read the most recent frame'), the resource ('of a stream'), and the output format ('return it as base64'). This differentiates from sibling tools like 'stream_list' (list streams) and 'screenshot' (capture screen), establishing a distinct purpose.
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 advice to 'Use sparingly' hints at cost or resource intensity but does not explicitly specify when to use this tool versus alternatives (e.g., screenshot, cursor_info). No direct comparison with siblings is provided, leaving usage context somewhat vague.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List active and completed stream sessions known to this process.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states it lists sessions without disclosing side effects, performance, or what 'known to this process' entails.
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?
Single sentence, 8 words, no fluff; every word is necessary and efficient.
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 output schema and sibling tools, description lacks details on return format or scope; leaves ambiguity about 'known to this process'.
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?
No parameters exist, so schema coverage is 100%; description needs no additional parameter info, but baseline for zero params is 4.
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?
Description uses specific verb 'List' and resource 'stream sessions', clearly distinguishing from sibling tools like stream_drop, stream_start, etc.
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?
Implied usage for listing sessions, but no explicit when-to-use or alternatives compared to siblings like stream_latest or stream_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a periodic capture session. Saves frames to disk every intervalSeconds for at most durationSeconds, keeping the last ringCapacity frames in memory. Returns a session id used by stream_status / stream_latest / stream_stop. Streams default to disk-only to keep LLM context lean - call stream_latest with includeBase64=true when you actually want to look at a frame.
| Name | Required | Description | Default |
|---|---|---|---|
| intervalSeconds | Yes | Seconds between frames. Minimum 0.25. | |
| durationSeconds | Yes | Total duration of the stream in seconds. | |
| cursorRadius | No | ||
| format | No | jpeg | |
| quality | No | ||
| maxEdge | No | Longest edge in px. Default 1920 for full-screen frames; cursor crops keep native resolution unless overridden. | |
| ringCapacity | No | Maximum number of recent frames kept in memory. Older frames are evicted (still on disk). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It discloses that frames are saved to disk, memory retains only ringCapacity frames, and streams default to disk-only. This adds moderate behavioral context, but lacks details on disk usage, permission requirements, or automatic stop conditions.
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 three sentences long, each serving a distinct purpose: stating the main action, detailing memory/disk behavior, and providing usage guidance. No extraneous words or 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?
Given the complexity of 7 parameters and no output schema, the description covers the core lifecycle, disk/memory behavior, and ties to sibling tools. It lacks explicit return value schema or error conditions, but is sufficiently complete for a start tool.
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 schema description coverage at 57%, the description adds some contextual meaning (e.g., explaining ringCapacity as memory retention) and clarifies the roles of intervalSeconds and durationSeconds. However, it does not elaborate on cursorRadius, format, quality, or maxEdge beyond what the schema already states. The baseline 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 specifies a clear verb ('Start'), resource ('periodic capture session'), and critical details: saves frames to disk, keeps recent frames in memory, returns a session ID. It distinguishes from sibling tools by naming the related tools (stream_status, stream_latest, stream_stop) and how they interact.
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?
Provides clear context for use: stream_start initiates capture, and it mentions that stream_latest with includeBase64=true should be called when actually viewing a frame. This helps agents decide when to use stream_latest vs relying on disk-only behavior. However, it does not explicitly state when not to use stream_start or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Snapshot of a running or finished stream session - frame count, time remaining, last frames metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| lastN | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behavioral traits: it gives a snapshot of running or finished sessions, includes frame count, time remaining, and last frames metadata. However, it does not state if it is read-only or what happens if the session does not exist.
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 (14 words) that immediately conveys the tool's purpose and key output items. No unnecessary words.
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 two parameters (one optional) and no output schema, the description should clarify how parameters affect output and describe the return format. It only lists output attributes without detail on structure or behavior.
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 coverage is 0% and the description does not explain the 'id' or 'lastN' parameters. The agent must infer their meaning from names alone, which is insufficient.
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 provides a snapshot of a stream session with frame count, time remaining, and last frames metadata. It distinguishes from siblings like stream_latest (which likely gives only latest frames) and stream_list (which lists sessions).
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?
No guidance on when to use this tool versus alternatives such as stream_latest or stream_status. The description does not mention explicitly that this is for overall status rather than just the latest frames.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop a running stream early. Frames already on disk remain.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that frames remain on disk, but with no annotations, it lacks details on side effects (e.g., resource cleanup), reversibility, or error states. It covers the core behavior minimally.
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 short sentences, front-loaded with the primary action and a key behavioral note. No redundancy or extraneous content.
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 output schema or annotations, the description is adequate for a simple stop operation but lacks details on return values, error handling, and state prerequisites, which would help 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 only parameter 'id' has no description in the schema (0% coverage), and the description does not elaborate on its meaning (e.g., stream ID) or expected format, leaving the agent to infer.
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 specifies the action ('Stop a running stream early') and distinguishes from sibling tools like stream_start, stream_status, and stream_drop by focusing on early termination and noting that frames are preserved.
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 early stopping but does not provide explicit guidance on when to use this versus alternatives (e.g., stream_drop for removing frames) or mention prerequisites like the stream must be running.
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.
v0.1.0cursor_infoscreenshotstream_dropstream_lateststream_liststream_startstream_statusstream_stopEach tool has a clearly distinct role: cursor info, single screenshot, and streaming session management. The streaming tools are all prefixed with 'stream_' and have specific verbs (start, stop, status, etc.), avoiding any overlap with each other or with the non-streaming tools.
The naming is mostly consistent: streaming tools follow a clear 'stream_<verb>' pattern, and 'cursor_info' uses snake_case for a compound name. However, 'screenshot' as a single verb stands out, and the pattern varies slightly (noun_info vs. verb). Overall predictable, with minor deviations.
With 8 tools, the server provides a well-scoped set for screenshot capture: one-off capture, cursor info, and a full streaming lifecycle. The count is neither too high nor too low, fitting the domain nicely.
The tool set covers all major operations: capture a single screenshot, start a stream, monitor its status, retrieve frames, stop early, and clean up memory. There are no obvious gaps for the stated purpose of taking screenshots and streaming screen content.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
MCP server for visual regression testing: triage a PR's UI diffs from your coding agent.
MCP server for Clipkit — gives AI agents a video toolbox via the Clipkit schema.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to control Unreal E…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/beekamai/mcp-screenshot'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
