ephemeral-buffer
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 | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| preflight_commandA | Return content-free path and executable diagnostics without running This resolves the working directory, symlink target, detectable Git repository root, and first executable token. Shell expansion, aliases, pipelines, redirections, environment changes, and arbitrary shell logic cannot be verified here. The requested command is never executed. |
| start_executionA | Run a sequential, durably checkpointed set of command phases. Each phase is an object with |
| resume_executionA | Resume an execution from its first incomplete phase. Completed phases are skipped. Failed and timed-out phases require
|
| get_executionB | Return durable phase metadata and event history for one execution. |
| get_execution_outputA | Retrieve one bounded output chunk for all phases or one named phase. |
| list_executionsA | List durable executions with compact partial/completion summaries. |
| capture_textA | Ingest already-collected text and return capture metadata. Use this when the caller already has output to index. For a noisy or
potentially long command, use |
| capture_fileA | Reads a file or log output from disk and ingests it into the ephemeral
search index. Returns a compact versioned JSON summary and preserves
optional named metrics in Validate the intended file path before calling: resolve symlinks when path
identity matters, confirm the file belongs to the expected workspace, and
use an explicit bounded |
| execute_and_captureA | Runs a shell command, captures stdout/stderr, indexes it, and returns a compact versioned JSON summary without flooding the prompt context with thousands of lines. The summary includes status, duration, sizes, approximate token counts, truncation, signals, and optional named metrics. Use this for noisy tests, builds, logs, and other output that benefits from
bounded capture and later search. Direct command execution is usually
faster for a small, targeted inspection; use capture once output may be
noisy, large, or uncertain. This is an advisory routing heuristic, not an
enforced threshold. Before running, verify the
command, intended repository, and working directory: an omitted Args: command: Shell command line to execute. cwd: Optional working directory for command execution; pass an explicit validated path for repository-sensitive commands. label: Optional human-readable description/label for this capture. content_type: Content type hint - 'auto' (default, detects diff/log/text), 'diff', 'log', or 'text'. max_output_bytes: Maximum command output retained (default: configured buffer byte limit). timeout_seconds: Optional maximum runtime; timed-out commands return exit code 124. |
| consolidate_capturesB | Create one bounded, searchable JSON capture from multiple captures. The consolidated capture keeps source capture IDs and source line numbers. If records do not fit, the complete source captures remain available through their original IDs until normal LRU eviction. The operation fails if the consolidated capture cannot be admitted while retaining those sources. |
| search_captureA | Searches the captured command output using BM25, Semantic embedding, or Hybrid (RRF) ranking. Semantic prefetch is on by default. Hybrid search waits at most the configured semantic wait budget for an active index job and may return BM25 results marked pending while that job continues. Semantic indexing is bounded by a per-capture input-byte budget and token-budgeted inference batches. Captures over the input budget use immediate BM25 fallback for semantic and hybrid searches; semantic mode waits for indexing unless the capture exceeds that budget. Args: query: Search keywords or natural language question (e.g. 'auth failure', 'ECONNREFUSED', 'why did the build fail?'). mode: Search mode - 'hybrid' (recommended, lexically weighted BM25 + Semantic), 'bm25' (keyword terms), or 'semantic' (vector concepts). capture_id: The capture ID to query (defaults to 'latest'). top_k: Number of matching snippets to return (default: 5). context_lines: Number of surrounding lines of context to include with each match (default: 3; must be non-negative). |
| get_capture_sliceA | Fetches an exact range of lines (1-indexed) from a capture to inspect full context around a match. |
| get_capture_summaryA | Returns a compact versioned JSON summary. Set |
| list_capturesA | Lists all captures currently retained in the ephemeral ring buffer. |
| clear_capturesA | Clears all or a specific capture from the ephemeral buffer to free memory. |
| get_buffer_statsB | Returns aggregate capture, accounting, prefetch, and process RSS metrics. |
| get_runtime_diagnosticsA | Returns opt-in runtime metadata without exposing captured content. |
| get_usage_metricsC | Return content-free usage metrics, optionally since a snapshot token. |
| set_semantic_index_budgetC | Adjust this session's semantic-index chunk budget when explicitly enabled. |
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 19 tools
Most tools target clearly different resources or actions: capture ingestion, capture search, durable execution lifecycle, and diagnostics are separable. Some boundaries are softer, especially execute_and_capture versus start_execution and the family of stats/diagnostics/usage tools, but descriptions generally help distinguish them.
Tool names consistently use snake_case and mostly follow a predictable verb_noun pattern, such as search_capture, get_execution, list_captures, and clear_captures. The few compound or longer names remain readable and do not break the overall convention.
At 19 tools, the surface is heavy for an ephemeral buffer server and includes several utility/diagnostic tools that could feel like surface-area expansion. Most tools are purposeful, but the count sits in the borderline 16-25 range where scoping can become harder to manage.
The server covers the core capture lifecycle well: ingestion, search, slice/summary retrieval, listing, clearing, consolidation, and execution start/resume/read operations. Minor gaps remain, such as explicit execution cancellation/deletion or broader cross-execution querying, but agents can work around them.