Skip to main content
Glama
vkmtx

veil-mcp

by vkmtx

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
VEIL_EFFECTSNocompute the git effect-diff (set 0 to skip in huge repos)true
VEIL_HEAD_LINESNolines kept from the top when condensing20
VEIL_TAIL_LINESNolines kept from the bottom when condensing20
VEIL_TIMEOUT_MSNodefault per-command timeout (0 = none)120000
VEIL_MAX_RECORDSNomax addressable run records (oldest evicted)500
VEIL_MAX_LINE_CHARSNomax chars of any single inline line (longer → capped with a pointer)1000
VEIL_INLINE_MAX_LINESNostdout shorter than this (lines) is returned whole45
VEIL_MAX_STREAM_BYTESNomax bytes stored per stream (older dropped)5000000
VEIL_STDERR_INLINE_ON_FAILNoon failure, show up to this many stderr lines inline60

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

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
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

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.8/5.0

Scored across 4 tools

Disambiguation4/5

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.

Naming Consistency3/5

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.

Tool Count4/5

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.

Completeness2/5

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.

Maintenance

ActivitySlowing
ResponsivenessUnresponsive