Flowra

Run app tools

FLOWRA_MULTI_EXECUTE_TOOL

Destructive

Run up to 50 action tools in parallel and return every result inline. Only type="action" tools — triggers and webhooks cannot be executed here.

This is how you run any tool that is not already bound as a direct function. Get the exact slug from FLOWRA_DISCOVER_TOOLS or a Known tools list, load its input schema with FLOWRA_GET_TOOL_SCHEMAS (or set includeInputSchemas on DISCOVER and reuse those), and call FLOWRA_MANAGE_CONNECTIONS first if the toolkit has no active connection. Never invent a slug or an argument. Never emit an unbound slug as a tool_call name — only this function runs those slugs, via tools[].toolSlug.

tools must be a non-empty array of { toolSlug, arguments }. Never pass tools: [] or omit tools. If you only have a JSON string, parse it into that array first.

Batch only independent calls; keep a dependent step in a later call so you can read the previous result first. When a result implies more pages, keep going until you have everything.

Never wrap a tool that waits for the user (for example a choice prompt) here. If one is bound, call it directly and wait.

Input Schema

Name	Required	Description
`tools`	Yes	Action tools to run in parallel (max 50). Not triggers. Must contain at least one { toolSlug, arguments } — never [].
`memory`	No	Durable facts worth reusing later, as {app: ["fact"]} — ids and mappings, not "sent/fetched" logs. Pass {} when there are none.
`session`	No	Meta session.id from DISCOVER (workbench correlation; auth is user-scoped)
`thought`	No	One-sentence rationale
`syncResponseToWorkbench`	Yes	Store a workbench snapshot for REMOTE_BASH / JS_REMOTE_WORKBENCH (results still return inline). Needs session.id. Only set true when a sandbox tool is available and the output is large or worth scripting over.

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": {
+        "errorCount": {
+          "description": "Failures"
+        },
+        "results": {
+          "description": "Results in input order",
+          "items": {
+            "properties": {
+              "error": {
+                "anyOf": [
+                  {},
+                  {}
+                ],
+                "description": "Error message when failed"
+              },
+              "index": {
+                "description": "Index in the request tools array"
+              },
+              "response": {
+                "anyOf": [
+                  {
+                    "propertyNames": {}
+                  },
+                  {}
+                ],
+                "description": "Payload { data, error, logId, successful } on success and failure"
+              },
+              "success": {
+                "description": "Whether execution succeeded"
+              },
+              "toolSlug": {
+                "description": "Executed tool slug"
+              }
+            }
+          }
+        },
+        "successCount": {
+          "description": "Successes"
+        },
+        "totalCount": {
+          "description": "Tools executed"
+        },
+        "workbenchArtifactId": {
+          "description": "Snapshot id when syncResponseToWorkbench; pass to REMOTE_BASH or omit for latest"
+        }
+      }
+    },
+    "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.7/5.0

Behavior4/5

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

Annotations already declare destructive/openWorld/non-idempotent, but the description adds meaningful operational behavior: parallel execution, inline return of every result, slug-validity enforcement, pagination continuation, and the prohibition on invoking unbound slugs as tool_call names. It stops short of describing partial-failure or error semantics when some of the 50 calls fail, which keeps it from a 5.

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?

Front-loads the core action in the first sentence, then layers prerequisites, batching rules, and exclusions in short, self-contained paragraphs. Despite the length, every sentence carries a distinct actionable constraint.

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?

For a complex meta-execution tool with nested objects, an output schema, and full annotation coverage, the description supplies everything the agent needs to construct a valid call: slug sourcing, schema loading, connection prerequisites, batching, pagination, and wait-tool exclusions. Return values are covered by the output schema, so omitting them is correct.

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 the baseline is 3, but the description earns extra by reinforcing the tools contract (non-empty array of {toolSlug, arguments}, never [], parse JSON strings first) and the rule that toolSlug must come from DISCOVER/pins and never be invented. It leaves memory/session/thought/syncResponseToWorkbench to the schema, which already documents them well.

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 (run), resource (action tools), and scope (up to 50, in parallel, inline results) in the first sentence. It immediately distinguishes itself from siblings by excluding triggers and webhooks and by naming DISCOVER, GET_TOOL_SCHEMAS, and MANAGE_CONNECTIONS as the supporting flow.

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?

Explicit when-to-use (any tool not bound as a direct function), how to prepare (get slug from DISCOVER, load schema, ensure a connection), and when-not (triggers/webhooks, waiting tools that must be called directly). It even gives sequencing rules: batch only independent calls, keep dependents in later calls, and continue paging until complete.

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?