Flowra

Bash sandbox

FLOWRA_REMOTE_BASH

Destructive

Run bash on the same remote sandbox as FLOWRA_JS_REMOTE_WORKBENCH for this session.id. Files under /home/user/files stay between calls. The shell itself starts fresh each time.

With session.id and useWorkbenchSnapshot (default true), the latest FLOWRA_MULTI_EXECUTE_TOOL snapshot is at /home/user/files/multi_execute.json (also FLOWRA_WORKBENCH_JSON). That snapshot only exists if the earlier call set syncResponseToWorkbench: true.

Use this for shell work on those files: jq, grep, sort, unzip, wc, listing directories. It has no run_tool, invoke_llm, or proxy_execute helpers and keeps no variables between calls. To call app tools, an LLM, or a connected API from the sandbox, or to keep state across steps, use FLOWRA_JS_REMOTE_WORKBENCH. Neither tool can call FLOWRA_MULTI_EXECUTE_TOOL or any other meta tool.

Input Schema

Name	Required	Description
`command`	Yes	The bash command to execute
`session`	No	ALWAYS pass session.id from DISCOVER when provided (or omit in chat — threadId is used).
`workbenchArtifactId`	No	Specific snapshot id returned as workbenchArtifactId by MULTI_EXECUTE; omit to use the latest snapshot for this session.
`useWorkbenchSnapshot`	No	When true (default), inject the latest Flowra workbench JSON for this session (from MULTI_EXECUTE + syncResponseToWorkbench) before your command. Set false to run raw bash only.

Output Schema

Name	Required	Description
`data`	No
`error`	No	Error if any occurred during the execution of the action
`message`	No
`successful`	No	Whether or not the action execution was successful or not

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 11, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "data": {
+      "properties": {
+        "sandbox_id_suffix": {
+          "description": "Last 4 digits of the sandbox ID for easier reference"
+        },
+        "session": {
+          "anyOf": [
+            {
+              "properties": {
+                "id": {},
+                "instructions": {}
+              }
+            },
+            {}
+          ],
+          "description": "Meta session echoed back to reinforce reuse: { id: string, instructions: string }"
+        },
+        "stderr": {
+          "description": "The standard error output from the command, possibly truncated for brevity."
+        },
+        "stderrLines": {
+          "description": "Total number of lines in original stderr, even if truncated"
+        },
+        "stderr_file_path": {
+          "anyOf": [
+            {},
+            {}
+          ],
+          "description": "Path to file containing full stderr if output was truncated"
+        },
+        "stdout": {
+          "description": "The standard output from the command, possibly truncated for brevity."
+        },
+        "stdoutLines": {
+          "description": "Total number of lines in original stdout, even if truncated"
+        },
+        "stdout_file_path": {
+          "anyOf": [
+            {},
+            {}
+          ],
+          "description": "Path to file containing full stdout if output was truncated"
+        }
+      }
+    },
+    "error": {
+      "anyOf": [
+        {},
+        {}
+      ],
+      "description": "Error if any occurred during the execution of the action"
+    },
+    "message": {},
+    "successful": {
+      "description": "Whether or not the action execution was successful or not"
+    }
+  },
+  "type": "object"
+}

First observedSep 25, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare destructive/openWorld/non-idempotent, and the description goes well beyond them: file persistence under /home/user/files, shell state resetting each call, no run_tool/invoke_llm/proxy_execute helpers, no variables kept, and the syncResponseToWorkbench:true prerequisite for snapshot existence.

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?

Front-loads the core purpose and persistence model before the snapshot mechanics and sibling routing. Dense but every sentence carries operational weight; only slightly long.

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?

Covers persistence semantics, prerequisites, sandbox limitations, and the sibling alternative. An output schema exists, so return values need not be explained, and nothing an agent needs to invoke it correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3, but the description adds real meaning: it ties useWorkbenchSnapshot (default true) to the snapshot file path and the syncResponseToWorkbench prerequisite, explaining why the injected file may be absent.

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?

States a specific verb and resource ('Run bash on the same remote sandbox... for this session.id') and explicitly contrasts with the sibling FLOWRA_JS_REMOTE_WORKBENCH. An agent can distinguish it from the JS workbench without opening either schema.

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?

Gives concrete when-to-use examples (jq, grep, sort, unzip, wc, directory listing) and an explicit alternative rule: use FLOWRA_JS_REMOTE_WORKBENCH for app tools, LLM calls, connected APIs, or cross-step state. Nothing is left to inference.

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

All Flowra tools Inspect

Try in Browser

Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?