Skip to main content
Glama

Flower MCP

Persistent software lifecycle management for coding agents.

Building software with an AI agent takes more than a good prompt. You need to keep track of what you asked for, which decisions you made, what is ready to build and what still needs checking.

Flower gives your agent a lasting project memory and a structured way to move from an idea to verified work. It keeps requirements, plans, decisions and evidence connected, even when the conversation changes.

In testing · Python 3.11+ · Latest release · Apache-2.0

Quick start · First project · English walkthrough · Presentazione italiana

What you gain

  • Pick up where you left off. Recover the selected project's context, decisions, open work and next step in another session or compatible agent.

  • Start with the behavior you want. Describe what the software should do and show. Your agent investigates technical choices, asks focused questions and proposes a roadmap for you to confirm.

  • Give the agent work it can act on. Plans carry scope, ordered tasks, dependencies and checks. Flower exposes missing declarations and lifecycle gates before admitting the next operation.

  • See what “done” means. Work reported as implemented, evidence of verification and a decision to accept the result remain distinct.

  • Keep progress when plans change. Requirements, decisions and results retain their revisions and history, so earlier work stays understandable.

  • Inspect the project yourself. Open the local browser dashboard to see requirements, roadmap, packets and verification, and read retained Markdown without asking an agent to summarize it.

  • Hand work over, including offline. Export a self-contained Markdown plan, carry out its authorized work and reconcile outcomes when Flower is available again.

Project state lives in a SQLite ledger under your chosen Flower profile. The core works without an internal model or CodingCastle. You can use a local or cloud coding agent through a compatible MCP client.

Related MCP server: project-memory-mcp

How it works

You explain the outcome. Your coding agent investigates the repository, chooses an implementation, writes code and runs builds and tests. Flower maintains the project's requirements, roadmap, work plans, findings, evidence and handovers. You keep the scope and acceptance decisions assigned to you.

For example, you might ask:

I want a room-booking service for our association. Two people must not be able to reserve the same room at the same time.

The agent can clarify what a booking means, record the agreed behavior and propose bounded work. The plan identifies what must be implemented and checked. If overlapping bookings are confirmed for the same room, that is a defect to investigate; adding recurring bookings changes the requested scope. Flower keeps those discussions and their resulting work connected.

This is an illustrative scenario, not a benchmark. Follow the complete story in English or Italiano.

Governing architecture stays in Flower alongside the work it explains. At a bounded work boundary, the agent reconciles repository facts and original evidence with current authority before dependent work advances. Read the engineering cycle for the practical workflow.

Quick start

Have a supported client installed: Codex, Claude Code, Cursor, Antigravity, Gemini CLI or OpenCode V2. Choose a writable user directory and check the installation prerequisites.

For OpenCode, follow the setup guide, including project AGENTS instructions and configuration choices.

macOS and Linux

You need a terminal with curl, Internet access and trusted HTTPS certificates. The launcher finds or prepares a supported Python environment. See prerequisite setup for macOS or Linux if a command is missing.

Review the installer, then run:

curl -fsSL https://github.com/Damel91/flower-mcp/releases/download/v0.14.0/install.sh | bash

Choose your client when prompted, or choose installation without registration.

Windows

Use Windows PowerShell 5.1+ or PowerShell 7, with Internet access and trusted HTTPS certificates. This route uses Invoke-WebRequest; curl is not required. See the Windows prerequisites.

Invoke-WebRequest -UseBasicParsing -Uri "https://github.com/Damel91/flower-mcp/releases/download/v0.14.0/install.ps1" -OutFile ".\install.ps1"
# Review install.ps1, then run:
powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\install.ps1

The execution-policy override applies only to that process. Follow the prompts to select your client or install without registration.

Other installation options

Start your first project

Reload the registered client and approve its MCP connection. The registered client starts Flower; a manual installation needs its client connection configured first. Then open the repository you want to work on and give your agent this request:

Set up Flower MCP for this repository. Run the bootstrap_command returned by the installer and follow its output to integrate Flower's instructions into this project's AGENTS.md, preserving its existing rules. Verify the MCP connection and explicitly select the intended lifecycle project; ask me if the choice is ambiguous. If Flower has no projects yet, I authorize creating one for this repository. Help me describe the first scenario and present a roadmap for my confirmation before coding.

