Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

No arguments

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
fow_architectureA

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

fow_external_workA

Hand a complete revision-bound packet to an external coding agent, export its executable Markdown plan, derive dependency-ordered TODOs and reconcile declared outcomes. Optional provider execution is a separate explicitly selected route. Route with operation: set_mode, select_executor, negotiate_provider, upgrade_validation, criteria, reconcile_criteria, add_criterion, edit_criterion, remove_criterion, validation, provider_validation, export_plan, todo, report_outcome, reconcile_outcome. Prerequisites: Use an existing packet/plan and issued authority. Select exactly one executor before execution. Effects: Reads derive criteria/readiness/TODO without executing code. Mutations record selection, criterion authority, artifacts and host outcomes; negotiate_provider alone explicitly probes optional provider support. Reporting completion does not verify or accept it. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_external_work","operation_name":"set_mode"}).

fow_bindingsA

Associate an existing lifecycle project with a coding host or optional configured provider through portable versioned JSON receipts. Inspect/export current associations or explicitly import and replace one. Route with operation: inspect, export, import. Prerequisites: Use an existing project; provider receipts may select already configured routes only. Effects: inspect/export read associations; import records idempotent canonical associations and requires a reason for replacement. No endpoint, credentials, commands or restart are supplied by receipts. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_bindings","operation_name":"inspect"}).

fow_semanticA

Prepare bounded semantic assignments for an external host or configured internal model, validate their submitted results and separately adopt their audit evidence. Supported roles are SRS semantic validation and intention grounding. Route with operation: inventory, prepare, inspect, submit, adopt, execute_internal. Prerequisites: Use inventory, then prepare a supported role in host or internal mode; internal needs configured inference. Effects: prepare persists a prompt/authority snapshot; submit validates executor results; adopt records declared provenance. execute_internal explicitly invokes inference. SRS preparation/inspection reads the selected source file. Observed-behavior drafting is unsupported. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_semantic","operation_name":"inventory"}).

fow_capabilitiesA

Discover what Flower can do and how to call it: bounded tool summary, progressive workflow recipes, exact operation inputs/examples or the diagnostic catalog. Route with view=summary|recipe|operation|docs|full; recipe needs recipe_name, operation needs operation_tool and operation_name. Prerequisites: No project, database mutation or optional provider is needed. Effects: Read-only progressive discovery; returns exact required/optional fields, accepted selector values, examples and guidance. Does not execute recipes. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_capabilities","operation_name":"call"}).

fow_create_projectA

Register a uniquely identified local lifecycle project before recording its requirements, goals and implementation work. This creates lifecycle authority rather than repository scaffolding. Single operation; call directly without an operation argument. Prerequisites: Choose a unique lifecycle project ID and human-readable name. Effects: Creates canonical local project authority and its audit event. Repeated creation of the same project_id rejects before further effects; request_id is inert. Does not inspect or create repository files. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_create_project","operation_name":"call"}).

fow_interactionB

Connect this conversation to its durable lifecycle project, discover available work and select one bounded work surface using the issued choices and frame. Route with operation: status, discover, open, select_project, switch_project, clear_project, select, switch, clear, frame, resolve, goal_hook. Prerequisites: Supply the host's stable interaction_session_ref and explicit selection intent. Effects: Persists conversation context, lenses and continuations. Optional configured discovery providers may be consulted; selecting a surface does not authorize its work. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_interaction","operation_name":"status"}).

fow_register_requirementA

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

fow_get_requirementA

Retrieve one existing requirement, its current canonical state and retained revision history. Single operation; call directly without an operation argument. Prerequisites: Use an existing canonical requirement ID within its project. Effects: Read-only requirement state and immutable revision history; no model/provider calls. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_get_requirement","operation_name":"call"}).

fow_revise_requirementA

Change the statement or classification of an existing requirement by appending a canonical revision. Keep intent changes explicit so downstream evidence can be reconciled. Single operation; call directly without an operation argument. Prerequisites: Investigate the existing requirement and authorize any actual change of intent first. Effects: Appends an immutable revision; downstream currentness/closure may change. Existing evidence is not rewritten or made current. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_revise_requirement","operation_name":"call"}).

fow_set_requirement_lifecycleA

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

fow_record_verificationA

Record evidence actually obtained for a requirement, including verification method, outcome, reference and declared metadata. This records a result rather than running a test. Single operation; call directly without an operation argument. Prerequisites: Use an existing requirement and evidence actually obtained by the declared verification method. Effects: Appends declared evidence/provenance. It does not execute tests, audit a provider or grant acceptance. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_record_verification","operation_name":"call"}).

