Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

No arguments

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

CapabilityDetails
tools
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
recordA

Record the screen for a fixed duration and return a numbered, timestamped contact sheet (a grid of still frames) as an image. Use this to inspect motion: dragging, animations, flashes, reordering, anything that cannot be understood from a single screenshot. Raw frames are also saved to disk.

captureA

Capture a single screenshot immediately and return it as an image. Uses the same region-selection semantics as record.

start_recordingA

Begin an OPEN-ENDED recording that runs until stop_recording is called. Use this (instead of record) when the USER controls the timing — e.g. they will perform a drag, open a menu, or trigger an animation and you cannot predict how long it takes. Start it on the user's cue, tell them to perform the interaction, then call stop_recording. Only one recording may be active at a time.

stop_recordingA

Stop the recording started by start_recording and return the contact sheet (plus full-resolution frame paths), exactly like record. Errors if no recording is in progress.

list_windowsA

List visible windows (title, process, and geometry where available) so a target can be chosen for window capture.

get_frameA

Return a single frame from a prior recording at FULL RESOLUTION, as an image. The contact sheet from record is a downscaled overview; when it is too small to read fine detail or small text, call this with the recording's directory and the frame number (both are listed in the record response), or with a direct frame path. This works over MCP without filesystem access.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.1/5.0

Scored across 6 tools

Disambiguation5/5

Each tool targets a distinct action: one-shot screenshot (capture), window enumeration (list_windows), fixed-duration recording (record), open-ended recording (start_recording/stop_recording), and full-resolution frame retrieval (get_frame). The descriptions explicitly disambiguate the tricky record vs start_recording/stop_recording split by who controls timing, and get_frame vs capture by source (prior recording vs live screen).

Naming Consistency4/5

All names use snake_case and action-oriented verbs, and the recording lifecycle is a coherent start_recording/stop_recording pair. However, two tools (capture, record) are bare verbs rather than the verb_noun pattern used by list_windows, get_frame, and stop_recording, which is a minor deviation.

Tool Count5/5

Six tools is well-scoped for a screen capture/recording server, with each tool earning its place across the screenshot, window-listing, and recording-lifecycle workflows. No redundant or filler tools are present.

Completeness4/5

The surface covers live capture, window discovery, timed and open-ended recording, and high-res frame retrieval, forming a coherent lifecycle. Minor gaps exist: list_windows hints at window-targeted capture but no explicit window/region capture tool is exposed, and there is no explicit cancel/discard recording operation.

Maintenance

ActivityMaintained
ResponsivenessNo issues