The AGENTS.md step is already part of the guided setup. A fresh installation returns bootstrap_command with the installed executable's absolute path and bootstrap argument. The command prints the bundled engineering template; your agent creates or merges its Flower section in the intended project's AGENTS.md. The installer itself does not edit project files. Make sure your client loads those project instructions.

For a manual installation, ask the agent to run the installed flower-mcp executable with bootstrap, using its absolute path. The bootstrap guide provides detailed prompts and examples. An upgrade preserves the existing profile and guides the agent to recover its project; it does not repeat first-project setup.

Open your project in the browser

When Flower runs with streamable HTTP, it also serves a dashboard on the same computer. Open /dashboard and sign in with the local operating-system account that owns your Flower profile. Create and browse projects, read retained documents, or prepare profile settings. Use Backup to save and manage SQLite copies, or export a single project. Backup → Ripristina archivio restores either ZIP into a new, separate profile.

To delete a project, enter its exact ID and your local account password. See the dashboard guide for startup, access and recovery. A stdio connection alone has no browser dashboard. To open the dashboard from another device, save Accesso dalla LAN in Impostazioni Flower and restart the same profile. Flower prints the available HTTPS links. LAN access guide

Optional LLMs and providers

Your coding agent can use Flower's core without installing an internal model. For additional assistance, Flower supports bounded internal semantic roles, host-executed semantic assignments and optional technical providers. Each route has its own prerequisites and evidence provenance.

See advanced configuration and internal inference setup to choose the integration you need.

Learn more

What you want to do

Where to go

Follow a complete project scenario

English walkthrough · Italiano

Understand plans, verification and handovers

Essential concepts

Browse projects and read retained documents

Local browser dashboard

Explore the public tools

Tool map

Resume work or reconcile offline results

Continuous work and recovery

Connect project architecture and technical providers

Integration guide

Install, update or recover a profile

Installation · Upgrading · Backups and recovery

See changes and compatibility notes

Releases

Read the walkthrough offline

Local readers

About the project

Flower is a personal project by Davide Mele, developed outside his professional work. He designed the system, defined requirements and guided verification; coding agents, primarily Codex, carried out repository investigation, implementation, tests and documentation. Read about the development method.

A real project managed with Flower is llama-runtime. Its requirements, milestones, implementation plans, verification evidence and handovers are maintained in Flower's project ledger.

Flower remains in testing. Its gates govern lifecycle operations; the coding agent and its host remain responsible for code, execution and reporting. Host-declared evidence keeps that provenance and is not an independent source audit. See the sources and limits. Report problems in the issue tracker, including your version, operating system, client and the affected operation. Keep credentials and private project data out of reports.

License and compatibility

Apache-2.0, with attribution in NOTICE. The public command is flower-mcp; the Python distribution flow-of-work-mcp, import package flow_of_work_mcp and MCP prefix fow_* retain their existing names.

Available Tools

37 tools
fow_accept_milestoneA

Record governed acceptance of an eligible milestone using actual acceptance evidence after its required verification and campaign gates. Single operation; call directly without an operation argument. Prerequisites: Use an existing eligible milestone and actual governed acceptance evidence after required verification/campaign closure. Effects: Appends explicit acceptance authority under policy guards; never substitutes agent completion for acceptance. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_accept_milestone","operation_name":"call"}).

Inputs: actor (required), project_id (required), milestone_id (required), acceptance_evidence (required), +1 more. Returns: object

fow_architectureA
Destructive

Define and select the project technical architecture: components, interfaces and engineering decisions. Inspect current authority, propose a complete revision, then explicitly adopt it. Route with operation: inspect, propose, adopt. Prerequisites: Use an existing project and current architecture revision. Effects: propose stores an immutable candidate; adopt changes selected engineering authority. No model/provider call, coding or acceptance. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_architecture","operation_name":"inspect"}).

Inputs: operation (required), project_id (required), actor, payload, +1 more. Returns: object

fow_assuranceA
Destructive

Record and inspect software assurance findings, reassess them against current intent, associate corrective packets and request guarded change acceptance using actual evidence. Route with operation: record_finding, get_finding, reassess_intent, set_finding_disposition, link_fixing_packet, request_change_acceptance. Prerequisites: Investigate current requirements/goals and evidence before classifying a finding or correction. Effects: Records findings, semantic reassessment, dispositions, fixing-packet links and guarded change acceptance. Reassessment is engineer-authored; completion, verification and acceptance remain separate. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_assurance","operation_name":"record_finding"}).