fow_traceabilityA

Inspect how current requirements, milestone scope and recorded verification evidence correspond. Read bounded pages or retrieve one original evidence body with audit detail. Single operation; call directly without an operation argument. Prerequisites: Select a project and optionally a milestone or exact evidence ID. Effects: Read-only bounded traceability/evidence with pagination; no provider/model execution or authority mutation. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_traceability","operation_name":"call"}).

fow_goalA

Describe intended software behavior as use cases, ordered sequences and behavioral expectations, then link and inspect those goal nodes or derive requirement candidates. Route with operation: view, add_use_case, add_sequence, add_behavioral_expectation, link, derive_requirement_candidates. Prerequisites: Use an existing project and canonical graph-node identities for links. Effects: view reads the graph; authoring appends use cases/sequences/expectations/links. Candidate derivation uses the recorded goal graph without inference; candidates do not silently become requirements. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_goal","operation_name":"view"}).

fow_validate_srsA

Check a local Markdown software-requirements document structurally against a supported profile in a durable job. Semantic assignment validation is exposed separately by fow_semantic. Single operation; call directly without an operation argument. Prerequisites: Supply a readable local Markdown SRS and supported standard_profile. Effects: Schedules durable structural validation and reads the source. Semantic checks use fow_semantic; validation alone does not import or accept a baseline. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_validate_srs","operation_name":"call"}).

fow_import_srsA

Import an eligible local Markdown SRS as the initial canonical requirement baseline, preserving validated source provenance. Existing baseline changes use fow_revise_srs_baseline. Single operation; call directly without an operation argument. Prerequisites: Supply a structurally/semantically eligible initial local SRS under the selected profile. Effects: Validates source provenance and atomically imports the initial canonical baseline. Existing baseline replacement uses revise_srs_baseline; import is not stakeholder acceptance. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_import_srs","operation_name":"call"}).

fow_revise_srs_baselineA

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

fow_promote_milestoneA

Create planned milestone scope from canonical requirements, dependencies and entry/exit/risk policies. Actual result acceptance uses fow_accept_milestone. Single operation; call directly without an operation argument. Prerequisites: Supply canonical requirements, dependency closure and planning entry/exit/risk policies. Effects: Records planned milestone scope. Nonempty acceptance_evidence is rejected; promotion does not accept the result. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_promote_milestone","operation_name":"call"}).

fow_accept_milestoneA

Record governed acceptance of an eligible milestone using actual acceptance evidence after its required verification and campaign gates. Single operation; call directly without an operation argument. Prerequisites: Use an existing eligible milestone and actual governed acceptance evidence after required verification/campaign closure. Effects: Appends explicit acceptance authority under policy guards; never substitutes agent completion for acceptance. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_accept_milestone","operation_name":"call"}).

fow_audit_phaseA

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

fow_what_nextA

Find the next bounded lifecycle action from current packet gates, dependencies, requirements and evidence. Reading this projection does not execute the suggested work. Single operation; call directly without an operation argument. Prerequisites: Select existing project/scope and optional milestone, then follow returned bounded pages. Effects: Read-only next-work projection from current authority/dependencies; no code execution or provider probes. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_what_next","operation_name":"call"}).

fow_generate_artifactsA

Render and retain project lifecycle documents using an existing artifact profile in a durable local job. The host publishes or saves returned artifacts separately. Single operation; call directly without an operation argument. Prerequisites: Select an existing configured artifact profile and project. Effects: Schedules local rendering and stores immutable artifact generations from ledger/profile data. No model/provider or repository publication is performed. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_generate_artifacts","operation_name":"call"}).

fow_get_artifactsA

Retrieve retained artifact generations and optionally their document contents, filtered by generation or artifact kind. Single operation; call directly without an operation argument. Prerequisites: Select an existing project; generation_id optionally filters to one retained generation. Effects: Read-only stored metadata and optional content from all retained generations when generation_id is omitted. The coding host saves returned content using its own file tools. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_get_artifacts","operation_name":"call"}).

fow_ground_intentA

Run the configured internal intention-grounding workflow to compare selected goals with implementation evidence. For an external host assignment use fow_semantic. Single operation; call directly without an operation argument. Prerequisites: Requires configured internal inference and the implementation/source provider; host mode uses fow_semantic. Effects: Schedules bounded grounding and records declared audit evidence from actual optional integrations. Missing prerequisites block the job; grounding is not acceptance. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_ground_intent","operation_name":"call"}).

fow_get_jobA

Retrieve the status, result or failure of one previously scheduled durable job without starting or retrying it. Single operation; call directly without an operation argument. Prerequisites: Use the durable job ID returned when work was scheduled. Effects: Read-only job status/result/error; polling does not start or retry execution. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_get_job","operation_name":"call"}).

