Marey
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
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
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| 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 |
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 6 tools
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).
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.
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.
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.