seshat
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SWAYSOCK | No | The Sway socket path to connect to for resolving output geometry. If not set, swaymsg uses its default socket. | |
| SESHAT_PIPER_MODEL | No | Path or name of the piper voice model to use for offline narration. If not set, edge-tts or a default piper voice may be used. |
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 |
|---|---|
| seshat_infoB | Inspect the recorder: active take, stream and recording directories, the streams that will be ingested, the capture outputs, and the binaries narration depends on. |
| recording_startA | Start recording an active output (or a region within it) into a silent artifact: H.264 MP4 by default, or AV1 WebM, or a constrained GIF fallback. Returns immediately; call recording_stop to finish, then poll recording_status until the phase is completed or failed. The pointer cursor is always included. Narration anchors come from the timeline streams ingested for this take, so the tool server that drives the demonstration has to publish one. |
| recording_statusB | Report the take lifecycle phase (idle, recording, stopping, processing, narrating, completed, failed) plus live progress or final artifact metadata. |
| recording_stopA | Gracefully stop the active recording and begin finalizing the requested artifact. Returns the stopping/processing state; poll recording_status for the final artifact path and metadata. |
| recording_timelineA | Return the take's monotonic event timeline: every event ingested from the take's timeline streams, filtered to the capture window, with a recording-relative t_ms, the emitting source, and a compact payload. Use event ids as narration anchors. A sidecar JSON copy is written next to the artifact on completion. |
| recording_voiceoverA | Attach a scripted narration track to a completed take: the caller supplies the prose, the server synthesizes speech, aligns segments to timeline anchors (or to an explicit at_ms), and muxes the audio over the existing video stream, optionally burning styled captions. Starts an async 'narrating' phase; poll recording_status. GIF cannot carry audio. |
| recording_scenesA | Optional, approximate fallback anchors for a completed take: ffmpeg scene-cut timestamps, with optional keyframe OCR via tesseract. Use when no timeline stream was published for the take; scene cuts are secondary evidence, never the sync source. |
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 7 tools
Tools cover distinct lifecycle stages and resources: start/stop/status are separate actions, timeline vs scenes are distinguished by primary vs fallback evidence, and voiceover is a distinct post-processing step. Minor potential overlap between seshat_info and recording_status over active-take state, but descriptions clarify their different scopes.
Six core tools consistently use recording_<noun> (start, stop, status, timeline, scenes, voiceover), which is predictable. The lone seshat_info breaks the prefix/pattern slightly, but the set remains readable.
Seven tools are well-scoped for a recording-and-narration server, covering lifecycle, inspection, timeline, fallback scenes, and voiceover without bloat. Each tool has a clear role.
The surface covers the core record→stop→status→narrate lifecycle plus timeline/scene anchors and environment inspection. Minor gaps such as no explicit cancel/pause or take-listing/deletion exist, but agents can work around them.