Flower MCP

Overview Schema Source Related Servers Discussions Admin

fow_register_requirement

Records one observable software requirement and its source in a selected lifecycle project, returning the requirement ID for goals, milestone scope, and verification.

Instructions

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

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.
`title`	Yes	Short human-readable title of the authored requirement, finding, packet, run step or campaign.
`category`	Yes	Requirement or behavioral-expectation category recognized by the current lifecycle policy.
`rationale`	Yes	Concrete reasoning supporting this ordinary mutation, decision or selected authority.
`statement`	Yes	Precise requirement or behavioral expectation describing an observable obligation.
`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.
`source_anchor`	No	String source locator/reference (path, section, entity or revision as applicable) linking authority to its originating material; this public input is not a structured object.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed8 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 / category / description

Added value: +"Requirement or behavioral-expectation category recognized by the current lifecycle policy."

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

Added value: +"Concrete reasoning supporting this ordinary mutation, decision or selected authority."

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

Added value: +"String source locator/reference (path, section, entity or revision as applicable) linking authority to its originating material; this public input is not a structured object."

addedInput schema / properties / statement / description

Added value: +"Precise requirement or behavioral expectation describing an observable obligation."

addedInput schema / properties / title / description

Added value: +"Short human-readable title of the authored requirement, finding, packet, run step or campaign."

First observedv0.1.0Oct 16, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations cover the safety profile (non-readOnly, non-destructive, non-idempotent), and the description adds real behavior beyond that: it appends 'canonical requirement authority with declared source anchor and receipt' and clarifies it does not implement or accept the requirement. This is meaningful context layered on top of the annotations.

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

Conciseness5/5

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

Front-loads the core action in the first sentence, then organizes Prerequisites and Effects as labeled lines, closing with a precise help pointer. Every sentence carries information; nothing is redundant.

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

Completeness4/5

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

With an output schema present, return-value explanation is unnecessary, and the description correctly points the agent at the returned requirement ID. Prerequisites, effects, and single-operation guidance are all present. Minor gap: no explicit pairing to the nearest siblings (get/revise requirement).

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 all 8 parameters (project_id, statement, rationale, actor, request_id, source_anchor, etc.). The description only alludes to source_anchor and project implicitly, adding no syntax or format detail beyond the schema. Baseline 3 is appropriate.

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 and resource: 'Record one observable software requirement and its source in the selected lifecycle project.' It is distinguishable from fow_revise_requirement by the 'record' framing, though it never names that sibling explicitly to draw the boundary.

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 concrete usage context: 'Use the returned requirement ID for goals, milestone scope and verification' plus an explicit Prerequisites line ('existing project and an observable requirement statement') and a negative scope ('does not implement or accept it'). No sibling alternatives (e.g. revise/import) are named, so it stops short of a 5.

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