Skip to main content
Glama

fow_run

Destructive

Records implementation runs with ordered dependent steps, tracking started, completed, blocked, and cancelled states to monitor execution and dependencies.

Instructions

Track who performs the implementation work: record a run, ordered dependent steps and their started/completed/blocked/cancelled states. The coding agent performs those actions outside Flower. Route with operation: create_run, get_run, add_step, link_step_dependency, start_step, complete_step, block_step, cancel_step, complete_run, cancel_run, task_view. Prerequisites: Use a governed change/packet and existing run/step IDs where requested. Effects: Records implementation-run steps, dependencies and execution outcomes; cancellation changes live authority. Flower does not execute the declared step actions. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_run","operation_name":"create_run"}).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actorYesIdentity of the human or agent recording this action; retain the original identity when replaying its request.
titleNoShort human-readable title of the authored requirement, finding, packet, run step or campaign. Applies to: add_step. Required by: add_step.
actionNoBounded instruction describing what this implementation-run step will do. Applies to: add_step. Required by: add_step.
reasonNoExplicit reason for the transition, cancellation or continuation action. Applies to: cancel_step, cancel_run. Required by: cancel_step, cancel_run.
run_idNoExisting implementation-run identity returned by create_run. Applies to: get_run, add_step, link_step_dependency, start_step, complete_step, block_step, cancel_step, complete_run, cancel_run, task_view. Required by: get_run, add_step, link_step_dependency, start_step, complete_step, block_step, cancel_step, complete_run, cancel_run, task_view.
step_idNoExisting implementation-run step identity. Applies to: link_step_dependency, start_step, complete_step, block_step, cancel_step. Required by: link_step_dependency, start_step, complete_step, block_step, cancel_step.
change_idNoCanonical owning change ID; when address resolution permits omission, the packet/campaign must resolve unambiguously.
objectiveNoObservable objective of the use case or implementation run. Applies to: create_run. Required by: create_run.
operationYesOperation selector for this multiplexer; use a canonical route listed below. Canonical values: create_run, get_run, add_step, link_step_dependency, start_step, complete_step, block_step, cancel_step, complete_run, cancel_run, task_view.
packet_idNoCanonical packet identity returned by authoring; it identifies the bounded implementation work.
project_idYesCanonical lifecycle project ID. Select the existing project explicitly; development Markdown authorities are separate from runtime projects.
request_idNoCaller-owned retry identity. For receipted mutations replay the same actor and contents; changed contents can conflict. Inspect exact operation help for its receipt policy.
source_refNoDeclared source-authority reference attached to the implementation run. Applies to: create_run.
target_refsNoExplicit implementation/source targets for this bounded run step. Applies to: add_step.
external_refNoDeclared external execution/reference identity attached to the implementation run. Applies to: create_run.
evidence_refsNoReferences to actual supporting evidence; host-declared provenance remains host-declared. Applies to: add_step, complete_step. Required by: complete_step.
step_requiredNoWhether completion of this implementation-run step is required for the run to complete. Applies to: add_step.
blocking_reasonNoConcrete reason the implementation-run step cannot advance. Applies to: block_step. Required by: block_step.
orchestrator_refNoIdentity/reference of the orchestrator responsible for this implementation run. Applies to: create_run.
depends_on_step_idNoExisting predecessor run-step ID that must complete before the selected step can start. Applies to: link_step_dependency. Required by: link_step_dependency.
completion_referenceNoReference to the actual evidence/authority supporting completion of this lifecycle object. Applies to: complete_run. Required by: complete_run.
next_expected_actionNoConcrete next action required to unblock or continue this implementation-run step. Applies to: block_step. Required by: block_step.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed23 schema fields changedv0.5.1
    • addedInput schema / properties / action / description
      Added value: +"Bounded instruction describing what this implementation-run step will do. Applies to: add_step. Required by: add_step."
    • addedInput schema / properties / actor / description
      Added value: +"Identity of the human or agent recording this action; retain the original identity when replaying its request."
    • addedInput schema / properties / blocking_reason / description
      Added value: +"Concrete reason the implementation-run step cannot advance. Applies to: block_step. Required by: block_step."
    • addedInput schema / properties / change_id / description
      Added value: +"Canonical owning change ID; when address resolution permits omission, the packet/campaign must resolve unambiguously."
    • addedInput schema / properties / completion_reference / description
      Added value: +"Reference to the actual evidence/authority supporting completion of this lifecycle object. Applies to: complete_run. Required by: complete_run."
    • addedInput schema / properties / depends_on_step_id / description
      Added value: +"Existing predecessor run-step ID that must complete before the selected step can start. Applies to: link_step_dependency. Required by: link_step_dependency."
    • addedInput schema / properties / evidence_refs / description
      Added value: +"References to actual supporting evidence; host-declared provenance remains host-declared. Applies to: add_step, complete_step. Required by: complete_step."
    • addedInput schema / properties / external_ref / description
      Added value: +"Declared external execution/reference identity attached to the implementation run. Applies to: create_run."
    • addedInput schema / properties / next_expected_action / description
      Added value: +"Concrete next action required to unblock or continue this implementation-run step. Applies to: block_step. Required by: block_step."
    • addedInput schema / properties / objective / description
      Added value: +"Observable objective of the use case or implementation run. Applies to: create_run. Required by: create_run."
    • addedInput schema / properties / operation / description
      Added value: +"Operation selector for this multiplexer; use a canonical route listed below. Canonical values: create_run, get_run, add_step, link_step_dependency, start_step, complete_step, block_step, cancel_step, complete_run, cancel_run, task_view."
    • addedInput schema / properties / operation / examples
      Added value: +[
      +  "create_run"
      +]
    • addedInput schema / properties / orchestrator_ref / description
      Added value: +"Identity/reference of the orchestrator responsible for this implementation run. Applies to: create_run."
    • addedInput schema / properties / packet_id / description
      Added value: +"Canonical packet identity returned by authoring; it identifies the bounded implementation work."
    • addedInput schema / properties / project_id / description
      Added value: +"Canonical lifecycle project ID. Select the existing project explicitly; development Markdown authorities are separate from runtime projects."
    • addedInput schema / properties / reason / description
      Added value: +"Explicit reason for the transition, cancellation or continuation action. Applies to: cancel_step, cancel_run. Required by: cancel_step, cancel_run."
    • addedInput schema / properties / request_id / description
      Added value: +"Caller-owned retry identity. For receipted mutations replay the same actor and contents; changed contents can conflict. Inspect exact operation help for its receipt policy."
    • addedInput schema / properties / run_id / description
      Added value: +"Existing implementation-run identity returned by create_run. Applies to: get_run, add_step, link_step_dependency, start_step, complete_step, block_step, cancel_step, complete_run, cancel_run, task_view. Required by: get_run, add_step, link_step_dependency, start_step, complete_step, block_step, cancel_step, complete_run, cancel_run, task_view."
    • addedInput schema / properties / source_ref / description
      Added value: +"Declared source-authority reference attached to the implementation run. Applies to: create_run."
    • addedInput schema / properties / step_id / description
      Added value: +"Existing implementation-run step identity. Applies to: link_step_dependency, start_step, complete_step, block_step, cancel_step. Required by: link_step_dependency, start_step, complete_step, block_step, cancel_step."
    • addedInput schema / properties / step_required / description
      Added value: +"Whether completion of this implementation-run step is required for the run to complete. Applies to: add_step."
    • addedInput schema / properties / target_refs / description
      Added value: +"Explicit implementation/source targets for this bounded run step. Applies to: add_step."
    • addedInput schema / properties / title / description
      Added value: +"Short human-readable title of the authored requirement, finding, packet, run step or campaign. Applies to: add_step. Required by: add_step."
  2. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already flag destructiveHint=true, readOnlyHint=false, idempotentHint=false, but the description adds genuine context beyond them: that the coding agent acts outside Flower, that cancellation changes live authority, and that Flower never executes declared step actions. These are meaningful behavioral disclosures for a mutation tool.

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 purpose, then routing, prerequisites, effects, and a help pointer in a compact block. Slightly redundant, repeating the non-execution point twice ('performs those actions outside Flower' and 'Flower does not execute the declared step actions').

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?

Because an output schema exists, return values need not be described; the description covers routing, prerequisites, and effects for a complex 22-parameter multiplexer. It reasonably defers exact per-operation detail to fow_capabilities, though that leaves some ambiguity resolvable only by a follow-up call.

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 description coverage is 100%, so every parameter is already documented with its per-operation applicability and requiredness. The description adds only the conceptual grouping of operations, so the baseline 3 is appropriate.

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 ('Track who performs the implementation work: record a run, ordered dependent steps...') and enumerates the eleven canonical routes, so an agent can distinguish it from sibling multiplexers like fow_packet_advance or fow_campaign_advance without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear operational context (route via 'operation', prerequisites of a governed change/packet and existing IDs) and points to fow_capabilities for exact per-operation help. It stops short of explicitly naming when to prefer this tool over adjacent siblings.

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