Skip to main content
Glama
Damel91

Flower MCP

by Damel91
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

fow_bindings

Destructive

Associate a lifecycle project with a coding host or configured provider via portable versioned JSON receipts. Inspect or export current associations; import and replace one with a reason.

Instructions

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actorNoIdentity of the human or agent recording this action; retain the original identity when replaying its request.
host_idNoStable coding-host identity for the host association; independent from optional provider bindings. Applies to: export.
operationYesOperation selector for this multiplexer; use a canonical route listed below. Canonical values: inspect, export, import.
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.
provider_kindNoConfigured route category selecting the implementation_provider association to export; not the provider's transport URL or executable command. Applies to: export.
association_kindNoAssociation category to export: host or implementation_provider; these are independent bindings. Applies to: export. Required by: export.
replacement_reasonNoRequired explanation when replacing a different canonical host/provider association; replay of the same receipt does not replace it. Applies to: import.
association_receiptNoVersioned flow.project-association.v1 JSON receipt. Contains associations only; URLs, credentials, commands and unknown fields are rejected. Applies to: import. Required by: import. Exact required/optional dotted fields and guidance: fow_capabilities(view=operation, operation_tool=fow_bindings, operation_name=<selected route>).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed11 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 / association_kind / description
      Added value: +"Association category to export: host or implementation_provider; these are independent bindings. Applies to: export. Required by: export."
    • addedInput schema / properties / association_receipt / description
      Added value: +"Versioned flow.project-association.v1 JSON receipt. Contains associations only; URLs, credentials, commands and unknown fields are rejected. Applies to: import. Required by: import. Exact required/optional dotted fields and guidance: fow_capabilities(view=operation, operation_tool=fow_bindings, operation_name=<selected route>)."
    • addedInput schema / properties / association_receipt / examples
      Added value: +[
+  {
+    "association": {
+      "host_id": "coding-agent",
+      "kind": "host",
+      "repository_locator": "./repository"
+    },
+    "contract": "flow.project-association.v1",
+    "project_id": "example-project-id"
+  }
+]
    • addedInput schema / properties / host_id / description
      Added value: +"Stable coding-host identity for the host association; independent from optional provider bindings. Applies to: export."
    • addedInput schema / properties / operation / description
      Added value: +"Operation selector for this multiplexer; use a canonical route listed below. Canonical values: inspect, export, import."
    • addedInput schema / properties / operation / examples
      Added value: +[
+  "inspect"
+]
    • 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 / provider_kind / description
      Added value: +"Configured route category selecting the implementation_provider association to export; not the provider's transport URL or executable command. Applies to: export."
    • addedInput schema / properties / replacement_reason / description
      Added value: +"Required explanation when replacing a different canonical host/provider association; replay of the same receipt does not replace it. Applies to: import."
    • 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."
  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 declare the tool destructive and not read-only, and the description usefully splits behavior per operation (inspect/export read, import replaces and requires a reason), notes idempotent replay semantics, and reassures that receipts carry no endpoints or credentials. It still defers finer behavioral detail (error handling, exact receipt policy) to the per-operation help view.

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?

Information is front-loaded: purpose first, then routing, prerequisites, and effects, with the help pointer at the end. It is dense and slightly repetitive (the fow_capabilities help pattern is stated twice across the description and schema), which keeps it from a 5.

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 nine-parameter multiplexer with an output schema and complex receipt payloads, the description covers routing, prerequisites, side effects, and where to get exact help, which is enough for correct invocation. Deep per-operation details are delegated to a discovery call rather than included, leaving a minor completeness gap.

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 nine parameters including route applicability and the receipt contract. The description only echoes the operation routing and the receipt-safety rule, adding little syntax or meaning the schema lacks, so baseline 3 applies.

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 specific verb and resource: bind an existing lifecycle project to a coding host or configured provider via versioned JSON receipts, with inspect/export/import routing made explicit. No sibling tool in the list performs association binding, so overlap is not an issue, but it never explicitly contrasts itself with any sibling, keeping it below 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?

It names the three routes (inspect, export, import) and gives prerequisites: an existing project is required and provider receipts may only select already-configured routes. It does not name alternative tools or state when NOT to use this one, so it stops short of a full when/when-not treatment.

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