Inputs: actor (required), operation (required), project_id (required), title, +20 more. Returns: object

fow_audit_phaseA

Compare current requirement traceability with the previous snapshot of a named scope and retain the resulting phase audit as a durable local job. Single operation; call directly without an operation argument. Prerequisites: Use a defined requirement scope; retain the same requirement selection when reusing its scope_id. Effects: Schedules a durable local audit of traceability changes since the prior scope snapshot. No model/provider call or lifecycle transition; audit evidence is distinct from acceptance. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_audit_phase","operation_name":"call"}).

Inputs: actor (required), scope_id (required), project_id (required), request_id, +1 more. Returns: object

fow_bindingsA
Destructive

Associate an existing lifecycle project with a coding host or optional configured provider through portable versioned JSON receipts. Inspect/export current associations or explicitly import and replace one. Route with operation: inspect, export, import. Prerequisites: Use an existing project; provider receipts may select already configured routes only. Effects: inspect/export read associations; import records idempotent canonical associations and requires a reason for replacement. No endpoint, credentials, commands or restart are supplied by receipts. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_bindings","operation_name":"inspect"}).

Inputs: operation (required), project_id (required), actor, host_id, +5 more. Returns: object

fow_bootstrapA
Destructive

Turn stakeholder scenarios into recorded lifecycle intent and an explicitly confirmed roadmap, then track correspondence, progress choices and completion of that bootstrap cycle. Route with operation: bind_implementation_provider, provider_binding_state, list_provider_bindings, start, resume, state, record_intake, record_contradiction, confirm_intake, derive_behavior, complete, cancel, guidance, record_answer, record_correspondence, roadmap, confirm_roadmap, record_continuation. Prerequisites: Select the real project/current bootstrap. Start from stakeholder scenarios and record only governing answers. Effects: Records intake, correspondence, confirmation and continuation; complete/cancel closes a cycle. Provider-binding replacement and optional behavior derivation are explicit operations. Never invent stakeholder approval or execute unclear scope. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_bootstrap","operation_name":"bind_implementation_provider"}).

Inputs: actor (required), operation (required), project_id (required), path, +20 more. Returns: object

fow_campaign_advanceA
Destructive

Perform bounded deterministic progression of an existing verification campaign until the next semantic, evidence or provider boundary requires attention. Implicit advance operation; transition_budget bounds the call. Prerequisites: Use an existing campaign, current scope and the provider/evidence prerequisites of its next boundary. Effects: Runs bounded deterministic lifecycle transitions, may deliver admitted provider work, then returns one semantic/evidence/provider boundary. It does not invent answers or acceptance. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_campaign_advance","operation_name":"advance"}).

Inputs: actor (required), project_id (required), request_id (required), change_id, +2 more. Returns: object

fow_campaign_authorA
Destructive

Define and revise a verification campaign: scope, cases, obligations, behavioral Oracles, source attestations and explicit materialization or promotion authority. Route with operation: start, edit_scope, add_case, edit_case, remove_case, reorder_cases, decide_obligation, bind_obligation, author_oracle, answer_question, attest_source, authorize_materialization, retry_provider_rejection, authorize_promotion, accept_exception, cancel. Prerequisites: Use an existing governed change and current campaign fingerprint for edits. Effects: Authors cases/obligations/Oracle definitions, attestations and explicit provider materialization/promotion commands. Removal/cancellation/exception changes current authority; source files and provider actions require their declared prerequisites. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_campaign_author","operation_name":"start"}).

Inputs: actor (required), operation (required), project_id (required), request_id (required), +29 more. Returns: object

fow_campaign_inspectA
Read-onlyIdempotent

Inspect one campaign scope, cases, obligations, Oracle contracts, attestations, evidence, residuals or history without progressing it. Route with view: summary, working_sheet, cases, obligations, oracles, constructibility, oracle_ir, attestation, evidence, residuals, history. Prerequisites: Use the campaign ID and optional owning change for scope validation. Effects: Read-only summary, cases, Oracle/evidence/residuals or history page. No provider/model calls, materialization or acceptance. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_campaign_inspect","operation_name":"summary"}).

Inputs: project_id (required), view, limit, offset, +2 more. Returns: object

fow_capabilitiesA
Read-onlyIdempotent

