Flower MCP

Overview Schema Source Related Servers Discussions Admin

fow_set_requirement_lifecycle

Destructive

Transition an existing requirement to a policy-permitted lifecycle state, recording the reason and any required governed approval reference.

Instructions

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

Input Schema

TableJSON Schema

Name	Required	Description
`actor`	Yes	Identity of the human or agent recording this action; retain the original identity when replaying its request.
`reason`	Yes	Explicit reason for the transition, cancellation or continuation action.
`project_id`	Yes	Canonical lifecycle project ID. Select the existing project explicitly; development Markdown authorities are separate from runtime projects.
`request_id`	No	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.
`requirement_id`	Yes	Existing canonical requirement identity, as returned by registration/import.
`lifecycle_status`	Yes	Requested canonical requirement lifecycle state, subject to normal transition/approval policy. Canonical values: planned, implemented, partial, removed.
`governed_approval_reference`	No	Reference to explicit governed approval required for this lifecycle transition or baseline change.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv0.5.1Oct 16, 2026

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 / governed_approval_reference / description

Added value: +"Reference to explicit governed approval required for this lifecycle transition or baseline change."

addedInput schema / properties / lifecycle_status / description

Added value: +"Requested canonical requirement lifecycle state, subject to normal transition/approval policy. Canonical values: planned, implemented, partial, removed."

addedInput schema / properties / project_id / description

Added value: +"Canonical lifecycle project ID. Select the existing project explicitly; development Markdown authorities are separate from runtime projects."

addedInput schema / properties / reason / description

Added value: +"Explicit reason for the transition, cancellation or continuation action."

addedInput schema / properties / request_id / description

Added value: +"Caller-owned retry identity. For receipted mutations replay the same actor and contents; changed contents can conflict. Inspect exact operation help for its receipt policy."

addedInput schema / properties / requirement_id / description

Added value: +"Existing canonical requirement identity, as returned by registration/import."

First observedv0.1.0Oct 16, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Annotations declare destructive=true and idempotent=false, and the description meaningfully extends them: ordinary guards apply, retirement/rejection can invalidate active authority, and human approval is not inferred by the tool. That tells the agent the blast radius of a state change, which the annotations alone do not.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded one-line purpose followed by labeled Prerequisites and Effects blocks that are easy to scan. The trailing capabilities-help pointer is useful but slightly boilerplate-y, keeping it short of a flawless 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, non-idempotent mutation with 7 parameters and an output schema, the description covers prerequisites, mutation effects, approval expectations, and even points to exact operation help for receipt/retry policy. Nothing an agent needs before calling is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents actor identity, reason, project vs. requirement IDs, request_id replay semantics, and the canonical lifecycle_status values. The description only restates that a reason and a policy-required approval reference accompany the move, adding negligible syntax or format detail beyond the schema.

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 specific verb+resource: moving an existing requirement to a policy-permitted lifecycle state, with reason and approval reference. It also clarifies the invocation shape ('single operation; call directly without an operation argument'), which separates it from multi-route siblings. It stops short of naming the nearest neighbor (fow_revise_requirement), so the boundary is inferable rather than explicit.

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

Usage Guidelines4/5

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

Gives a clear usage context plus prerequisites ('use an existing requirement and the approval reference required by its transition policy') and a call-directly instruction. No alternatives or when-not-to-use conditions are named, so it is clear context without exclusions.

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