veil-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| VEIL_EFFECTS | No | compute the git effect-diff (set 0 to skip in huge repos) | true |
| VEIL_HEAD_LINES | No | lines kept from the top when condensing | 20 |
| VEIL_TAIL_LINES | No | lines kept from the bottom when condensing | 20 |
| VEIL_TIMEOUT_MS | No | default per-command timeout (0 = none) | 120000 |
| VEIL_MAX_RECORDS | No | max addressable run records (oldest evicted) | 500 |
| VEIL_MAX_LINE_CHARS | No | max chars of any single inline line (longer → capped with a pointer) | 1000 |
| VEIL_INLINE_MAX_LINES | No | stdout shorter than this (lines) is returned whole | 45 |
| VEIL_MAX_STREAM_BYTES | No | max bytes stored per stream (older dropped) | 5000000 |
| VEIL_STDERR_INLINE_ON_FAIL | No | on failure, show up to this many stderr lines inline | 60 |
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": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| sh_run | Execute a shell command and return a QUIET, STRUCTURED result: exit code, duration, files changed (git diff), and a token-aware view of stdout/stderr (full on small/failure, head+tail otherwise). Full output is stored and addressable via sh_detail — it is NOT re-emitted into context. Prefer this over a raw Bash call when you care about effects or output is likely verbose. Pass scrub_env:true to strip credential-shaped env vars from the child (auto-on with sandbox protect_secrets/deny_read); no_store:true keeps a sensitive run memory-only. |
| sh_detailA | Retrieve full stored output for a previous sh_run by id WITHOUT re-running it (the addressable output store). Use after a condensed result hid lines you need. |
| sh_plan | Statically predict what a command WOULD do without running it: blast-radius category (read-only | mutating | destructive | network | complex | unknown), whether it's reversible, and predicted file mutations. Use before destructive or unfamiliar commands. Does NOT execute anything. |
| sh_checkpointA | Snapshot a working directory under a label so you can restore it later with sh_restore. Excludes .git and node_modules. Take one before a risky or irreversible change. |
| sh_restore | Mirror a directory back to a previous sh_checkpoint (files created since the checkpoint are removed). This is the rollback for an agent's mistakes. |
| sh_checkpoints | List existing checkpoint labels for a project directory (checkpoints are namespaced per directory). |
| sh_history | Aggregate PAST sh_run records for a command: observed exit/retry/duration/file-churn with explicit sample size (n) and recency window. DESCRIPTIVE only — it restates this local, capped, TTL-pruned store; it is NOT a prediction and makes NO causal claim. Read-only, runs nothing. Use to judge whether a command is historically slow/flaky in THIS project before running it. |
| sh_logsA | Read the output of a background run started with sh_run background:true, by id. Returns a QUIET, condensed view of stdout/stderr plus status (running/exited/killed), exit code, and running_ms. Pass back stdout_cursor/stderr_cursor (the values returned by the previous call) to get ONLY new output since last poll — ideal for tailing a dev server. A live process reads from its in-memory buffer; once it exits the SAME id resolves to the durable record. |
| sh_killA | Stop a background run started with sh_run background:true, by id. Signals the whole process group (so a dev server's children die too). SIGTERM (the default) escalates to SIGKILL after 2s if the process ignores it. Returns status:"terminating" — the signal was sent but the OS hasn't confirmed the process is dead yet; poll sh_logs to see it settle to exited/killed. Killing an id whose process has ALREADY exited is not an error — it returns already_exited (idempotent). |
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 4 tools
sh_detail and sh_logs both retrieve output for a run by id, so there is minor overlap after a background process exits. However, their primary purposes are clearly separated: full stored output vs. live/condensed tailing with status polling, and sh_checkpoint/sh_kill are unambiguous.
All tool names consistently use the sh_ prefix and snake_case, which is readable. But the suffixes mix nouns (detail, checkpoint, logs) and a verb (kill), so the set does not follow a predictable verb_noun pattern.
Four tools is a reasonable count for a focused helper set, and each tool has a distinct role. The count feels slightly low only because the set references core tools like sh_run and sh_restore that are not actually exposed here.
The descriptions repeatedly reference sh_run and sh_restore, but neither is available in this server, leaving obvious dead ends: an agent cannot create a run or restore a checkpoint. The exposed tools are useful helpers, but the surface is significantly incomplete for the domain it implies.