Skip to main content
Glama
Damel91

Flower MCP

by Damel91
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

fow_packet_advance

Destructive

Advance a lifecycle packet through its ordinary gate decisions and provider delivery, or sync authoring deltas without starting execution.

Instructions

Move an existing packet through its ordinary lifecycle gates and admitted provider delivery, or only synchronize authoring deltas without starting execution. Semantic decisions answer the exact current gate. Route ordinary progression with mode=advance (default) or sync_only. Gate responses use decision.operation: accept_work_plan, reject_work_plan, accept_residual_risk, retry_provider_rejection, record_workspace_review, resolve_reconciliation_residual. Prerequisites: Inspect the current packet gate and retain issued revision/fingerprint identities. Effects: advance may synchronize provider deltas, persist transitions and reach START when admitted. mode=sync_only delivers deltas without START and rejects gate decisions. Explicit provider routes require compatible configured support; failures preserve truthful recovery. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_packet_advance","operation_name":"advance"}).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoPacket advancement policy: advance evaluates ordinary progression; sync_only delivers pending deltas without START. Applies to: advance. Canonical values: advance, sync_only.advance
actorYesIdentity of the human or agent recording this action; retain the original identity when replaying its request.
decisionNoGate response object routed by decision.operation. Omit it for ordinary advance; obtain the current gate and its required decision fields before replying. sync_only rejects semantic decisions. Applies to: accept_work_plan, reject_work_plan, accept_residual_risk, retry_provider_rejection, record_workspace_review, resolve_reconciliation_residual. Required by: accept_work_plan, reject_work_plan, accept_residual_risk, retry_provider_rejection, record_workspace_review, resolve_reconciliation_residual. Exact required/optional dotted fields and guidance: fow_capabilities(view=operation, operation_tool=fow_packet_advance, operation_name=<selected route>).
change_idNoCanonical owning change ID; when address resolution permits omission, the packet/campaign must resolve unambiguously.
packet_idYesCanonical 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_idYesCaller-owned retry identity. For receipted mutations replay the same actor and contents; changed contents can conflict. Inspect exact operation help for its receipt policy.
expected_plan_revisionNoPlan revision issued with the work or gate being acted on; do not replace stale issued authority to legitimize old work.
expected_spec_revisionNoPacket specification revision issued with the work or gate being acted on; mismatch rejects stale mutation.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed11 schema fields changedv0.5.1
    • 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 / change_id / description
      Added value: +"Canonical owning change ID; when address resolution permits omission, the packet/campaign must resolve unambiguously."
    • addedInput schema / properties / decision / description
      Added value: +"Gate response object routed by decision.operation. Omit it for ordinary advance; obtain the current gate and its required decision fields before replying. sync_only rejects semantic decisions. Applies to: accept_work_plan, reject_work_plan, accept_residual_risk, retry_provider_rejection, record_workspace_review, resolve_reconciliation_residual. Required by: accept_work_plan, reject_work_plan, accept_residual_risk, retry_provider_rejection, record_workspace_review, resolve_reconciliation_residual. Exact required/optional dotted fields and guidance: fow_capabilities(view=operation, operation_tool=fow_packet_advance, operation_name=<selected route>)."
    • addedInput schema / properties / decision / examples
      Added value: +[
+  {
+    "operation": "accept_work_plan",
+    "rationale": "example-rationale"
+  }
+]
    • addedInput schema / properties / expected_plan_revision / description
      Added value: +"Plan revision issued with the work or gate being acted on; do not replace stale issued authority to legitimize old work."
    • addedInput schema / properties / expected_spec_revision / description
      Added value: +"Packet specification revision issued with the work or gate being acted on; mismatch rejects stale mutation."
    • addedInput schema / properties / mode / description
      Added value: +"Packet advancement policy: advance evaluates ordinary progression; sync_only delivers pending deltas without START. Applies to: advance. Canonical values: advance, sync_only."
    • addedInput schema / properties / mode / examples
      Added value: +[
+  "advance"
+]
    • 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 / 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."
  2. First observedv0.1.0

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true; the description adds real behavioral context beyond them — what advance persists and that it can reach START when admitted, that sync_only delivers deltas without START and rejects gate decisions, that explicit provider routes require compatible configured support, and that failures preserve truthful recovery. It stops short of detailing what state is destroyed or the retry/conflict mechanics, which the schema partially carries.

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?

Purpose is front-loaded, followed by routing, prerequisites, effects, and a precise help pointer, so each block is scannable. It is dense with domain jargon and the 'Semantic decisions answer the exact current gate' line is terse to the point of opacity, but no sentence is pure filler.

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?

For a 9-parameter, gated mutation tool with an output schema available, the description covers prerequisites, effects, mode routing, and failure behavior adequately. It relies on the fow_capabilities pointer for exact per-route required fields, which is a reasonable division of labor but leaves the agent to make a follow-up call.

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 goes further by explaining mode semantics, how decision.operation routes each gate response, and the need to retain issued revision/fingerprint identities (expected_plan_revision/expected_spec_revision). It adds meaning beyond the schema rather than restating it.

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?

States a concrete verb+resource ('Move an existing packet through its ordinary lifecycle gates') and splits it into the two operating modes (advance vs sync_only), so the agent knows this is a lifecycle-progression tool rather than authoring or inspection. It does not explicitly name siblings such as fow_packet_inspect or fow_packet_author, so it falls short of full sibling differentiation.

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 clear routing criteria ('Route ordinary progression with mode=advance (default) or sync_only'), states the prerequisite to inspect the current gate first, and enumerates the gate decision routes via decision.operation. There is no explicit 'do not use this when X, use tool Y' exclusion, but the context for correct usage is well covered.

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