Discover what Flower can do and how to call it: bounded tool summary, progressive workflow recipes, exact operation inputs/examples or the diagnostic catalog. Route with view=summary|recipe|operation|docs|full; recipe needs recipe_name, operation needs operation_tool and operation_name. Prerequisites: No project, database mutation or optional provider is needed. Effects: Read-only progressive discovery; returns exact required/optional fields, accepted selector values, examples and guidance. Does not execute recipes. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_capabilities","operation_name":"call"}).

Inputs: view, recipe_name, operation_name, operation_tool. Returns: object

fow_changeA
Destructive

Record a governed change and manage its packet readiness, engineering questions, evidence reconciliation, dependencies and risk dispositions. Author the executable packet plan with fow_packet_author. Route with operation: create_change, get_change, link_change_milestone, set_packet_target_state, evaluate_packet_readiness, start_packet_construction_audit, get_packet_construction_audit, initialize_packet_reconciliation, get_packet_reconciliation, declare_packet_evidence_claim, supersede_packet_evidence_claim, import_packet_evidence_snapshot, collect_packet_evidence_snapshot, reconcile_packet_evidence, disposition_packet_evidence_residual, answer_packet_question, waive_packet_question, block_packet_question, derive_packet_pressure, get_packet_pressure, accept_residual_risk, revise_packet, link_dependency, transition_packet. Prerequisites: Use existing project/change/packet identities and the selected ordinary authority/evidence contract. Effects: Records governed changes, readiness, reconciliation and risk/question dispositions. Some explicit evidence collection/audit routes use configured providers or inference; transitions/supersession can invalidate current authority. Work plans are authored with fow_packet_author. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_change","operation_name":"create_change"}).

Inputs: actor (required), operation (required), project_id (required), title, +74 more. Returns: object

fow_create_projectA
Idempotent

Register a uniquely identified local lifecycle project before recording its requirements, goals and implementation work. This creates lifecycle authority rather than repository scaffolding. Single operation; call directly without an operation argument. Prerequisites: Choose a unique lifecycle project ID and human-readable name. Effects: Creates canonical local project authority and its audit event. Repeated creation of the same project_id rejects before further effects; request_id is inert. Does not inspect or create repository files. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_create_project","operation_name":"call"}).

Inputs: name (required), actor (required), project_id (required), request_id. Returns: object

fow_external_workA
Destructive

Hand a complete revision-bound packet to an external coding agent, export its executable Markdown plan, derive dependency-ordered TODOs and reconcile declared outcomes. Optional provider execution is a separate explicitly selected route. Route with operation: set_mode, select_executor, negotiate_provider, upgrade_validation, criteria, reconcile_criteria, add_criterion, edit_criterion, remove_criterion, validation, provider_validation, export_plan, todo, report_outcome, reconcile_outcome. Prerequisites: Use an existing packet/plan and issued authority. Select exactly one executor before execution. Effects: Reads derive criteria/readiness/TODO without executing code. Mutations record selection, criterion authority, artifacts and host outcomes; negotiate_provider alone explicitly probes optional provider support. Reporting completion does not verify or accept it. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_external_work","operation_name":"set_mode"}).

Inputs: change_id (required), operation (required), packet_id (required), project_id (required), +3 more. Returns: object

fow_generate_artifactsA

Render and retain project lifecycle documents using an existing artifact profile in a durable local job. The host publishes or saves returned artifacts separately. Single operation; call directly without an operation argument. Prerequisites: Select an existing configured artifact profile and project. Effects: Schedules local rendering and stores immutable artifact generations from ledger/profile data. No model/provider or repository publication is performed. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_generate_artifacts","operation_name":"call"}).

Inputs: actor (required), profile_id (required), project_id (required), request_id. Returns: object

fow_get_artifactsA
Read-onlyIdempotent

Retrieve retained artifact generations and optionally their document contents, filtered by generation or artifact kind. Single operation; call directly without an operation argument. Prerequisites: Select an existing project; generation_id optionally filters to one retained generation. Effects: Read-only stored metadata and optional content from all retained generations when generation_id is omitted. The coding host saves returned content using its own file tools. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_get_artifacts","operation_name":"call"}).

Inputs: project_id (required), artifact_kind, generation_id, include_content. Returns: object

fow_get_jobA
Read-onlyIdempotent

Retrieve the status, result or failure of one previously scheduled durable job without starting or retrying it. Single operation; call directly without an operation argument. Prerequisites: Use the durable job ID returned when work was scheduled. Effects: Read-only job status/result/error; polling does not start or retry execution. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_get_job","operation_name":"call"}).

