Skip to main content
Glama
metamug

plunger

Official

run_workflow

Execute a saved workflow: requests go in order, values pass between steps, and it stops at the first failure. Returns step statuses, set variables, and the final response.

Instructions

Run a saved workflow: its requests are sent in order, values are carried from one response to the next (never shown if secret), and it stops at the first step that fails. Returns each step's status and the variables it set, plus the last response in full.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesThe workflow's name (see list_workflows).
cleanupNoRemove the variables this run stored once it is done (the later steps have used them by then), so runs do not leave values behind. Values extracted with `scope: "run"` are never stored at all.
variablesNo{{variable}} values for every step of this run.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okYesTrue when every step passed.
stepsYes
workflowYes
cancelledNoTrue when the run was cancelled before it finished.
steps_runYesHow many steps ran (a failed step stops the rest).
cleaned_upNoWith `cleanup`: the variables the run stored and then removed.
last_responseNoThe last response that came back, in full.
stopped_earlyNoTrue when a `stop_if` ended the run before the last step.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior5/5

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

Annotations only supply openWorldHint and a title, so the description carries the real behavioral load and does so well: in-order execution, value propagation between steps, secrets never surfaced, fail-fast on first error, and what is returned. These are exactly the traits an agent needs to predict outcomes.

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?

Dense but front-loaded: the execution model is stated first, then the return contract. It packs semantics into relatively few words with no filler, though the single long sentence with parenthetical asides is slightly heavy.

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?

With an output schema present, return values need not be explained, yet the description still summarizes them concisely. Execution behavior is well covered; only prerequisites (auth/environment context) go unmentioned, a minor gap for a tool with this much disclosure.

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 coverage is 100%, so name, cleanup, and variables are already fully documented in the schema, including the cleanup trade-off and the scope:'run' exception. The description adds nothing parameter-specific beyond a passing mention of returned variables, so baseline 3 applies.

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?

Specific verb+resource: 'Run a saved workflow'. It immediately distinguishes itself from send_request (single request) and list_workflows by describing the ordered multi-step execution model. An agent can tell what this does without opening the schema.

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?

Usage is implied rather than stated: 'a saved workflow' signals you need a name from list_workflows, and the fail-fast semantics help an agent judge fit. However, it never explicitly contrasts with send_request or explains when running a workflow is preferable to sending individual requests.

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