Versión en ruso abajo / Russian version below
Un pequeño servidor de Protocolo de Contexto de Modelo (MCP) que le da a un LLM ojos en tu escritorio sin consumir contexto. Puede tomar capturas de pantalla únicas, recortar una región alrededor del cursor del ratón y ejecutar sesiones de transmisión temporizadas que guardan fotogramas en el disco y solo devuelven los bytes de la imagen cuando se solicitan explícitamente.
La mayoría de los flujos de trabajo de LLM que necesitan "mirar la pantalla" hacen una de estas dos cosas:
Sueltan un PNG de resolución completa en el contexto del modelo en cada llamada, lo que consume tokens rápidamente y ralentiza la conversación.
Ejecutan una canalización de visión separada que el modelo no puede consultar directamente.
Este servidor toma un camino intermedio. Las capturas se guardan en el disco; las herramientas MCP devuelven pequeños blobs de metadatos (filePath, bytes, dimensiones, información del cursor) además de la imagen solo cuando solicitas includeBase64=true o llamas a stream_latest. Las sesiones de transmisión mantienen un anillo limitado de fotogramas recientes en la memoria, por lo que una sesión de captura de 5 minutos a 1 fps tampoco agota la memoria.
También expone la posición del cursor del ratón y el título de la ventana bajo el cursor, para que el modelo pueda fundamentar su análisis ("estás mirando la ventana titulada X en la parte superior derecha de la pantalla") sin tener que adivinar.
Related MCP server: Webcam MCP
Herramienta | Qué hace |
| Captura única. Recorte opcional de la región del cursor, formato, calidad, redimensionamiento. |
| Coordenadas del cursor + ventana en primer plano + ventana directamente bajo el cursor. |
| Inicia una captura periódica temporizada (intervalo + duración). |
| Instantánea de una sesión: recuento de fotogramas, tiempo restante, fotogramas recientes. |
| Lee el fotograma más reciente del disco y lo devuelve como base64. |
| Detiene una sesión en ejecución antes de tiempo. Los fotogramas ya en el disco se conservan. |
| Lista todas las sesiones conocidas. |
| Olvida una sesión finalizada (libera su anillo en memoria). |
Los valores predeterminados están ajustados para la legibilidad en monitores 4K:
Capturas de pantalla únicas — JPEG, calidad 82, borde más largo 2400px.
Transmisiones — JPEG, calidad 72, borde más largo 1920px.
Cuando cursorRadius>0, el recorte del cursor se mantiene en resolución nativa (sin redimensionar) a menos que sobrescribas maxEdge explícitamente.
Pasa maxEdge: 0 para deshabilitar el redimensionamiento por completo; pasa cualquier valor positivo para sobrescribir.
git clone https://github.com/beekamai/mcp-screenshot.git
cd mcp-screenshot
npm install
npm run buildConéctalo a cualquier cliente compatible con MCP apuntándolo a node dist/index.js a través de stdio. La mayoría de los clientes basados en CLI tienen un subcomando mcp add:
your-mcp-client mcp add screenshot --scope user -- node /absolute/path/to/mcp-screenshot/dist/index.jsWindows: utiliza System.Drawing a través de PowerShell. No se incluyen binarios nativos. Tanto el sondeo del cursor como la captura de pantalla funcionan sin derechos de administrador. La selección de múltiples monitores es compatible a través del argumento display (0 = primer monitor, omitir = pantalla virtual completa).
macOS / Linux: la captura recurre a screenshot-desktop si está instalado. El sondeo del cursor actualmente solo informa x = -1, y = -1 fuera de Windows; las contribuciones son bienvenidas.
Todo es local. El servidor se ejecuta como un proceso stdio, las capturas se guardan en ./captures/ junto al paquete de forma predeterminada, y no se envía nada a través de la red a menos que tu cliente MCP transporte los bytes. Elimina el directorio captures/ cuando hayas terminado.
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.
v0.1.0cursor_infoscreenshotstream_dropstream_lateststream_liststream_startstream_statusstream_stopScored across 8 tools
Each 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.
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…
