Flower MCP
Flower MCP provides persistent software lifecycle management for coding agents, keeping requirements, plans, decisions, evidence, and handovers connected.
Discover capabilities, bootstrap projects, select lifecycle context, and manage host/provider bindings.
Author and revise requirements, goals/use cases, SRS baselines, architecture decisions, and milestone scope.
Create governed changes; author, inspect, and advance implementation packets; track run steps and dependencies.
Export external work plans, select executors, reconcile outcomes, and negotiate optional providers.
Author and advance verification campaigns with cases, obligations, Oracles, evidence, and exceptions.
Record assurance findings, reassess intent, link corrective packets, and request change acceptance.
Record verification evidence, traceability, phase audits, next-work guidance, and milestone acceptance.
Generate/retrieve artifacts; create/read handovers; inspect project state, progress, jobs, and resume context.
Run optional semantic jobs for SRS validation, intention grounding, and provider-assisted analysis.
In HTTP mode, use a local browser dashboard to browse projects/documents, manage profile settings, and back up/restore data.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Flower MCP resume the handover state for the payment service"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
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 | bashChoose 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.ps1The execution-policy override applies only to that process. Follow the prompts to select your client or install without registration.
Other installation options
Manual installation: use a verified release wheel or install from source. These routes require Python 3.11+ with SSL,
venvandensurepip; cloning the repository also requires Git.Google clients: see Antigravity and Gemini CLI setup.
Containers: see container and Glama setup for server startup and persistent storage.
Already installed? Use the SQLite-preserving upgrade guide with your existing environment, profile and data paths. The installer offers
--upgrade --dry-runand backs up SQLite and YAML before changing packages.
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 | |
Understand plans, verification and handovers | |
Browse projects and read retained documents | |
Explore the public tools | |
Resume work or reconcile offline results | |
Connect project architecture and technical providers | |
Install, update or recover a profile | |
See changes and compatibility notes | |
Read the walkthrough offline |
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 toolsfow_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_architectureADestructive
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_assuranceADestructive
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_bindingsADestructive
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_bootstrapADestructive
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_advanceADestructive
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_authorADestructive
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_inspectARead-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_capabilitiesARead-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_changeADestructive
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_projectAIdempotent
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_workADestructive
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_artifactsARead-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_jobARead-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_requirementARead-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_interactionBDestructive
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_jobsARead-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_advanceADestructive
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_authorADestructive
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_inspectARead-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_requirementADestructive
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_baselineADestructive
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_runADestructive
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_lifecycleADestructive
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_traceabilityARead-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_nextARead-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
Scored across 37 tools
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.
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.
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.
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
Related MCP Connectors
One shared project for a team's coding agents: decisions, a task board and handoffs.
Project memory for coding agents: requirements, decisions, code graph and delivery telemetry.
Project memory, documentation and controlled secret access for AI coding agents.
Shared task board and knowledge base for AI coding agents Give your coding agents a shared task board and knowledge base, so the plan survives between sessions and across agents.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceEnables coding agents to store, recall, and manage persistent memory across sessions through MCP tools, with reviewable handoffs and SQLite-backed local storage.1MIT
- AlicenseAqualityCmaintenanceEnables coding agents to persist notes, decisions, requirements, and learnings per project in SQLite and retrieve them across sessions via search and status tools.3MIT
- FlicenseAqualityBmaintenanceEnables 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-
- AlicenseNot gradedqualityCmaintenanceEnables 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