Skip to main content
Glama
vkmtx

veil-mcp

by vkmtx

Run shell command (agent-native)

sh_run

Execute shell commands with structured output: exit code, duration, git diff, and condensed stdout/stderr. Full output stored for on-demand retrieval, reducing token usage.

Instructions

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cwdNoWorking directory. Defaults to the server's cwd.
fullNoIf true, return full stdout/stderr inline (skip condensing).
traceNoCapture a structured FS/syscall trace (Linux strace). Surfaces a read/write summary; full trace via sh_detail selector=trace. Best-effort: if no tracer is available the command still runs and trace_unavailable is set.
expectNoPost-conditions verified after the command, so you need no second command to confirm it worked.
commandYesThe shell command to execute.
previewNoDry-run in a disposable CoW clone of cwd: the command runs INSIDE the clone, you get the cwd-relative file diff, and the real cwd is never touched (nothing is promoted). Honest scope: absolute-path / parent-dir / network effects are NOT captured and may happen for real — this is NOT a sandbox (combine with sandbox:true for containment). Refuses if cwd can't be cloned.
retriesNoRetry up to N times on failure (default 0).
sandboxNoRun under a real OS sandbox (macOS sandbox-exec / Linux bubblewrap): file writes confined to cwd + temp. Pass {network:false} to deny network, {writable:[...]} for extra writable paths, {protect_secrets:true} or {deny_read:[...]} to BLOCK READS of configured secret dirs (scoped — blocks the listed paths, NOT a proof against all exfiltration). REFUSES to run (does not execute unconfined) if a sandbox is unavailable.
no_storeNoKeep this run MEMORY-ONLY: the record is cached for sh_detail this session but is NOT written to disk. Use for a sensitive run whose output should not persist. Result carries stored:"memory-only" so you know sh_detail works now but nothing was persisted.
scrub_envNoStrip credential-shaped vars (SECRET/TOKEN/PASSWORD/KEY/… see SECRET_ENV_PATTERNS) from the command's environment so a child can't read them. Auto-enabled whenever the sandbox requests protect_secrets or deny_read — masking ~/.ssh while leaving tokens in $env would be inconsistent. Surfaces secrets_env_scrubbed (a COUNT; values are never echoed).
backgroundNoRun as a LONG-RUNNING background process (dev server, --watch build): returns IMMEDIATELY with { id, pid, status:"running" } instead of blocking until exit. Poll its output with sh_logs id=<id> (pass the returned cursor to tail only new lines); stop it with sh_kill id=<id>. No stdin/TTY. Incompatible with options that require completion (expect, preview, trace, retries, full, timeout_ms) — those are refused. Keeps cwd, sandbox, scrub_env, no_store.
backoff_msNoFixed delay between retries in ms.
timeout_msNoOverride per-command timeout in ms (0-config default applies otherwise).
retry_on_exitNoOnly retry when exit code is in this set; omit = retry on any nonzero.
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully bears the transparency burden. It details output truncation, storage via sh_detail, sandbox behavior, secret scrubbing, preview limitations, and background mode incompatibilities, leaving no major behavioral unknowns.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is information-dense and front-loads the core purpose. While slightly lengthy, every sentence adds value. Minor redundancy (e.g., mentioning sh_detail twice) could be trimmed, but overall structure is clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (14 parameters, nested objects, no output schema), the description covers all essential aspects: command execution, output handling, safety features, edge cases (refusal to run without sandbox), and compatibility notes. No critical gaps remain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Despite 100% schema description coverage, the description adds significant context beyond parameter names and simple descriptions. It explains trade-offs (e.g., preview vs sandbox, scrub_env auto-enable, background restrictions), retry logic with retry_on_exit, and expect post-conditions, providing richer semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool executes a shell command and returns a quiet, structured result. It distinguishes itself from raw Bash calls and references sibling tools like sh_detail for output retrieval.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly advises when to prefer this tool over raw Bash (when effects or verbose output matter) and points to sh_detail for full output. It also hints at when not to use it (e.g., for long-running processes, use background instead).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/vkmtx/veil-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server