fow_list_jobsA

List the durable jobs already recorded for one lifecycle project without scheduling additional work. Single operation; call directly without an operation argument. Prerequisites: Select an existing project. Effects: Read-only durable job inventory; does not schedule, retry or cancel jobs. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_list_jobs","operation_name":"call"}).

fow_bootstrapA

Turn stakeholder scenarios into recorded lifecycle intent and an explicitly confirmed roadmap, then track correspondence, progress choices and completion of that bootstrap cycle. Route with operation: bind_implementation_provider, provider_binding_state, list_provider_bindings, start, resume, state, record_intake, record_contradiction, confirm_intake, derive_behavior, complete, cancel, guidance, record_answer, record_correspondence, roadmap, confirm_roadmap, record_continuation. Prerequisites: Select the real project/current bootstrap. Start from stakeholder scenarios and record only governing answers. Effects: Records intake, correspondence, confirmation and continuation; complete/cancel closes a cycle. Provider-binding replacement and optional behavior derivation are explicit operations. Never invent stakeholder approval or execute unclear scope. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_bootstrap","operation_name":"bind_implementation_provider"}).

fow_changeA

Record a governed change and manage its packet readiness, engineering questions, evidence reconciliation, dependencies and risk dispositions. Author the executable packet plan with fow_packet_author. Route with operation: create_change, get_change, link_change_milestone, set_packet_target_state, evaluate_packet_readiness, start_packet_construction_audit, get_packet_construction_audit, initialize_packet_reconciliation, get_packet_reconciliation, declare_packet_evidence_claim, supersede_packet_evidence_claim, import_packet_evidence_snapshot, collect_packet_evidence_snapshot, reconcile_packet_evidence, disposition_packet_evidence_residual, answer_packet_question, waive_packet_question, block_packet_question, derive_packet_pressure, get_packet_pressure, accept_residual_risk, revise_packet, link_dependency, transition_packet. Prerequisites: Use existing project/change/packet identities and the selected ordinary authority/evidence contract. Effects: Records governed changes, readiness, reconciliation and risk/question dispositions. Some explicit evidence collection/audit routes use configured providers or inference; transitions/supersession can invalidate current authority. Work plans are authored with fow_packet_author. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_change","operation_name":"create_change"}).

fow_assuranceA

Record and inspect software assurance findings, reassess them against current intent, associate corrective packets and request guarded change acceptance using actual evidence. Route with operation: record_finding, get_finding, reassess_intent, set_finding_disposition, link_fixing_packet, request_change_acceptance. Prerequisites: Investigate current requirements/goals and evidence before classifying a finding or correction. Effects: Records findings, semantic reassessment, dispositions, fixing-packet links and guarded change acceptance. Reassessment is engineer-authored; completion, verification and acceptance remain separate. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_assurance","operation_name":"record_finding"}).

fow_runA

Track who performs the implementation work: record a run, ordered dependent steps and their started/completed/blocked/cancelled states. The coding agent performs those actions outside Flower. Route with operation: create_run, get_run, add_step, link_step_dependency, start_step, complete_step, block_step, cancel_step, complete_run, cancel_run, task_view. Prerequisites: Use a governed change/packet and existing run/step IDs where requested. Effects: Records implementation-run steps, dependencies and execution outcomes; cancellation changes live authority. Flower does not execute the declared step actions. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_run","operation_name":"create_run"}).

fow_handoverA

Read coherent project progress and lifecycle context or retain a durable handover snapshot that another agent can inspect and resume. Route with operation: create_handover, get_handover, resume_context, ledger_projection, project_state_snapshot, project_progress. Prerequisites: Select current project scope or a retained handover ID. Effects: Read projections are inert; create_handover stores a coherent durable snapshot. It does not execute, accept or rewrite historical work. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_handover","operation_name":"create_handover"}).

fow_packet_authorA

Define the bounded implementation work in a packet: complete instructions, stable plan units, dependencies, producer/consumer contracts and checks. Resolve engineering questions through ordinary authoring before execution. Route with operation: start_packet, revise_packet, replace_plan, resolve_questions, answer_gate, add_unit, revise_unit, remove_unit, rebind_unit, set_dependencies. Prerequisites: Use current specification/plan revisions and ordinary packet authority; investigate and close semantic gaps before dispatch. Effects: Creates/revises packets and complete ordered units/contracts/dependencies. Removal/replacement changes current plan authority; provider-target deltas may be queued, without executing coding work. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_packet_author","operation_name":"start_packet"}).