Inputs: job_id (required), project_id (required). Returns: object

fow_get_requirementA
Read-onlyIdempotent

Retrieve one existing requirement, its current canonical state and retained revision history. Single operation; call directly without an operation argument. Prerequisites: Use an existing canonical requirement ID within its project. Effects: Read-only requirement state and immutable revision history; no model/provider calls. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_get_requirement","operation_name":"call"}).

Inputs: project_id (required), requirement_id (required). Returns: object

fow_goalA

Describe intended software behavior as use cases, ordered sequences and behavioral expectations, then link and inspect those goal nodes or derive requirement candidates. Route with operation: view, add_use_case, add_sequence, add_behavioral_expectation, link, derive_requirement_candidates. Prerequisites: Use an existing project and canonical graph-node identities for links. Effects: view reads the graph; authoring appends use cases/sequences/expectations/links. Candidate derivation uses the recorded goal graph without inference; candidates do not silently become requirements. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_goal","operation_name":"view"}).

Inputs: operation (required), project_id (required), view, actor, +22 more. Returns: object

fow_ground_intentA

Run the configured internal intention-grounding workflow to compare selected goals with implementation evidence. For an external host assignment use fow_semantic. Single operation; call directly without an operation argument. Prerequisites: Requires configured internal inference and the implementation/source provider; host mode uses fow_semantic. Effects: Schedules bounded grounding and records declared audit evidence from actual optional integrations. Missing prerequisites block the job; grounding is not acceptance. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_ground_intent","operation_name":"call"}).

Inputs: actor (required), project_id (required), goal_node_ids (required), request_id, +1 more. Returns: object

fow_handoverA

Read coherent project progress and lifecycle context or retain a durable handover snapshot that another agent can inspect and resume. Route with operation: create_handover, get_handover, resume_context, ledger_projection, project_state_snapshot, project_progress. Prerequisites: Select current project scope or a retained handover ID. Effects: Read projections are inert; create_handover stores a coherent durable snapshot. It does not execute, accept or rewrite historical work. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_handover","operation_name":"create_handover"}).

Inputs: operation (required), project_id (required), actor, limit, +10 more. Returns: object

fow_import_srsA

Import an eligible local Markdown SRS as the initial canonical requirement baseline, preserving validated source provenance. Existing baseline changes use fow_revise_srs_baseline. Single operation; call directly without an operation argument. Prerequisites: Supply a structurally/semantically eligible initial local SRS under the selected profile. Effects: Validates source provenance and atomically imports the initial canonical baseline. Existing baseline replacement uses revise_srs_baseline; import is not stakeholder acceptance. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_import_srs","operation_name":"call"}).

Inputs: actor (required), project_id (required), source_path (required), standard_profile (required), +1 more. Returns: object

fow_interactionB
Destructive

Connect this conversation to its durable lifecycle project, discover available work and select one bounded work surface using the issued choices and frame. Route with operation: status, discover, open, select_project, switch_project, clear_project, select, switch, clear, frame, resolve, goal_hook. Prerequisites: Supply the host's stable interaction_session_ref and explicit selection intent. Effects: Persists conversation context, lenses and continuations. Optional configured discovery providers may be consulted; selecting a surface does not authorize its work. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_interaction","operation_name":"status"}).

Inputs: interaction_session_ref (required), area, actor, limit, +12 more. Returns: object

fow_list_jobsA
Read-onlyIdempotent

List the durable jobs already recorded for one lifecycle project without scheduling additional work. Single operation; call directly without an operation argument. Prerequisites: Select an existing project. Effects: Read-only durable job inventory; does not schedule, retry or cancel jobs. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_list_jobs","operation_name":"call"}).

Inputs: project_id (required). Returns: object

fow_packet_advanceA
Destructive

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"}).

Inputs: actor (required), packet_id (required), project_id (required), request_id (required), +5 more. Returns: object

fow_packet_authorA
Destructive

Define the bounded implementation work in a packet: complete instructions, stable plan units, dependencies, producer/consumer contracts and checks. Resolve engineering questions through ordinary authoring before execution. Route with operation: start_packet, revise_packet, replace_plan, resolve_questions, answer_gate, add_unit, revise_unit, remove_unit, rebind_unit, set_dependencies. Prerequisites: Use current specification/plan revisions and ordinary packet authority; investigate and close semantic gaps before dispatch. Effects: Creates/revises packets and complete ordered units/contracts/dependencies. Removal/replacement changes current plan authority; provider-target deltas may be queued, without executing coding work. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_packet_author","operation_name":"start_packet"}).

