Fetch Hive

Run a workflow

run_workflow

Destructive

Run a workflow once, as it is now, like the editor's Run button. Runs cost money and can send messages or change things in connected apps, so: call it first without approved to get the cost and the inputs it would use, tell the person, and only call again with approved: true after they say yes. Returns a run_id; then call get_run every 15 seconds or so until done is true.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "workflow_id": "<workflow_id>"
    },
    "name": "run_workflow"
  }
}

Input Schema

Name	Required	Description
`inputs`	No	Start input values keyed by input name (see get_workflow start_inputs). Inputs left out use their example value.
`approved`	No	true only after the person has agreed to this run and its cost.
`workflow_id`	Yes	The workflow to run.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already flag destructive, non-idempotent, open-world behavior; the description adds the specifics that matter — runs cost money and can send messages or change connected apps. It also discloses the return value (run_id) and the required polling loop, which no structured field provides.

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 purpose, then the safety protocol, then the return/polling instruction — a logical order with no wasted sentences. The middle sentence is long and clause-heavy, but every clause carries operational weight.

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 destructive, costly, non-idempotent action with no output schema, the description covers the cost preview, consent gate, side effects, and the post-call polling loop. Nothing an agent needs in order to invoke it safely 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 the schema carries the field definitions and the baseline would be 3. The description still adds real meaning by defining 'approved' as a consent gate tied to a prior preview call, and by implying inputs default to example values via the get_workflow reference.

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 a workflow once, as it is now, like the editor's Run button') and pins down the snapshot semantics of the run. An agent can distinguish this from siblings like test_run_draft or retry_run from the description alone.

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 an explicit two-phase protocol: call without approved to preview cost and inputs, tell the person, then re-call with approved: true only after consent. It also names the follow-up tool (get_run) and a polling cadence, so both when-to-use and what-to-do-next are covered.

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

All Fetch Hive tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?