Skip to main content
Glama
ConnorBoetig-dev

Unrestricted Development MCP Server

shell_execute_streaming

Execute long-running shell commands with real-time output streaming for build processes, scripts, and services that produce continuous output over time.

Instructions

Execute a long-running shell command with streaming output support. Captures output as it's produced.

Use this for:

  • Build processes (npm build, cargo build, etc.)

  • Long-running scripts

  • Services that produce continuous output

  • Commands that take significant time to complete

The command runs in /bin/bash by default. Output is streamed and returned when complete.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
commandYesThe shell command to execute with streaming output
cwdNoWorking directory for the command
envNoEnvironment variables to set for the command
shellNoShell to use (default: /bin/bash)
sudoNoExecute with sudo privileges

Implementation Reference

  • Core handler function that executes the shell command using spawn for real-time streaming output capture and processing.
    export async function executeStreamingCommand(args: z.infer<typeof executeStreamingCommandSchema>): Promise<ToolResponse> {
      try {
        // For sudo commands, wrap the entire command in a shell to ensure all parts run with sudo
        const command = args.sudo
          ? `sudo bash -c ${JSON.stringify(args.command)}`
          : args.command;
    
        return new Promise((resolve) => {
          const child = spawn(command, {
            cwd: args.cwd,
            env: args.env ? { ...process.env, ...args.env } : process.env,
            shell: args.shell || '/bin/bash',
            stdio: ['ignore', 'pipe', 'pipe']
          });
    
          let stdout = '';
          let stderr = '';
    
          child.stdout?.on('data', (data) => {
            stdout += data.toString();
          });
    
          child.stderr?.on('data', (data) => {
            stderr += data.toString();
          });
    
          child.on('close', (code, signal) => {
            resolve({
              content: [
                {
                  type: "text" as const,
                  text: JSON.stringify({
                    success: code === 0,
                    command: command,
                    stdout: stdout,
                    stderr: stderr,
                    exitCode: code,
                    signal: signal
                  }, null, 2)
                }
              ],
              isError: code !== 0
            });
          });
    
          child.on('error', (error) => {
            resolve({
              content: [
                {
                  type: "text" as const,
                  text: JSON.stringify({
                    success: false,
                    command: command,
                    stdout: stdout,
                    stderr: stderr + '\n' + error.message,
                    error: error.message
                  }, null, 2)
                }
              ],
              isError: true
            });
          });
        });
      } catch (error) {
        return {
          content: [
            {
              type: "text" as const,
              text: JSON.stringify({
                success: false,
                error: error instanceof Error ? error.message : String(error)
              }, null, 2)
            }
          ],
          isError: true
        };
      }
    }
  • Zod schema defining input validation for the shell_execute_streaming tool parameters.
    export const executeStreamingCommandSchema = z.object({
      command: z.string().describe('The shell command to execute with streaming output'),
      cwd: z.string().optional().describe('Working directory for the command'),
      env: z.record(z.string()).optional().describe('Environment variables to set for the command'),
      shell: z.string().optional().describe('Shell to use (default: /bin/bash)'),
      sudo: z.boolean().default(false).describe('Execute with sudo privileges')
    });
  • Tool definition object in shellTools array, used for listing the tool in MCP protocol.
      {
        name: 'shell_execute_streaming',
        description: `Execute a long-running shell command with streaming output support. Captures output as it's produced.
    
    Use this for:
    - Build processes (npm build, cargo build, etc.)
    - Long-running scripts
    - Services that produce continuous output
    - Commands that take significant time to complete
    
    The command runs in /bin/bash by default. Output is streamed and returned when complete.`,
        inputSchema: {
          type: 'object',
          properties: {
            command: {
              type: 'string',
              description: 'The shell command to execute with streaming output'
            },
            cwd: {
              type: 'string',
              description: 'Working directory for the command'
            },
            env: {
              type: 'object',
              additionalProperties: { type: 'string' },
              description: 'Environment variables to set for the command'
            },
            shell: {
              type: 'string',
              description: 'Shell to use (default: /bin/bash)'
            },
            sudo: {
              type: 'boolean',
              default: false,
              description: 'Execute with sudo privileges'
            }
          },
          required: ['command']
        }
      }
  • src/index.ts:351-353 (registration)
    Dispatch logic in the central CallToolRequestHandler that routes calls to the streaming shell handler.
    if (name === 'shell_execute_streaming') {
      const validated = executeStreamingCommandSchema.parse(args);
      return await executeStreamingCommand(validated);
  • src/index.ts:285-296 (registration)
    ListToolsRequestHandler that includes shellTools (containing shell_execute_streaming) in the available tools list.
    return {
      tools: [
        ...filesystemTools,
        ...shellTools,
        ...dockerTools,
        ...mongodbTools,
        ...redisTools,
        ...gitTools,
        ...processTools,
        ...networkTools
      ]
    };
Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses key behavioral traits: long-running nature, streaming output, default shell (/bin/bash), and that output is returned when complete. However, it lacks details on error handling, timeout behavior, security implications (especially with sudo), or output format, which are important for a shell execution tool. It doesn't contradict annotations (none exist), but could be more comprehensive.

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 well-structured and appropriately sized. It starts with a clear purpose statement, followed by usage guidelines in a bulleted list, and ends with operational details. Every sentence earns its place by adding value, with no redundant or vague language, making it efficient and easy to parse.

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?

Given the tool's complexity (shell execution with streaming) and the absence of annotations and output schema, the description does a good job but has gaps. It covers purpose, usage, and some behavioral aspects, but lacks details on error handling, output structure, or security warnings (e.g., risks of sudo). For a tool with no structured safety hints, this is above minimum viable but not fully complete.

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?

The schema description coverage is 100%, so the schema already documents all parameters (command, cwd, env, shell, sudo) with descriptions. The description adds minimal parameter semantics beyond the schema, mentioning only the default shell (/bin/bash) and implying the command parameter's purpose. It doesn't provide additional context like parameter interactions or examples, so the baseline score of 3 is appropriate as the schema does the heavy lifting.

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's purpose: 'Execute a long-running shell command with streaming output support. Captures output as it's produced.' This specifies the verb (execute), resource (shell command), and key capability (streaming output). It effectively distinguishes this tool from its sibling 'shell_execute' (which presumably lacks streaming support), making the distinction explicit.

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 usage guidelines with a bulleted list of scenarios: 'Use this for: - Build processes (npm build, cargo build, etc.) - Long-running scripts - Services that produce continuous output - Commands that take significant time to complete.' This gives clear context on when to use this tool versus alternatives (e.g., non-streaming commands or other siblings like docker tools), though it doesn't explicitly name alternatives, the context is sufficient.

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/ConnorBoetig-dev/mcp2'

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