Flower MCP

Overview Schema Source Related Servers Discussions Admin

fow_architecture

Destructive

Define and select project technical architecture by inspecting current authority, proposing a complete revision, and adopting it as the new engineering authority.

Instructions

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

Input Schema

TableJSON Schema

Name	Required	Description
`actor`	No	Identity of the human or agent recording this action; retain the original identity when replaying its request.
`payload`	No	Architecture operation input: inspect selects revision/kind/page; propose supplies expected_revision and a complete definition; adopt selects expected_revision/revision and rationale. Proposals become authority only through adopt. Required by: propose, adopt. Exact required/optional dotted fields and guidance: fow_capabilities(view=operation, operation_tool=fow_architecture, operation_name=<selected route>).
`operation`	Yes	Operation selector for this multiplexer; use a canonical route listed below. Canonical values: inspect, propose, adopt.
`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.

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

Added value: +"Operation selector for this multiplexer; use a canonical route listed below. Canonical values: inspect, propose, adopt."

addedInput schema / properties / operation / examples
```
Added value: +[
+  "inspect"
+]
```

addedInput schema / properties / payload / description

Added value: +"Architecture operation input: inspect selects revision/kind/page; propose supplies expected_revision and a complete definition; adopt selects expected_revision/revision and rationale. Proposals become authority only through adopt. Required by: propose, adopt. Exact required/optional dotted fields and guidance: fow_capabilities(view=operation, operation_tool=fow_architecture, operation_name=<selected route>)."

addedInput schema / properties / payload / examples

Added value: +[
+  {
+    "kind": "all",
+    "limit": 20,
+    "offset": 0,
+    "revision": 0
+  }
+]

addedInput schema / properties / project_id / description

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

addedInput schema / properties / request_id / description

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

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?

Adds real behavior beyond the annotations: propose produces an 'immutable candidate' while adopt is what 'changes selected engineering authority', and it scopes out work ('No model/provider call, coding or acceptance'). This complements the destructiveHint=true/idempotentHint=false annotations by telling the agent which route actually mutates authority. It does not spell out immutability/reversibility of an adopted revision, keeping it below 5.

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-loads the purpose, then routes, then prerequisites, then effects - a sensible ordering with no filler sentences. The repeated pointer to fow_capabilities (once in the description and again in the payload schema) duplicates a help-hint already carried by structured fields, which slightly dilutes it.

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?

An output schema exists, so return values need not be described, and the description covers routing, prerequisites, and side effects for a destructive multiplexer. What is missing is any note on what 'current authority' means operationally (how the agent obtains the expected_revision it must pass on propose/adopt).

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

Parameters4/5

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

With 100% schema coverage the baseline is 3, but the description adds route-specific payload meaning ('inspect selects revision/kind/page; propose supplies expected_revision and a complete definition; adopt selects expected_revision/revision and rationale'), which the schema does not spell out per route. The actor/request_id retry identity is left to the schema, so it is not a 5.

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 ('Define and select the project technical architecture: components, interfaces and engineering decisions') and enumerates the three routes, so the subject matter is unmistakable. It never names a sibling tool (e.g. fow_goal, fow_semantic, fow_bindings) to differentiate scope, so it stops short of a 5.

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 explicit routing ('Route with operation: inspect, propose, adopt') and prerequisites ('Use an existing project and current architecture revision'), which is clear context for when this tool applies. It does not state when NOT to use it or point at an alternative tool, so it lacks the exclusion/alternative element of a 5.

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