Skip to main content
Glama
thenavidm

Gumloop MCP Server

by thenavidm
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Call MCP tools

call_mcp_tools
Destructive

Execute up to five MCP tool calls concurrently and return each call's status and error, enabling mixed success and failure inspection in one batch.

Instructions

Execute a batch of 1–5 MCP tool calls. Calls run concurrently and each result reports its own status. When Gumloop accepts the request, MCP execution failures such as target server authentication, policy blocks, invalid tools, upstream HTTP errors, and connection failures are returned in results[*].status and results[*].error. Top-level 4xx responses are reserved for Gumloop request, authentication, and permission failures. 200 covers homogeneous execution outcomes (all calls succeeded or all calls failed); mixed success/failure batches return 207. If you previously treated non-2xx HTTP statuses as MCP execution failures, update your integration to inspect each result's status and error. Explicit confirmation is required for this exact account operation. Runs can spend credits or trigger downstream actions; never resubmit unknown outcomes automatically.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
callsNo
accountNoNamed private Gumloop account; selects private credentials and user/team identity.
confirmNoSet true only when the user asked for exactly this action.
payloadNoComplete JSON request body instead of body flags. Preserves current endpoint fields and values.
team_idNoTeam the calls are scoped to.
payload_fileNoRegular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed14 schema fields changedv3.0.0
    • addedInput schema / $defs / calls
      Added value: +{
+  "description": "Tool calls to execute. Dispatched concurrently; the batch is capped at 5.",
+  "items": {
+    "properties": {
+      "arguments": {
+        "description": "Arguments passed to the tool. Defaults to `{}`. Validated by the tool's `input_schema`.",
+        "type": "object"
+      },
+      "ref": {
+        "description": "Caller-supplied identifier echoed back on the matching result. When omitted, Gumloop assigns the call's zero-based index in `calls` as its `ref`.",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "server_id": {
+        "type": "string"
+      },
+      "tool_name": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "server_id",
+      "tool_name"
+    ],
+    "type": "object"
+  },
+  "maxItems": 5,
+  "minItems": 1,
+  "type": "array"
+}
    • addedInput schema / properties / calls / $ref
      Added value: +"#/$defs/calls"
    • removedInput schema / properties / calls / description
      Removed value: -"Tool calls to execute. Dispatched concurrently; the batch is capped at 5."
    • removedInput schema / properties / calls / items
      Removed value: -{
-  "properties": {
-    "arguments": {
-      "description": "Arguments passed to the tool. Defaults to `{}`. Validated by the tool's `input_schema`.",
-      "type": "object"
-    },
-    "ref": {
-      "description": "Caller-supplied identifier echoed back on the matching result. When omitted, Gumloop assigns the call's zero-based index in `calls` as its `ref`.",
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "server_id": {
-      "type": "string"
-    },
-    "tool_name": {
-      "type": "string"
-    }
-  },
-  "required": [
-    "server_id",
-    "tool_name"
-  ],
-  "type": "object"
-}
    • removedInput schema / properties / calls / maxItems
      Removed value: -5
    • removedInput schema / properties / calls / minItems
      Removed value: -1
    • removedInput schema / properties / calls / type
      Removed value: -"array"
    • changedInput schema / properties / confirm / description
      Previous value: -"Must be true for this exact requested account change, agent/flow execution, upload or deletion."New value: +"Set true only when the user asked for exactly this action."
    • addedInput schema / properties / payload / properties / calls / $ref
      Added value: +"#/$defs/calls"
    • removedInput schema / properties / payload / properties / calls / description
      Removed value: -"Tool calls to execute. Dispatched concurrently; the batch is capped at 5."
    • removedInput schema / properties / payload / properties / calls / items
      Removed value: -{
-  "properties": {
-    "arguments": {
-      "description": "Arguments passed to the tool. Defaults to `{}`. Validated by the tool's `input_schema`.",
-      "type": "object"
-    },
-    "ref": {
-      "description": "Caller-supplied identifier echoed back on the matching result. When omitted, Gumloop assigns the call's zero-based index in `calls` as its `ref`.",
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "server_id": {
-      "type": "string"
-    },
-    "tool_name": {
-      "type": "string"
-    }
-  },
-  "required": [
-    "server_id",
-    "tool_name"
-  ],
-  "type": "object"
-}
    • removedInput schema / properties / payload / properties / calls / maxItems
      Removed value: -5
    • removedInput schema / properties / payload / properties / calls / minItems
      Removed value: -1
    • removedInput schema / properties / payload / properties / calls / type
      Removed value: -"array"
  2. First observedv2.0.1

TDQS

A4.1/5.0
Behavior5/5

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

Annotations already flag destructive/openWorld/non-idempotent, and the description adds substantial context beyond them: concurrent dispatch, per-result status and error reporting, which failure classes appear in results vs top-level 4xx, the 200 vs 207 semantics for homogeneous vs mixed batches, and the credit-spend risk. This is exactly the behavioral disclosure an agent needs before invoking a destructive batch call.

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-loaded with the operation and its concurrency/cap, then moves to result semantics and then the confirmation warning. Dense but each block is relevant; the paragraph on HTTP status migration is slightly lecture-like and could be tightened.

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?

With no output schema and a nested 6-parameter schema, the description carries the return-shape burden and does so: it explains results[*].status/error, batch-level 200/207, and top-level 4xx. An agent can interpret a response and decide whether to retry without any further documentation.

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 83%, so the baseline is 3, but the description adds real meaning: the confirmation semantics tied to the `confirm` flag ('exact account operation') and the note that per-call errors surface in results rather than the top level. It doesn't clarify account, team_id, or payload/payload_file selection.

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 opens with a specific verb and resource plus scope: 'Execute a batch of 1–5 MCP tool calls,' and states they run concurrently. It is clearly distinguishable from siblings like list_mcp_server_tools or read_mcp_server_resource, though it never names an alternative sibling explicitly.

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?

It gives a strong precondition ('Explicit confirmation is required for this exact account operation') and a caution against auto-resubmitting unknown outcomes, which is useful when-to-use guidance. It does not, however, explain when to prefer this tool over a singular tool call or over list_/read_mcp_server_* siblings.

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

Deploy Server

Other Tools