Skip to main content
Glama
Sign In
Flower MCP

Flower MCP

by Damel91
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

fow_revise_srs_baseline

Destructive

Apply a source-proven revision to the current SRS baseline, classifying changes while preserving approval requirements and immutable history, without silently accepting drift.

Instructions

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

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>",
      "previous_baseline_id": "<previous_baseline_id>",
      "source_path": "<source_path>",
      "standard_profile": "<standard_profile>",
      "actor": "<actor>"
    },
    "name": "fow_revise_srs_baseline"
  }
}

Input Schema

NameRequiredDescriptionDefault
actorYesIdentity of the human or agent recording this action; retain the original identity when replaying its request.
project_idYesCanonical lifecycle project ID. Select the existing project explicitly; development Markdown authorities are separate from runtime projects.
request_idNoCaller-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_pathYesUTF-8 .md/.markdown SRS file on the Flower SERVER filesystem, not automatically the coding client's disk. The expanded/resolved path must stay within the configured import root when one is set; source/profile/currentness checks apply.
standard_profileYesSupported SRS Markdown validation profile; use the same profile when preparing, validating and importing a source.
previous_baseline_idYesExact current SRS baseline ID that this source-proven revision is intended to replace.
governed_approval_referenceNoReference to explicit governed approval required for this lifecycle transition or baseline change.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv0.5.1
    • 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 / previous_baseline_id / description
      Added value: +"Exact current SRS baseline ID that this source-proven revision is intended to replace."
    • 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 / source_path / description
      Added value: +"UTF-8 .md/.markdown SRS file on the Flower SERVER filesystem, not automatically the coding client's disk. The expanded/resolved path must stay within the configured import root when one is set; source/profile/currentness checks apply."
    • addedInput schema / properties / standard_profile / description
      Added value: +"Supported SRS Markdown validation profile; use the same profile when preparing, validating and importing a source."
  2. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds real value on top: it is an append ('appends a baseline revision') that retains immutable history and approval requirements, warns that authority/evidence 'may require reconciliation', and states 'Does not silently accept drift' — behavior an agent would not otherwise know.

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 the core action in sentence one, then layered Prerequisites/Effects before the help escape hatch. Slight redundancy ('classifying changes' appears in both the opening and the Effects block), and the verbose fow_capabilities call line costs space, but nothing is truly wasted.

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 destructive, open-world mutation this covers prerequisites, effects, history/approval retention, and reconciliation risk, and an output schema exists so return values need not be described. The only gap is the absence of any explicit pointer to how it differs from fow_import_srs or fow_revise_requirement, which matters given the dense sibling set.

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 seven parameters thoroughly, and this is the baseline of 3. The description reinforces a few of them (previous_baseline_id, changed source, governed approval) but adds no syntax, format, or constraint detail beyond what the fields already spell out.

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 (apply/revise) and resource (the current SRS baseline), and the qualifier 'source-proven' cleanly separates it from a raw import. It does not, however, name the nearest siblings (fow_import_srs for first-time import, fow_revise_requirement for single requirements), so the agent must infer the boundary from the resource noun alone.

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 an explicit Prerequisites clause (exact current previous_baseline_id, changed local source, required governed approval) tell the agent when the tool is callable and what must be true first. It stops short of naming an alternative or a when-not condition, 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.

Deploy Server

Other Tools