Skip to main content
Glama
gabrielmaialva33

MCP Filesystem Server

bash_execute

Execute and capture Bash commands securely with predefined restrictions. Set working directory, timeout, and environment variables for controlled command execution within MCP Filesystem Server.

Instructions

Execute a Bash command directly with output capture. More flexible than execute_command but still with security restrictions. Allows for direct access to Bash functionality.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
commandYesThe bash command to execute
envNoAdditional environment variables for the command
timeoutNoMaximum execution time in milliseconds (max 60s)
workingDirNoWorking directory for command execution

Implementation Reference

  • Main handler for bash_execute tool: validates arguments, calls bashExecute, formats and returns MCP response.
    export async function handleBashExecute(args: any, config: Config) {
      const endMetric = metrics.startOperation('bash_execute')
    
      try {
        // Validate arguments
        const parsed = BashExecuteArgsSchema.safeParse(args)
        if (!parsed.success) {
          throw new FileSystemError(`Invalid arguments for bash_execute`, 'INVALID_ARGS', undefined, {
            errors: parsed.error.format(),
          })
        }
    
        // Execute the command
        const result = await bashExecute(parsed.data, config)
    
        // Format the response
        const formattedResponse = formatCommandResult(result, parsed.data.command)
    
        await logger.debug(`Bash command executed: ${args.command}`, {
          exitCode: result.exitCode,
        })
    
        endMetric()
        return {
          content: [
            {
              type: 'text',
              text: formattedResponse,
            },
          ],
        }
      } catch (error) {
        metrics.recordError('bash_execute')
    
        if (error instanceof FileSystemError) {
          await logger.error(`Error in bash_execute:`, error.toJSON())
          return {
            content: [{ type: 'text', text: `Error: ${error.message}` }],
            isError: true,
          }
        }
    
        const errorMessage = error instanceof Error ? error.message : String(error)
        await logger.error(`Unexpected error in bash_execute:`, { error })
    
        return {
          content: [{ type: 'text', text: `Error: ${errorMessage}` }],
          isError: true,
        }
      }
  • Core bash command execution logic using child_process.exec with safety checks, timeout, and logging.
    export async function bashExecute(
      args: z.infer<typeof BashExecuteArgsSchema>,
      config: Config
    ): Promise<{ stdout: string; stderr: string; exitCode: number }> {
      // Validate the command
      validateCommand(args.command)
    
      // Validate working directory if provided
      // Initialize cwd with the current directory and possibly override it
      const cwd = args.workingDir ? await validatePath(args.workingDir, config) : process.cwd()
    
      // Prepare execution options
      const options = {
        cwd,
        timeout: args.timeout || 30000,
        env: args.env ? { ...process.env, ...args.env } : process.env,
        encoding: 'utf8' as const,
        maxBuffer: 10 * 1024 * 1024, // 10MB buffer for output
      }
    
      try {
        await logger.debug(`Executing bash command: ${args.command}`, {
          workingDir: cwd,
          timeout: options.timeout,
        })
    
        // Execute the command
        const { stdout, stderr } = await execPromise(args.command, options)
    
        await logger.debug(`Command executed successfully: ${args.command}`, {
          exitCode: 0,
          stdoutPreview: stdout.substring(0, 100) + (stdout.length > 100 ? '...' : ''),
        })
    
        return {
          stdout,
          stderr,
          exitCode: 0,
        }
      } catch (error: any) {
        // Handle command execution errors
        const stderr = error.stderr || ''
        const stdout = error.stdout || ''
        const exitCode = error.code || 1
    
        await logger.warn(`Command execution failed: ${args.command}`, {
          exitCode,
          stderr: stderr.substring(0, 100) + (stderr.length > 100 ? '...' : ''),
        })
    
        return {
          stdout,
          stderr,
          exitCode,
        }
      }
    }
  • Zod schema for validating input arguments to the bash_execute tool.
    export const BashExecuteArgsSchema = z.object({
      command: z.string().describe('The bash command to execute'),
      workingDir: z.string().optional().describe('Working directory for command execution'),
      timeout: z
        .number()
        .int()
        .positive()
        .max(60000)
        .optional()
        .default(30000)
        .describe('Maximum execution time in milliseconds (max 60s)'),
      env: z.record(z.string()).optional().describe('Additional environment variables for the command'),
    })
  • src/index.ts:757-759 (registration)
    Registration and dispatch: switch case routes bash_execute calls to handleBashExecute.
    case 'bash_execute': {
      return await handleBashExecute(a, config)
    }
  • src/index.ts:356-362 (registration)
    Tool metadata registration in the ListTools response, including name, description, and schema.
      name: 'bash_execute',
      description:
        'Execute a Bash command directly with output capture. ' +
        'More flexible than execute_command but still with security restrictions. ' +
        'Allows for direct access to Bash functionality.',
      inputSchema: zodToJsonSchema(BashExecuteArgsSchema) as ToolInput,
    },
Behavior2/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 mentions 'security restrictions' and 'output capture,' which are useful behavioral traits. However, it lacks details on what those restrictions entail, whether the command runs in a sandbox, potential side effects (e.g., file modifications), error handling, or rate limits. For a tool that executes arbitrary Bash commands, this is a significant gap in transparency.

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 concise and front-loaded, with two sentences that directly state the tool's function and key features. There's no wasted text, but it could be slightly more structured by explicitly listing advantages or use cases. Overall, it's efficient and to the point.

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

Completeness2/5

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

Given the complexity of executing Bash commands (potentially destructive, security-sensitive) and the lack of annotations and output schema, the description is insufficient. It doesn't cover critical aspects like return values, error formats, safety warnings, or detailed behavioral context. For such a powerful tool, more completeness is needed to guide safe and effective use.

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 the schema fully documents all parameters (command, env, timeout, workingDir). The description adds no specific parameter semantics beyond implying the command is for Bash. This meets the baseline of 3, as the schema handles the heavy lifting, but the description doesn't enhance understanding of parameter usage or constraints.

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

Purpose4/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 Bash command directly with output capture.' It specifies the verb (execute) and resource (Bash command) and mentions output capture. However, it doesn't explicitly distinguish from sibling tools like 'execute_command' beyond saying 'more flexible,' which is vague rather than specific.

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

Usage Guidelines3/5

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

The description provides some usage context by comparing to 'execute_command' ('more flexible... but still with security restrictions'), implying this tool is for advanced Bash usage. However, it doesn't explicitly state when to use this over alternatives like 'bash_pipe' or 'execute_command,' nor does it mention any exclusions or prerequisites, leaving the guidance incomplete.

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

Related 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/gabrielmaialva33/mcp-filesystem'

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