sift
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SIFT_MASK | No | Set to 0 to disable masking of credentials before sending to the model. | 1 |
| SIFT_CACHE | No | Set to 0 to re-ask the model even for previously seen text. | 1 |
| SIFT_EFFORT | No | Set to 'low' to ask the model to think less (faster but can lose important lines). | |
| SIFT_MODELS | No | Comma-separated list of model names to use with SIFT_BASE_URL, best first. | |
| SIFT_API_KEY | No | Your NVIDIA API key. Alternative to NVIDIA_API_KEY. | |
| SIFT_BASE_URL | No | Base URL of an OpenAI-compatible API endpoint (e.g., http://localhost:11434/v1). When set, no API key is required. | |
| SIFT_NO_MODEL | No | Set to 1 to run without using any model (uses deterministic fallback). | |
| SIFT_PATIENCE | No | Set to 1 to wait longer for a busy endpoint to respond. | 0 |
| NVIDIA_API_KEY | No | Your NVIDIA API key. Alternative to SIFT_API_KEY. |
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 |
|---|---|
| runA | Run a shell command and return only the lines that mattered instead of all of its output. Every byte is kept on disk and never enters the conversation, so a 5,000-line test run costs a few dozen lines of context -- and goes on costing nothing on every later turn, because tool results are re-sent with the rest of the transcript. The lines shown are the command's own, byte for byte; each gap states how many lines it stands for, and |
| followA | Return what a background command has printed since the last time you asked, and nothing you have already been shown. Use it with the handle from a |
| outlineA | Return what a file declares -- its types, functions, exports, targets and settings -- without their bodies, so that reading a 2,000-line source file costs a page. This is the machine behind |
| digestB | Read a file and return a distilled view of what is in it instead of its text. This is for anything already written down that would flood the conversation if opened whole: a log, a saved build or CI transcript, a test report, a crash dump, a long JSON export. The server opens the file, so its contents never enter the conversation -- a 40,000-line log costs a screenful -- and every line shown is the file's own, byte for byte, with |
| toolC | Run one of three dense tools and return a distilled view of what it printed: |
| digest_manyA | Digest several files in one call, asked at the same time. Use it whenever there is more than one file to read: four logs cost four waits asked one by one and roughly one wait asked together, and come back as one tool result instead of four. Each file keeps its own last line saying which it is, and a file that cannot be read says so in its place rather than taking the others down with it. |
| peekA | Return the exact original lines of a capture or a file, byte for byte, with the line numbers they had there. Use it with the handle at the end of a |
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
Each tool has a distinct role — execute, follow background output, outline declarations, distill file contents, batch-digest, and peek into gaps — and the descriptions explicitly cross-reference one another to prevent confusion. The boundary between `run` and `tool` is subtle since both execute commands and distill output, and `digest`/`outline` share the same distill-then-peek pattern, which is why this isn't a perfect 5.
Six tools use crisp, lowercase imperative verbs (run, follow, outline, digest, peek) with `digest_many` as a readable compound variant. `tool` breaks the pattern as a generic noun instead of a verb, which is the only real inconsistency.
Seven tools sits squarely in the ideal 3–15 range for a focused output-distillation server. Each tool adds distinct capability — `digest_many` covers batching, `tool` covers specialized analyzers — so none feels redundant.
The set covers the full inspection lifecycle: execute (`run`), monitor and control background work (`follow` with wait/stop/everything), summarize files (`digest`/`outline`/`digest_many`), and retrieve exact bytes (`peek` with grep support). Every view leads back to the source via `peek`, so there are no dead ends or missing core operations.