Inputs: actor (required), project_id (required), request_id (required), unit, +34 more. Returns: object

fow_packet_inspectA
Read-onlyIdempotent

Inspect a packet scope, executable units, current gates, requirements, working sheet or retained history without advancing or executing it. Route with view: summary, units, gates, working_sheet, history, requirements. Prerequisites: Use the packet ID and owning change when needed for unambiguous address resolution. Effects: Read-only bounded packet authority/units/gates/history. Provider capability projection is local binding inspection; no provider RPC or coding execution. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_packet_inspect","operation_name":"summary"}).

Inputs: packet_id (required), project_id (required), view, limit, +3 more. Returns: object

fow_promote_milestoneA

Create planned milestone scope from canonical requirements, dependencies and entry/exit/risk policies. Actual result acceptance uses fow_accept_milestone. Single operation; call directly without an operation argument. Prerequisites: Supply canonical requirements, dependency closure and planning entry/exit/risk policies. Effects: Records planned milestone scope. Nonempty acceptance_evidence is rejected; promotion does not accept the result. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_promote_milestone","operation_name":"call"}).

Inputs: name (required), actor (required), project_id (required), exit_policy (required), +6 more. Returns: object

fow_record_verificationA

Record evidence actually obtained for a requirement, including verification method, outcome, reference and declared metadata. This records a result rather than running a test. Single operation; call directly without an operation argument. Prerequisites: Use an existing requirement and evidence actually obtained by the declared verification method. Effects: Appends declared evidence/provenance. It does not execute tests, audit a provider or grant acceptance. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_record_verification","operation_name":"call"}).

Inputs: actor (required), outcome (required), reference (required), project_id (required), +4 more. Returns: object

fow_register_requirementA

Record one observable software requirement and its source in the selected lifecycle project. Use the returned requirement ID for goals, milestone scope and verification. Single operation; call directly without an operation argument. Prerequisites: Use an existing project and an observable requirement statement. Effects: Appends canonical requirement authority with declared source anchor and receipt; does not implement or accept it. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_register_requirement","operation_name":"call"}).

Inputs: actor (required), title (required), category (required), rationale (required), +4 more. Returns: object

fow_revise_requirementA
Destructive

Change the statement or classification of an existing requirement by appending a canonical revision. Keep intent changes explicit so downstream evidence can be reconciled. Single operation; call directly without an operation argument. Prerequisites: Investigate the existing requirement and authorize any actual change of intent first. Effects: Appends an immutable revision; downstream currentness/closure may change. Existing evidence is not rewritten or made current. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_revise_requirement","operation_name":"call"}).

Inputs: actor (required), title (required), category (required), rationale (required), +5 more. Returns: object

fow_revise_srs_baselineA
Destructive

Apply a source-proven revision to the current SRS baseline, classifying changes and retaining approval requirements and immutable history. Single operation; call directly without an operation argument. Prerequisites: Use the exact current previous_baseline_id, changed local source and any required governed approval. Effects: Classifies source-proven changes and appends a baseline revision; impacted authority/evidence may require reconciliation. Does not silently accept drift. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_revise_srs_baseline","operation_name":"call"}).

Inputs: actor (required), project_id (required), source_path (required), standard_profile (required), +3 more. Returns: object

fow_runA
Destructive

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"}).

Inputs: actor (required), operation (required), project_id (required), title, +18 more. Returns: object

fow_semanticA

Prepare bounded semantic assignments for an external host or configured internal model, validate their submitted results and separately adopt their audit evidence. Supported roles are SRS semantic validation and intention grounding. Route with operation: inventory, prepare, inspect, submit, adopt, execute_internal. Prerequisites: Use inventory, then prepare a supported role in host or internal mode; internal needs configured inference. Effects: prepare persists a prompt/authority snapshot; submit validates executor results; adopt records declared provenance. execute_internal explicitly invokes inference. SRS preparation/inspection reads the selected source file. Observed-behavior drafting is unsupported. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_semantic","operation_name":"inventory"}).

Inputs: operation (required), project_id (required), role, actor, +10 more. Returns: object

