Flower MCP

Overview Schema Source Related Servers Discussions Admin

fow_audit_phase

Compare current requirement traceability against a scope's prior snapshot and save the phase audit as a durable local job for later review.

Instructions

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

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "project_id": "<project_id>",
      "scope_id": "<scope_id>",
      "actor": "<actor>"
    },
    "name": "fow_audit_phase"
  }
}

Input Schema

Name	Required	Description
`actor`	Yes	Identity of the human or agent recording this action; retain the original identity when replaying its request.
`scope_id`	Yes	Named audit/work scope selecting the relevant requirement phase or work projection.
`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_ids`	No	Explicit existing requirement IDs defining the selected scope.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 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 / 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."

addedInput schema / properties / requirement_ids / description

Added value: +"Explicit existing requirement IDs defining the selected scope."

addedInput schema / properties / scope_id / description

Added value: +"Named audit/work scope selecting the relevant requirement phase or work projection."

First observedv0.1.0Oct 16, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Beyond the annotations, the description discloses that it schedules a durable LOCAL job, makes no model/provider call, performs no lifecycle transition, and that audit evidence is distinct from acceptance. This meaningfully expands on destructiveHint=false/readOnlyHint=false, though it stays silent on idempotency/replay behavior despite idempotentHint=false.

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 with purpose, then Prerequisites and Effects blocks that are easy to scan. The final fow_capabilities help-pointer line is slightly meta/verbose but every other sentence earns its place.

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?

For a mutation-style job-scheduling tool, the description covers prerequisites, effects, and scope semantics, and an output schema exists so return values need no explanation. Only the retry/idempotency story (relevant given idempotentHint=false) is left largely to the schema's request_id field.

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 baseline is 3. The description adds only marginal value for parameters, mainly the scope_id reuse constraint ('retain the same requirement selection when reusing its scope_id'); it does not explain requirement_ids or request_id beyond what the schema already documents.

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?

The description states a precise verb and resource: 'Compare current requirement traceability with the previous snapshot of a named scope' and clarifies the output is a retained phase audit. It is specific enough to distinguish itself from passive read siblings like fow_traceability, though it never names an alternative explicitly.

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?

'Single operation; call directly without an operation argument' plus a Prerequisites line ('Use a defined requirement scope; retain the same requirement selection when reusing its scope_id') gives clear invocation context. It does not name a competing sibling tool or state when NOT to use it, 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.