Skip to main content
Glama

sassy_shell

Execute shell commands in the host's native shell, with tunable timeouts and safeguards against destructive actions.

Instructions

Execute a shell command in the host's native shell.

shell: Windows -> powershell (default), cmd, wsl. macOS/Linux -> zsh/bash (default is the login shell), sh. Leave empty to use the host default. Automatically normalizes syntax (e.g. && to ; for PowerShell); POSIX shells run the command verbatim.

timeout_seconds > 120: auto-promoted to a background session and returns a JSON handle ({"auto_detached": true, "session_name": ...}). Poll with sassy_session_read; stop with sassy_session_stop. This is because synchronous waits past the MCP client's ~240s response wall wedge the connection. For known long-running work, prefer calling sassy_session_start directly with a memorable name.

allow_pattern: opt-in escape hatch for power users. When set to a specific pattern label (e.g. 'truncate-by-redirect') OR to '*', a regex-pattern match with that label is allowed to execute instead of being blocked. The bypass is recorded as a 'pattern_bypass' audit entry. Keyword matches (rm/del/remove-item) are NEVER affected by this flag — only regex patterns can be opted out, and only one pattern at a time.

Tiered destructive-action handling: when interceptor.destructiveAction = "confirm" (config), MEDIUM- and HIGH-tier pattern matches return a confirmation_required JSON payload with a single-use token instead of hard-blocking. Call sassy_shell_confirm(token) (HIGH tier also requires a typed phrase) to actually run the command. LOW-tier matches always run after a log entry. The default action remains "block".

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
shellNo
commandYes
allow_patternNo
timeout_secondsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

With no annotations provided, the description carries the full burden—and it excels. It discloses shell selection logic, syntax normalization, timeout auto-detachment, the allow_pattern escape hatch with audit logging, and the tiered destructive-action handling with confirmation tokens. No contradictions with any structured fields.

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 lengthy but each paragraph targets a distinct behavioral aspect (shell selection, timeouts, allow_pattern, destructive actions). It is front-loaded with the core purpose. Slightly dense, but every sentence adds value; no filler or redundancy.

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 (shell execution, background sessions, safety mechanisms) and the presence of an output schema, the description covers all critical operational details: return formats (JSON handle, confirmation payload), interaction with session tools, audit behavior, and tiered blocking rules. It leaves little to guesswork.

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?

Schema description coverage is 0%, so the description must compensate—and it does thoroughly. It explains 'shell' with platform-specific defaults, 'timeout_seconds' with the >120 behavior, 'allow_pattern' with pattern label semantics, and 'command' implicitly by context. Every parameter receives meaningful, non-obvious context beyond the schema.

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 opens with a specific verb and resource: 'Execute a shell command in the host's native shell.' It clearly distinguishes itself from sibling tools by explaining how it relates to session tools (sassy_session_read/stop/start) and the confirm tool (sassy_shell_confirm), making its unique role evident.

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 provides explicit guidance on when to use this tool versus alternatives: 'For known long-running work, prefer calling sassy_session_start directly with a memorable name.' It also explains the auto-detach behavior and when synchronous waits are inappropriate, giving the agent clear decision criteria.

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/sassyconsultingllc/SassyMCP'

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