Skip to main content
Glama
vkmtx

veil-mcp

by vkmtx

Run shell command (agent-native)

sh_run

Run shell commands with structured output including exit code, duration, and file changes. Supports post-condition verification and sandboxing.

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
commandYesThe shell command to execute.
cwdNoWorking directory. Defaults to the server's cwd.
fullNoIf true, return full stdout/stderr inline (skip condensing).
timeout_msNoOverride per-command timeout in ms (0-config default applies otherwise).
expectNoPost-conditions verified after the command, so you need no second command to confirm it worked.
retriesNoRetry up to N times on failure (default 0).
retry_on_exitNoOnly retry when exit code is in this set; omit = retry on any nonzero.
backoff_msNoFixed delay between retries in ms.
sandboxNoRun under a real OS sandbox (macOS sandbox-exec): file writes confined to cwd + temp. Pass {network:false} to also deny network, {writable:[...]} for extra writable paths. REFUSES to run (does not execute unconfined) if a sandbox is unavailable.
traceNoCapture a structured FS/syscall trace (feature A; 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.
Behavior5/5

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

Without annotations, the description carries full burden and discloses key behaviors: structured return, token-aware condensing, separate storage, sandbox confinement with refusal if unavailable, trace capturing, retries, and expect verification. All major behaviors are transparently described.

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

Conciseness5/5

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

The description is front-loaded with the key action and result, lists essential features concisely, and includes usage guidance in a single paragraph. Every sentence serves a purpose with no wasted words.

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

Completeness4/5

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

For a complex tool with 10 parameters, nested objects, and no output schema, the description provides solid overall understanding. It covers behavior, output structure, and related tools. However, it could briefly mention the return format is a JSON object to fully aid comprehension.

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

Parameters3/5

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

Schema description coverage is 100%, so baseline is 3. The description does not add new parameter-specific details beyond the schema; it sets context for the overall tool but does not enhance individual parameter understanding.

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 structured result including exit code, duration, git diff, and token-aware output. It distinguishes itself from raw Bash calls and mentions storage via sh_detail, providing a specific verb-resource pairing.

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

Usage Guidelines4/5

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

The description explicitly says 'Prefer this over a raw Bash call when you care about effects or output is likely verbose,' giving clear guidance on when to use it. It also references sh_detail for full output access, but does not list situations where this tool is not appropriate beyond that preference statement.

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