fow_set_requirement_lifecycleA
Destructive

Move an existing requirement to a policy-permitted lifecycle state with its reason and any required approval reference. Single operation; call directly without an operation argument. Prerequisites: Use an existing requirement and the approval reference required by its transition policy. Effects: Mutates lifecycle state under ordinary guards; retirement/rejection can invalidate active authority. Does not infer human approval. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_set_requirement_lifecycle","operation_name":"call"}).

Inputs: actor (required), reason (required), project_id (required), requirement_id (required), +3 more. Returns: object

fow_traceabilityA
Read-onlyIdempotent

Inspect how current requirements, milestone scope and recorded verification evidence correspond. Read bounded pages or retrieve one original evidence body with audit detail. Single operation; call directly without an operation argument. Prerequisites: Select a project and optionally a milestone or exact evidence ID. Effects: Read-only bounded traceability/evidence with pagination; no provider/model execution or authority mutation. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_traceability","operation_name":"call"}).

Inputs: project_id (required), limit, offset, evidence_id, +2 more. Returns: object

fow_validate_srsA

Check a local Markdown software-requirements document structurally against a supported profile in a durable job. Semantic assignment validation is exposed separately by fow_semantic. Single operation; call directly without an operation argument. Prerequisites: Supply a readable local Markdown SRS and supported standard_profile. Effects: Schedules durable structural validation and reads the source. Semantic checks use fow_semantic; validation alone does not import or accept a baseline. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_validate_srs","operation_name":"call"}).

Inputs: actor (required), project_id (required), source_path (required), standard_profile (required), +1 more. Returns: object

fow_what_nextA
Read-onlyIdempotent

Find the next bounded lifecycle action from current packet gates, dependencies, requirements and evidence. Reading this projection does not execute the suggested work. Single operation; call directly without an operation argument. Prerequisites: Select existing project/scope and optional milestone, then follow returned bounded pages. Effects: Read-only next-work projection from current authority/dependencies; no code execution or provider probes. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_what_next","operation_name":"call"}).

Inputs: project_id (required), limit, offset, scope_id, +2 more. Returns: object

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    A3.7/5.0

    Scored across 37 tools

    Disambiguation4/5

    Most tools target a distinct lifecycle concern, and descriptions include explicit cross-references that steer agents away from overlaps (e.g. fow_ground_intent vs fow_semantic, fow_external_work vs fow_packet_advance). However, the dense cluster of packet/change/run/campaign/external-work tools has subtle boundaries that an agent could still misselect, so it is not perfectly unambiguous.

    Naming Consistency4/5

    All tools share a consistent fow_ prefix and snake_case, with single-operation tools using a clear verb_noun pattern (fow_create_project, fow_get_requirement, fow_revise_requirement) and multi-operation routers named by domain (fow_change, fow_assurance, fow_packet_author). The deliberate router-vs-verb distinction is readable and mostly consistent, with only minor deviation.

    Tool Count3/5

    At 37 tools the surface is heavy and exceeds the comfortable range, which raises cognitive load for an agent. That said, the domain (a full software lifecycle governance engine) is genuinely vast and many tools are multi-operation dispatchers that consolidate dozens of underlying actions, so the count is defensible rather than inflated.

    Completeness5/5

    The surface covers an unusually full lifecycle: project creation, requirement CRUD and lifecycle, verification evidence, traceability, goals, SRS validate/import/revise, milestone promotion/acceptance, audits, artifact generation, job retrieval, bootstrap, assurance, run tracking, handover, packet authoring, and verification campaigns. CRUD and lifecycle coverage across these domains appears complete with no obvious dead ends.

    Maintenance

    ActivityNo data
    ResponsivenessOutdated data

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      Not graded
      quality
      C
      maintenance
      Enables coding agents to store, recall, and manage persistent memory across sessions through MCP tools, with reviewable handoffs and SQLite-backed local storage.
      1
      MIT
    • F
      license
      A
      quality
      B
      maintenance
      Enables coding agents to track and coordinate project work through a shared SQLite ledger, including task plans, session ancestry, claims, work locations, blockers, and commits via MCP tools.
      9
      -
    • A
      license
      Not graded
      quality
      C
      maintenance
      Enables coding agents to persist and resume shared working state—tasks, progress, decisions, commands, tests, checkpoints, and handoffs—backed by SQLite while keeping Git authoritative for files and repository state.
      MIT