fow_packet_advanceA

Move an existing packet through its ordinary lifecycle gates and admitted provider delivery, or only synchronize authoring deltas without starting execution. Semantic decisions answer the exact current gate. Route ordinary progression with mode=advance (default) or sync_only. Gate responses use decision.operation: accept_work_plan, reject_work_plan, accept_residual_risk, retry_provider_rejection, record_workspace_review, resolve_reconciliation_residual. Prerequisites: Inspect the current packet gate and retain issued revision/fingerprint identities. Effects: advance may synchronize provider deltas, persist transitions and reach START when admitted. mode=sync_only delivers deltas without START and rejects gate decisions. Explicit provider routes require compatible configured support; failures preserve truthful recovery. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_packet_advance","operation_name":"advance"}).

fow_packet_inspectA

Inspect a packet scope, executable units, current gates, requirements, working sheet or retained history without advancing or executing it. Route with view: summary, units, gates, working_sheet, history, requirements. Prerequisites: Use the packet ID and owning change when needed for unambiguous address resolution. Effects: Read-only bounded packet authority/units/gates/history. Provider capability projection is local binding inspection; no provider RPC or coding execution. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_packet_inspect","operation_name":"summary"}).

fow_campaign_authorA

Define and revise a verification campaign: scope, cases, obligations, behavioral Oracles, source attestations and explicit materialization or promotion authority. Route with operation: start, edit_scope, add_case, edit_case, remove_case, reorder_cases, decide_obligation, bind_obligation, author_oracle, answer_question, attest_source, authorize_materialization, retry_provider_rejection, authorize_promotion, accept_exception, cancel. Prerequisites: Use an existing governed change and current campaign fingerprint for edits. Effects: Authors cases/obligations/Oracle definitions, attestations and explicit provider materialization/promotion commands. Removal/cancellation/exception changes current authority; source files and provider actions require their declared prerequisites. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_campaign_author","operation_name":"start"}).

fow_campaign_advanceA

Perform bounded deterministic progression of an existing verification campaign until the next semantic, evidence or provider boundary requires attention. Implicit advance operation; transition_budget bounds the call. Prerequisites: Use an existing campaign, current scope and the provider/evidence prerequisites of its next boundary. Effects: Runs bounded deterministic lifecycle transitions, may deliver admitted provider work, then returns one semantic/evidence/provider boundary. It does not invent answers or acceptance. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_campaign_advance","operation_name":"advance"}).

fow_campaign_inspectA

Inspect one campaign scope, cases, obligations, Oracle contracts, attestations, evidence, residuals or history without progressing it. Route with view: summary, working_sheet, cases, obligations, oracles, constructibility, oracle_ir, attestation, evidence, residuals, history. Prerequisites: Use the campaign ID and optional owning change for scope validation. Effects: Read-only summary, cases, Oracle/evidence/residuals or history page. No provider/model calls, materialization or acceptance. Exact help (replace operation_name with the selected route): fow_capabilities({"view":"operation","operation_tool":"fow_campaign_inspect","operation_name":"summary"}).

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.7/5.0

Scored across 37 tools

Disambiguation4/5

Most tools target a distinct lifecycle concern, and descriptions include explicit cross-references that steer agents away from overlaps (e.g. fow_ground_intent vs fow_semantic, fow_external_work vs fow_packet_advance). However, the dense cluster of packet/change/run/campaign/external-work tools has subtle boundaries that an agent could still misselect, so it is not perfectly unambiguous.

Naming Consistency4/5

All tools share a consistent fow_ prefix and snake_case, with single-operation tools using a clear verb_noun pattern (fow_create_project, fow_get_requirement, fow_revise_requirement) and multi-operation routers named by domain (fow_change, fow_assurance, fow_packet_author). The deliberate router-vs-verb distinction is readable and mostly consistent, with only minor deviation.

Tool Count3/5

At 37 tools the surface is heavy and exceeds the comfortable range, which raises cognitive load for an agent. That said, the domain (a full software lifecycle governance engine) is genuinely vast and many tools are multi-operation dispatchers that consolidate dozens of underlying actions, so the count is defensible rather than inflated.

Completeness5/5

The surface covers an unusually full lifecycle: project creation, requirement CRUD and lifecycle, verification evidence, traceability, goals, SRS validate/import/revise, milestone promotion/acceptance, audits, artifact generation, job retrieval, bootstrap, assurance, run tracking, handover, packet authoring, and verification campaigns. CRUD and lifecycle coverage across these domains appears complete with no obvious dead ends.

Maintenance

ActivityMaintained
ResponsivenessNo issues