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

Annotations already declare the mutation/safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the bar is lower. The description nonetheless adds real behavior: the action appends acceptance authority under policy guards and explicitly cannot be used to substitute for agent completion. It omits any retry/idempotency warning, which matters given 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short, front-loaded lines covering purpose, invocation style, prerequisites, and effects, with a pointer to exact help last. Every line contributes; the help-pointer line is somewhat formulaic but useful for route discovery.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need not be described, and structured fields supply safety and parameter detail. The description still covers what an agent needs: gates that must close first, the evidence requirement, and the fact that this records authority rather than agent-claimed completion.

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

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

Schema description coverage is 100%, so all five parameters are already documented in the schema, including actor, request_id retry semantics, and the meaning of acceptance_evidence. The description adds only high-level prerequisite context (eligible milestone, actual evidence) rather than parameter-level syntax or constraints, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Record governed acceptance of an eligible milestone') with scope conditions (evidence, verification and campaign gates closed). It implicitly distinguishes itself from verification and completion tools via 'never substitutes agent completion for acceptance', but no sibling is named outright.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

An explicit Prerequisites line tells the agent when this applies: an existing eligible milestone plus actual governed acceptance evidence after verification/campaign closure. It also clarifies invocation style ('single operation; call directly without an operation argument'). It stops short of naming an alternative tool for the when-not case, though the 'not a completion claim' line implies one.

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

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.

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.

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.

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.

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.

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.

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

Annotations already flag the mutation profile (readOnlyHint=false, destructiveHint=true, idempotentHint=false), but the description adds real context beyond them: it lists what effects are produced and stresses that 'reassessment is engineer-authored; completion, verification and acceptance remain separate,' which prevents the agent conflating these stages. It does not, however, describe reversibility or the receipt/retry behavior (only the schema's request_id field hints at that).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight blocks — purpose, route list, prerequisites/effects — plus one help pointer, all front-loaded with the capability statement first. Density is justified for a six-operation multiplexer, though the 'Effects' sentence is somewhat compressed and could be clearer.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 no explanation, and the description covers routing, prerequisites, mutation effects and a mechanism for per-operation detail. For a 24-parameter, 6-route multiplexer it is close to complete, but it leaves the receipt/replay policy and success criteria implicit in the schema only.

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

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

With 24 parameters and 100% schema description coverage, the schema already carries per-field meaning, including 'Applies to' / 'Required by' routing annotations, so the baseline is 3. The description contributes only the operation enumeration and a pointer to fow_capabilities for dotted-field help, adding nothing about field formats or constraints beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource set — recording/inspecting software assurance findings, reassessing intent, linking fixing packets, requesting guarded change acceptance — and enumerates the six routing operations that scope the tool. It is clearly distinguishable in domain from siblings like fow_campaign_author or fow_record_verification, but it never explicitly contrasts itself against those neighbors.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an explicit prerequisite ('Investigate current requirements/goals and evidence before classifying a finding or correction') and names the operation routes for each intended behavior, so an agent knows which route to select. It stops short of when-not-to-use guidance or pointing to an alternative sibling tool for overlapping work.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

With destructiveHint=true and openWorldHint=true already in annotations, the description still adds substantive behavior: it says what gets recorded (intake, correspondence, confirmation, continuation), that complete/cancel closes a cycle, that provider-binding replacement and behavior derivation are explicit opt-in operations, and that approval must never be invented. The one gap is that individual operation-level side effects and the confirmation receipt semantics are deferred to the capabilities lookup.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded and the Prerequisites/Effects blocks are well-structured, so the skeleton is good. But the description re-lists all 19 operation names that are already enumerated in the `operation` schema enum, which is pure duplication and dominates the token budget. The final fow_capabilities pointer is verbose but earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 24-parameter, 19-route multiplexer with an output schema available (so return values need no explanation), the description covers purpose, prerequisites, effects, and the escape hatch for exact per-operation contracts. The residual gap is that the object-typed payloads (intake, contradiction, correspondence, answer) are only reachable via an extra fow_capabilities call, so an agent cannot invoke those routes from this definition alone.

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

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 and the per-property 'Applies to / Required by' notes already tell the agent which operation consumes which field. The description itself contributes no parameter meaning beyond the operation-route list, which is duplicated in the schema's canonical values. It correctly defers the nested payload shapes to operation help rather than pretending to document them.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence names a specific transformation (stakeholder scenarios -> recorded lifecycle intent + explicitly confirmed roadmap) plus the ongoing tracking function, which is far more than a restatement of the name. It is distinguishably a lifecycle-bootstrap multiplexer rather than a sibling like fow_handover or fow_packet_advance. It loses a point only because the phrasing is dense internal jargon that an outside agent must decode.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Prerequisites ('Select the real project/current bootstrap. Start from stakeholder scenarios and record only governing answers.') give real context for when this tool is the right entry point, and the enumerated operation routes imply the sub-workflow. However, there is no explicit when-not-to-use guidance and no routing against the 35 sibling tools (e.g. when to bootstrap vs. fow_goal or fow_campaign_author), so usage is only partially disambiguated.

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

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 bar is lower. The description still adds real behavioral context the annotations do not: the progression is deterministic and bounded, it may deliver admitted provider work, it stops at exactly one boundary, and it 'does not invent answers or acceptance'. It stops short of describing the destructive/persistence consequences the annotations imply.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded in the first sentence, followed by clearly labelled Prerequisites and Effects blocks, so an agent can scan it quickly. 'Implicit advance operation' is near-redundant with the name and the help-dispatcher sentence is dense, but overall the size is proportionate and every remaining sentence carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 explained, and the description covers prerequisites, bounded effects, and the boundary it stops at. Combined with the annotations it gives an agent enough to call the tool correctly; only the destructive/idempotency implications and sibling routing are unaddressed.

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

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

Schema coverage is 100%, so all six parameters are already documented in the schema, making a baseline of 3 appropriate. The description only elaborates on transition_budget (it bounds the call) and the campaign prerequisite; it adds no format or interaction detail beyond what the schema supplies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: bounded deterministic progression of an existing verification campaign until a semantic/evidence/provider boundary. That is far more precise than a restatement of the name. It does not, however, explicitly contrast itself with the similarly named sibling fow_packet_advance or the read-only fow_campaign_inspect, so sibling disambiguation is left to the name.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives prerequisites ('use an existing campaign, current scope and the provider/evidence prerequisites of its next boundary') and notes the implicit advance operation bounded by transition_budget. But it never says when NOT to use it, nor names an alternative route (e.g. inspecting rather than advancing, or packet-level advance). Usage is implied rather than routed.

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

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

Annotations already declare destructiveHint=true, openWorldHint=true and non-idempotent, so the safety bar is lower; the description still adds real substance by naming the mutation targets and warning that removal/cancellation/exception changes current authority and that source files and provider actions require declared prerequisites. It does not state reversibility or receipt-replay behavior in the description itself (that lives in the schema).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Effectively structured: purpose first, then the operation routes, then prerequisites, then effects, then the help escape hatch. The long route enumeration is load-bearing for a multiplexer rather than padding, and no sentence is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 16-route multiplexer with 33 parameters, an output schema, and full annotations, the description supplies the routing table, the mutation/authority effects, and a concrete pointer (fow_capabilities with operation_name) for per-route field detail. Nothing needed to select or correctly invoke a route is missing.

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

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

Schema description coverage is 100% across 33 parameters, so the schema already carries per-field meaning and applicability. The description contributes only the routing contract (operation selectors and prerequisites) and then defers exact dotted-field guidance to fow_capabilities, adding little beyond the structured data.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource pair ('Define and revise a verification campaign') and enumerates exactly what artifacts are within that scope (scope, cases, obligations, Oracles, attestations, materialization/promotion authority). The focus on authoring clearly separates it from the sibling campaign tools fow_campaign_advance and fow_campaign_inspect.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'Route with operation:' list tells the agent exactly which operation selects which sub-action, and the Prerequisites sentence ('use an existing governed change and current campaign fingerprint for edits') sets a gating condition. It never explicitly names an alternative sibling (e.g. use fow_campaign_inspect to read rather than author), so it stops short of full when/when-not routing.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint false, and openWorldHint false. The description adds meaningful non-effects beyond those: it does not progress the campaign and makes no provider/model calls, materialization, or acceptance.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the purpose, then routes, prerequisites, effects, and an exact-help pointer. It is dense but each line earns its place; the help pointer is useful for view-specific semantics, though the overall block is longer than strictly minimal.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a six-parameter, multi-view read tool with an output schema, the description covers purpose, routing, prerequisites, effects, and points to exact help for route details. Return values are handled by the output schema, so no critical gaps remain.

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

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 six parameters including the canonical view values. The description adds slight purpose for campaign_id/change_id via 'scope validation,' but limit/offset and address-resolution behavior remain schema-only, making the baseline 3 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Inspect') and resource ('one campaign') plus the inspectable aspects. The phrase 'without progressing it' distinguishes it from fow_campaign_advance, so an agent can select it without opening another schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear routing via view values and prerequisites ('Use the campaign ID and optional owning change for scope validation'). It does not explicitly name sibling alternatives such as fow_campaign_advance or fow_packet_inspect, so it stops short of full when/when-not guidance.

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

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

Annotations already cover readOnly/idempotent/non-destructive; the description adds genuinely new behavioral context: it 'does not execute recipes' and returns 'exact required/optional fields, accepted selector values, examples and guidance'. This clarifies the tool is pure introspection rather than an action, which the annotations alone would not convey. It stops short of describing pagination or size bounds for the 'full' view.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded routing sentence, then prerequisites, effects, and a concrete example call. Every element is useful, though the final 'Exact help' sentence is somewhat clunky and partly overlaps the earlier routing statement.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return contents need not be described. For a meta-discovery tool the description covers routes, required companion parameters, prerequisites, and side-effect scope, leaving nothing an agent needs before invoking it.

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

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

Schema coverage is 100%, so baseline would be 3, but the description adds conditional dependency semantics the schema does not express: recipe requires recipe_name, operation requires operation_tool plus operation_name. That routing-to-parameter mapping is real added meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Discover what Flower can do and how to call it', with concrete sub-capabilities (bounded tool summary, workflow recipes, exact operation inputs, diagnostic catalog). This is clearly distinguishable from all the action siblings like fow_run, fow_traceability, or fow_goal, which perform work rather than describe it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit routing conditions for each view ('recipe needs recipe_name, operation needs operation_tool and operation_name') and a prerequisite statement ('No project, database mutation or optional provider is needed'). It does not explicitly say when to prefer a concrete sibling over this discovery tool, but the route-to-use mapping is clear.

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

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

Annotations already declare destructiveHint=true, openWorldHint=true, idempotentHint=false and readOnlyHint=false, so the safety posture is known. The description adds real value beyond that: it discloses that some evidence-collection/audit routes use configured providers or inference, and that transitions/supersession can invalidate current authority. The request_id schema note also conveys the retry/receipt policy. This is meaningful behavioral context layered on the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Content is clearly labeled (Route, Prerequisites, Effects, Exact help) and the purpose is front-loaded, which is good structure. However, the 24-route enumeration plus the effects boilerplate is heavy prose for a multiplexer whose schema already lists the same canonical operations, so some text is redundant with structured fields rather than earning its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 explained, and the 78-parameter schema is fully documented. The description supplies purpose, routing, prerequisites, effects and a help pointer — sufficient for an agent to know which route to select. Deeper per-route argument semantics are deliberately deferred to fow_capabilities, which is a reasonable division of labor.

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

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 78 parameters, setting the baseline at 3. The description adds no per-parameter format or syntax detail but instead delegates exact per-operation parameter guidance to fow_capabilities. With the schema carrying the full burden, 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific domain (governed change plus packet readiness, engineering questions, evidence reconciliation, dependencies, risk dispositions) and enumerates all 24 routes, so the resource is unambiguous. It also explicitly routes plan authoring to the sibling fow_packet_author, giving clear differentiation. The aggregate 'manage X, Y, Z' framing is broad but the route list grounds it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides a Prerequisites line (existing project/change/packet identities and the selected ordinary authority/evidence contract) and an Effects line, plus an explicit alternative ('Work plans are authored with fow_packet_author') and a concrete way to get per-route help via fow_capabilities. It does not, however, spell out when to prefer this tool over fow_packet_advance or fow_packet_inspect, leaving some sibling disambiguation implied.

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

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

Annotations already declare non-readOnly, idempotent, non-destructive and closed-world, and the description adds real depth beyond them: duplicate project_id is rejected before further effects, request_id is inert, an audit event is created, and repository files are neither inspected nor created. This is exactly the behavioral context an agent needs before invoking a state-mutating tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded and the remainder is organized into usable Prerequisites/Effects clauses with zero filler sentences. The trailing 'Exact help' boilerplate and some conceptual jargon slightly dilute an otherwise tight passage, keeping it just short of 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 explained. Given that, the description covers purpose, prerequisites, side effects, duplicate-rejection behavior and non-file-system scope — everything needed to call it correctly.

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

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; each parameter already has its own description in the schema. The description reinforces project_id uniqueness and request_id inertness, but that duplicates what the schema fields (particularly request_id) already document, so it adds little beyond the structured data.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Register a ... local lifecycle project') and immediately scopes it ('lifecycle authority rather than repository scaffolding'), which separates it from repo-file creation and from downstream siblings like fow_register_requirement and fow_goal. An agent can tell what this does and where it sits in the sequence without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Single operation; call directly without an operation argument' and lists prerequisites (pick a unique project_id and human-readable name). It gives clear conditions for use but does not route to a named alternative tool (it only points at fow_capabilities for help), so full when/when-not/alternatives coverage is not reached.

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

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

Annotations already declare destructiveHint=true, openWorldHint=true and non-idempotent, so the description's job is to add context. It does: reads derive criteria/readiness/TODO without executing code; mutations record authority and outputs; negotiate_provider is the only route that probes optional provider support; reporting completion does not verify or accept it. That last point is important behavioral context not covered by annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded and organized with Route/Prerequisites/Effects paragraphs, which gives structure. However, the opening sentence is dense, the operation list duplicates the enum in the schema, and the help pointer is lengthy; the text is adequate but not tight.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 explained. For a 7-parameter, 15-operation multiplexer the description covers routing, prerequisites and the key behavioral distinction between read and mutation routes, and points to fow_capabilities for per-operation field details. It is complete enough to call correctly, though per-operation semantics remain behind the capabilities tool.

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

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

Schema description coverage is 100%, and the schema itself already describes actor, payload, change_id, packet_id, project_id, request_id and the operation enum. The description names the operations but adds little about individual parameter semantics beyond pointing to fow_capabilities for exact dotted fields. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a broad summary of handing a packet to an external coding agent, exporting plans, deriving TODOs and reconciling outcomes, then lists 15 operations. That is a consistent descriptor for a multiplexer, so the purpose is not misleading, but it does not establish what fow_external_work owns relative to siblings like fow_packet_advance or fow_run. Its identity is only distinguishable by the operation list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states prerequisites (existing packet/plan and issued authority; exactly one executor selected before execution) and separates read operations from mutations. It does not tell the agent when to choose a sibling tool instead, but within this tool the read/mutation split and executor rule are clear routing guidance.

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

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

Goes well beyond the annotations: it discloses the durable local job, that stored generations are immutable, and that no model/provider call or repository publication occurs — the latter being important given openWorldHint=false. The request_id retry semantics are also surfaced. It stops short of stating auth/permission requirements or expected duration.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The first sentence front-loads verb, resource, and mechanism, and the following lines are clearly segmented into Single operation / Prerequisites / Effects. Slightly verbose, and the long help pointer sentence is heavy, but nothing is redundant with structured fields.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 explained, and the description covers prerequisites, effects, non-effects, and retry behavior for a mutation with idempotentHint=false. The main gap is the missing pointer to fow_get_artifacts as the retrieval counterpart.

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

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

Schema description coverage is 100%, so all four parameters are already documented (actor, profile_id, project_id, request_id) with meaningful semantics like 'selects rendering policy, not a model endpoint'. The description adds little parameter-level meaning beyond echoing that an existing profile and project must be selected, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Render and retain project lifecycle documents using an existing artifact profile in a durable local job.' It also delimits scope by noting the host publishes/saves artifacts separately, so the agent can tell rendering from publishing. It does not name the read-side sibling (fow_get_artifacts), so sibling differentiation is implicit rather than explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 line gives clear invocation context. However, it never states when NOT to use it or which sibling to reach for instead (e.g., fow_get_artifacts for retrieval), so the when-vs-alternatives guidance is absent.

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

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, and the description adds real value beyond them: breadth of the read when generation_id is omitted (all retained generations), and the important operational note that the coding host writes returned content to disk using its own file tools rather than this tool persisting anything. No indication of pagination or result-size limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the purpose, then uses short labeled lines (Single operation / Prerequisites / Effects) that are easy to scan. The trailing templated capabilities-help sentence is boilerplate filler that slightly dilutes an otherwise tight definition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need not be described, and the description covers prerequisites, filtering scope, and content handling adequately. Minor omissions remain around pagination or volume expectations for large generation sets.

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

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 project_id, generation_id, artifact_kind and include_content with semantics comparable to the description. The description repeats the filtering behavior without adding syntax or format detail beyond it, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Retrieve retained artifact generations and optionally their document contents') with the filtering axes named. It is clearly distinguishable from the write-side sibling fow_generate_artifacts and from the other fow_* tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says it is a single operation with no operation argument, and lists the prerequisite (select an existing project) plus how generation_id narrows scope. It lacks an explicit 'when not to use / use X instead' pointer back to fow_generate_artifacts for creating artifacts.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond that: polling does not start or retry execution, which is the exact misunderstanding an agent could have for a job-status tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core purpose and then labels prerequisites and effects clearly. The trailing fow_capabilities help pointer is useful but adds bulk; still, every sentence carries operational content and none is filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need not be spelled out, and the description supplies prerequisites, read-only effects, and a help route. It is complete enough for correct invocation, with the only gap being no explicit tie-break against fow_list_jobs.

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

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

Schema description coverage is 100%, so both job_id and project_id are already documented in the schema, including where the job ID comes from. The description restates the job-ID provenance but adds no format or constraint detail beyond the schema; baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Retrieve the status, result or failure of one previously scheduled durable job') and adds a scope boundary ('without starting or retrying it') that distinguishes it from scheduling or list-style siblings like fow_list_jobs. An agent can identify the tool's role without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives the prerequisite (use the durable job ID returned when work was scheduled) and clarifies it is a single operation requiring no operation argument. It does not explicitly contrast with the sibling fow_list_jobs, so an agent must infer the one-job-vs-many-jobs split.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so safety is covered structurally. The description still adds real value beyond them by disclosing the effects ('no model/provider calls', immutable revision history) and the need for an existing canonical ID — cost, side-effect and precondition context the annotations cannot express.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The key claim (what is retrieved) is front-loaded, and the Prerequisites/Effects labeling makes it scannable. The trailing 'Exact help (replace operation_name with the selected route)' boilerplate is a bit of templated filler, keeping it out of the top band.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

A read-only retrieval tool with an output schema, full annotation coverage and 100% parameter description coverage needs little more than this. The description supplies the operation model, prerequisites, side-effect profile and help routing, leaving no gap an agent must close before calling it.

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

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

Schema description coverage is 100% and both parameters are documented there in detail (canonical lifecycle project ID, requirement identity as returned by registration/import). The description's phrase 'existing canonical requirement ID within its project' only lightly reinforces that, without adding format, syntax or constraint detail beyond the schema — baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Retrieve) and resource (one existing requirement), and explicitly scopes what is returned: current canonical state plus retained revision history. The resource is unique among siblings, so an agent can distinguish it from fow_get_artifacts, fow_get_job, and the mutate-oriented fow_revise_requirement without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives invocation guidance ('Single operation; call directly without an operation argument') and a precondition ('Use an existing canonical requirement ID within its project'), which is more than nothing. However, it never states when to prefer this over siblings such as fow_traceability or fow_revise_requirement, and there are no explicit when-not-to-use conditions.

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

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

Annotations declare it is not read-only, not idempotent, and non-destructive, and the description adds useful specifics beyond that: 'view reads the graph; authoring appends ... candidates do not silently become requirements.' This clarifies the mutation/read split and the non-promoting behavior of derivation, going beyond the annotation flags.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core purpose, then routing, prerequisites, and effects in labeled blocks. Reasonably tight for a 26-parameter multiplexer, though the help-invocation sentence is somewhat boilerplate.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 explained. The description covers routing, prerequisites, and effects for a complex multiplexer; the main omission is discriminating this tool from sibling authoring tools.

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

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 26 parameters thoroughly. The description adds only the operation routing values, which the schema also lists. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific domain (goal graph) and enumerates the authoring capabilities (use cases, sequences, behavioral expectations, links, derivation). It is clear what the tool does, though it is a multiplexer whose breadth is better conveyed by the operation enumeration than a single crisp verb+resource.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly names the routing operation values and provides prerequisites (existing project, canonical graph-node identities). It doesn't compare against siblings like fow_architecture or fow_register_requirement, but the routing guidance is concrete.

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

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

Annotations declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false, so the safety profile is already carried. The description goes beyond that by disclosing async behavior ('Schedules bounded grounding'), that audit evidence is recorded from optional integrations, and the important caveat that 'grounding is not acceptance.' It does not spell out receipt/idempotency semantics beyond pointing at the help route.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The content is front-loaded with the purpose, then prerequisites, then effects, which is a sensible order and each block earns its place. It is slightly redundant ('host mode uses fow_semantic' repeats the earlier external-host routing sentence) and the trailing self-referential help pointer adds length, but nothing is padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a non-idempotent, open-world mutation that schedules a job, and the description covers prerequisites, blocking behavior, side effects (audit evidence), and the semantic limit of the result. Because an output schema exists, it need not describe return values. The main residual gap is that it does not describe how to observe the scheduled job's progress.

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

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

Schema description coverage is 100% and all five parameters carry their own descriptions (actor, project_id, request_id, goal_node_ids, source_revision), so the schema does the heavy lifting. The description adds no parameter-level syntax or format detail, which is the expected baseline when coverage is complete.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource ('Run the configured internal intention-grounding workflow to compare selected goals with implementation evidence'), which is far more precise than the bare tool name. It immediately distinguishes itself from the closest sibling by stating 'For an external host assignment use fow_semantic.' An agent can separate fow_ground_intent from fow_semantic without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit routing guidance: use this tool for internal intention grounding, use fow_semantic for an external host assignment. Prerequisites are stated concretely ('Requires configured internal inference and the implementation/source provider') along with the consequence of missing them ('Missing prerequisites block the job'). Both when-to-use and when-not-to-use are covered.

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

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

Annotations declare readOnly=false and destructive=false but say nothing about scope of mutation. The description fills that gap well: read projections are inert, create_handover stores a coherent durable snapshot, and it explicitly does not execute, accept, or rewrite historical work. It does not address retry/receipt semantics beyond deferring to operation help, which keeps it short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded around the read/write split, then routing, prerequisites, effects, and a help pointer in that order. Dense but every line carries information; the fow_capabilities boilerplate is slightly long but justified for a six-route multiplexer.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need no explanation, and the description covers scope split, routing, prerequisites, and non-destructiveness for what is a 6-route, 14-parameter multiplexer. The per-parameter route mapping lives in the schema's "Applies to" annotations, so the description is nearly complete; only route-to-sibling boundary guidance is missing.

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

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

Schema description coverage is 100% across 14 parameters, each already annotated with which route it applies to and which are required, so the schema carries the burden and baseline 3 applies. The description adds only the aggregate prerequisite (project scope or handover ID retained) and route names, without new format or constraint detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence names a specific resource and two concrete modes: reading lifecycle/progress context versus retaining a durable handover snapshot another agent can resume. The six operation routes are listed, so the tool's dual read/write scope is clear. It stops short of distinguishing itself from nearby siblings like fow_packet_inspect or fow_campaign_inspect, which also deal with progress state.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

"Route with operation: ..." plus "Prerequisites: Select current project scope or a retained handover ID" gives real selection context, and the fow_capabilities pointer offers per-route help. However, no guidance is given on when to pick ledger_projection versus project_state_snapshot versus project_progress, nor when a sibling tool would be the better entry point. Usage is implied by route names rather than explained.

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

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

With no annotations supplied, the description carries the load and does reasonably well: it discloses provenance validation, atomic import semantics, the eligibility prerequisite, and the non-implication of stakeholder acceptance, and points to the operation help for receipt policy. It still doesn't cover permissions/auth required to import a canonical baseline or whether an import can be undone.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded statement of purpose followed by clearly labelled Prerequisites/Effects lines — efficient structure. The final 'exact help' sentence is boilerplate phrased generically for a route-based tool and reads as marginal noise on a single-operation tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, prerequisites, effects, sibling routing, and invocation mode, but with no output schema the description never says what the agent receives back (baseline identifier, receipt, revision record). For a baseline-mutating operation that gap is a modest but real incompleteness.

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

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

All five parameters carry schema descriptions (source_path explains the server-filesystem constraint and import root; request_id explains retry identity), so the schema does the heavy lifting. The description only adds that the source must be eligible under the selected profile, which is confirmatory rather than new. Baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Import ... Markdown SRS as the initial canonical requirement baseline') and scopes it to the *initial* baseline, explicitly naming fow_revise_srs_baseline as the tool for existing baseline changes. An agent can distinguish this from its lifecycle siblings without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit alternative and the condition selecting it ('Existing baseline changes use fow_revise_srs_baseline'), plus stated prerequisites (eligible local SRS under the selected profile) and a scope exclusion ('import is not stakeholder acceptance'). It also tells the agent to call directly without an operation argument.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true and openWorldHint=true, so mutation risk and external reach are known. The description adds genuine context beyond that in the Effects line ('Persists conversation context, lenses and continuations', external providers 'may be consulted', and 'selecting a surface does not authorize its work'), but it never maps destructive behavior to specific routes (clear, clear_project) or states auth/permission needs, so it only partially fills the gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The text is front-loaded with purpose and then cleanly sectioned into Route, Prerequisites, Effects, and an 'Exact help' pointer, making it easy to scan. It is fairly dense with neologisms and repeats the route list already present in the operation enum, but every section is functionally purposeful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 12-route multiplexer this is thin: the description lists operation names but never explains what distinguishes select from switch from frame from resolve, which is exactly what an agent needs to choose a route. Output values need not be explained since an output schema exists, and the pointer to fow_capabilities partially mitigates the gap, but it forces a second call to become actionable.

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

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 16 parameters thoroughly, including which routes each applies to. The description adds only the prerequisite that interaction_session_ref and selection intent must be supplied, so the baseline 3 for a fully-documented schema is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a concrete set of verbs (connect, discover, select) and a resource (the lifecycle project/work surface) and enumerates the 12 routes, which helps an agent see the multiplexer's scope. However, it is wrapped in invented jargon ('durable lifecycle project', 'bounded work surface', 'issued choices and frame') and never distinguishes this tool from siblings like fow_what_next, fow_goal, or fow_capabilities, so an agent cannot easily tell when this is the right entry point.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a real prerequisite ('Supply the host's stable interaction_session_ref and explicit selection intent') and tells the agent to pick a route via the operation selector, plus points to fow_capabilities for exact per-operation help. But it offers no when-to-use vs when-not-to-use guidance and names no alternative sibling tool, leaving route selection to inference.

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

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

Annotations already declare read-only, idempotent, non-destructive behavior. The description adds useful context beyond that: it is a durable job inventory and does not schedule, retry, or cancel jobs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and front-loaded, with purpose first, then invocation, prerequisites, and effects. The trailing exact-help call is useful but slightly less essential, keeping it from a full 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given rich annotations, full parameter schema coverage, and an output schema, the description supplies everything an agent needs: purpose, invocation style, prerequisite, and side-effect boundaries. Return values are appropriately left to the output schema.

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

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 the single project_id parameter thoroughly. The description only adds that the project must be selected explicitly, which is already implied by the schema description; baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'List the durable jobs already recorded for one lifecycle project.' It adds scope and an exclusion ('without scheduling additional work'), but does not explicitly differentiate itself from the related fow_get_job sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear invocation guidance ('call directly without an operation argument') and a prerequisite ('Select an existing project'). It also implies when not to use it by saying it does not schedule work, though it names no sibling alternative explicitly.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true; the description adds real behavioral context beyond them — what advance persists and that it can reach START when admitted, that sync_only delivers deltas without START and rejects gate decisions, that explicit provider routes require compatible configured support, and that failures preserve truthful recovery. It stops short of detailing what state is destroyed or the retry/conflict mechanics, which the schema partially carries.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded, followed by routing, prerequisites, effects, and a precise help pointer, so each block is scannable. It is dense with domain jargon and the 'Semantic decisions answer the exact current gate' line is terse to the point of opacity, but no sentence is pure filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter, gated mutation tool with an output schema available, the description covers prerequisites, effects, mode routing, and failure behavior adequately. It relies on the fow_capabilities pointer for exact per-route required fields, which is a reasonable division of labor but leaves the agent to make a follow-up call.

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

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

Schema coverage is 100%, so the baseline is 3, but the description goes further by explaining mode semantics, how decision.operation routes each gate response, and the need to retain issued revision/fingerprint identities (expected_plan_revision/expected_spec_revision). It adds meaning beyond the schema rather than restating it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a concrete verb+resource ('Move an existing packet through its ordinary lifecycle gates') and splits it into the two operating modes (advance vs sync_only), so the agent knows this is a lifecycle-progression tool rather than authoring or inspection. It does not explicitly name siblings such as fow_packet_inspect or fow_packet_author, so it falls short of full sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear routing criteria ('Route ordinary progression with mode=advance (default) or sync_only'), states the prerequisite to inspect the current gate first, and enumerates the gate decision routes via decision.operation. There is no explicit 'do not use this when X, use tool Y' exclusion, but the context for correct usage is well covered.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, openWorldHint=true, so the safety profile is covered. The description meaningfully adds: removal/replacement changes current plan authority, provider-target deltas may be queued, and — importantly — no coding work is actually executed. That is real context beyond the structured hints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four labeled lines (purpose, routing, prerequisites, effects, help) front-load the definition and are scannable. Given a 38-parameter multiplexer, the density is justified, though the help-pointer sentence and some phrasing are slightly redundant with the schema's own capability notes.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need not be described, and the description still covers effects, prerequisites, routing, and where to get per-operation detail. For a tool of this complexity it is nearly complete; only the when-versus-siblings dimension is left implicit.

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

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

Schema description coverage is 100% across 38 parameters, so the schema already documents each field's meaning and applicable operations. The description adds only the operation-route enumeration and a pointer to fow_capabilities for exact dotted-field help, which does not meaningfully exceed the schema's own content. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — defining bounded implementation work in a packet — and enumerates what that entails (instructions, stable plan units, dependencies, producer/consumer contracts, checks). The operation list makes the tool's surface très concrete. It doesn't explicitly name a sibling such as fow_packet_advance or fow_packet_inspect to disambiguate, so it falls 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

"Route with operation: ..." tells how to select a mode, and the Prerequisites line gives a precondition (use current spec/plan revisions, close semantic gaps before dispatch). However, nothing says when to choose this authoring tool over fow_packet_advance or fow_packet_inspect, so guidance is implied rather than explicit.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description nonetheless adds value beyond them: 'no provider RPC or coding execution,' the fact that provider capability projection is local binding inspection, and that the packet authority is bounded – all behavioral context an agent could not derive from the annotations alone.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core purpose in the first sentence and then layers route, prerequisites, and effects in clearly delineated blocks. The trailing 'Exact help' JSON template is slightly clunky but is a concrete pointer rather than filler, so the overall structure is efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter read tool with an output schema present, the description covers purpose, routing, prerequisites, and effects without needing to explain return values. Nothing an agent needs in order to invoke it correctly is missing.

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

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

Schema description coverage is 100%, so every parameter is already documented, and the tool has no enums. The description restates the view routes (summary, units, gates, working_sheet, history, requirements) and the packet/change address prerequisite, but adds no format, default, or interaction detail beyond the schema, which is the expected baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (inspect) and resource (packet scope: units, gates, requirements, working sheet, history) and immediately bounds it with 'without advancing or executing it,' which cleanly separates it from the fow_packet_advance sibling. An agent can tell what it does and what it does not do without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'without advancing or executing it' clause plus the route list tells the agent when this is the right call versus the advance/mutation path, and it names a prerequisite (packet ID and owning change for unambiguous resolution). It stops short of explicitly naming fow_packet_advance as the alternative, so it is clear context rather than a full when/when-not routing table.

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

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

Annotations declare readOnlyHint=false and destructiveHint=false; the description goes further by disclosing the observable effect ('Records planned milestone scope') and a hard failure condition (nonempty acceptance_evidence is rejected). It does not discuss retry/idempotency behavior despite idempotentHint=false, though the request_id parameter description in the schema partly covers that.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and the alternative route, then labeled Prerequisites/Effects lines that scan quickly. The trailing 'Exact help' boilerplate with the operation_name substitution instruction is lower-value and slightly bloats an otherwise tight definition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 10-parameter governed mutation with an output schema, the description covers purpose, prerequisites, effect, rejection rule, and the sibling alternative, so an agent has enough to invoke it correctly. Minor gaps remain around failure/retry semantics, which the request_id schema description only partly addresses.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds genuine meaning beyond the schema for the two highest-risk inputs: acceptance_evidence is a 'reserved compatibility input' that must stay empty, and the requirement/dependency/policy inputs are framed as prerequisites the caller must supply. That is useful routing information, though no syntax or format detail is added.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Create planned milestone scope') and immediately names the contrasting sibling ('Actual result acceptance uses fow_accept_milestone'), so the agent can separate scope planning from acceptance without opening either schema. The scope is further bounded by the inputs it draws from (requirements, dependencies, entry/exit/risk policies).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use ('Create planned milestone scope...'), when-not (rejects nonempty acceptance_evidence; promotion does not accept the result), and the alternative route (fow_accept_milestone). It also answers the invocation-shape question directly: 'Single operation; call directly without an operation argument.'

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

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

Annotations mark this as a non-read-only, non-idempotent, non-destructive mutation; the description is consistent and goes further by saying it 'appends declared evidence/provenance' and explicitly disclaims test execution, provider auditing, and acceptance granting. Retry/receipt behavior is only gestured at ('inspect exact operation help'), leaving idempotency semantics thin given 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded purpose followed by labeled Prerequisites/Effects blocks, which is easy for an agent to scan. The trailing 'Exact help' pointer with a literal fow_capabilities call is useful but adds length; overall every block earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 no explanation, and the description covers purpose, prerequisites, effects, and single-operation invocation. Given 8 parameters and a retry/receipt surface implied by request_id, the reliance on external operation help for receipt policy is the only real gap.

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

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

Schema description coverage is 100% across all 8 parameters, so the schema already carries the semantics. The description echoes the key inputs (verification method, outcome, reference, declared metadata) and reinforces that evidence must be 'actually obtained', but adds no format, enum, or constraint detail beyond the structured fields. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (record evidence obtained for a requirement) plus the concrete payload it captures (method, outcome, reference, metadata). The sentence 'This records a result rather than running a test' actively distinguishes it from execution-oriented siblings such as fow_run or fow_assurance, so an agent can route without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit prerequisites (an existing requirement and evidence actually obtained by the declared verification method) and boundary conditions (does not execute tests, audit a provider, or grant acceptance). It also routes to fow_capabilities for exact operation help. It stops short of naming the sibling tool to use instead when the goal is actually running a test, which would make the when-not guidance complete.

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

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

Annotations cover the safety profile (non-readOnly, non-destructive, non-idempotent), and the description adds real behavior beyond that: it appends 'canonical requirement authority with declared source anchor and receipt' and clarifies it does not implement or accept the requirement. This is meaningful context layered on top of the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core action in the first sentence, then organizes Prerequisites and Effects as labeled lines, closing with a precise help pointer. Every sentence carries information; nothing is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return-value explanation is unnecessary, and the description correctly points the agent at the returned requirement ID. Prerequisites, effects, and single-operation guidance are all present. Minor gap: no explicit pairing to the nearest siblings (get/revise requirement).

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

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 8 parameters (project_id, statement, rationale, actor, request_id, source_anchor, etc.). The description only alludes to source_anchor and project implicitly, adding no syntax or format detail beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Record one observable software requirement and its source in the selected lifecycle project.' It is distinguishable from fow_revise_requirement by the 'record' framing, though it never names that sibling explicitly to draw the boundary.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete usage context: 'Use the returned requirement ID for goals, milestone scope and verification' plus an explicit Prerequisites line ('existing project and an observable requirement statement') and a negative scope ('does not implement or accept it'). No sibling alternatives (e.g. revise/import) are named, 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.

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

Annotations already declare destructiveHint=true and idempotentHint=false; the description adds valuable context beyond that: the revision is immutable, existing evidence is not rewritten or made current, and downstream currentness/closure may change. This is exactly the kind of non-obvious consequence disclosure the annotations cannot convey, though it omits explicit permission/authorization error behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action, then cleanly labeled Prerequisites and Effects. Every sentence carries content, though the trailing 'Exact help' template line is somewhat boilerplate-heavy for a description whose sibling fow_capabilities already exists.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, non-idempotent mutation with an output schema present, the description covers prerequisites, the append-only semantics, and downstream effects. The receipt/retry story is delegated to the schema's request_id and the help route, which is reasonable given the output schema exists.

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

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

Schema coverage is 100% and each of the 9 parameters carries its own description (actor, title, category, rationale, statement, requirement_id, project_id, request_id, source_anchor), so the schema does the heavy lifting. The prose mentions statement and classification but adds no syntax or format detail beyond the schema, so a baseline-plus score is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Change the statement or classification of an existing requirement') plus the mechanism ('by appending a canonical revision'). Combined with the prerequisite/effects framing, an agent can distinguish this from register_requirement (new) and set_requirement_lifecycle (state) without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear invocation context ('Single operation; call directly without an operation argument') and explicit prerequisites ('Investigate the existing requirement and authorize any actual change of intent first'). It does not name a sibling alternative to route to when the change is a lifecycle transition rather than a revision, which keeps it 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.

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.

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.

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.

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.

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.

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.

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

Annotations already flag destructiveHint=true, readOnlyHint=false, idempotentHint=false, but the description adds genuine context beyond them: that the coding agent acts outside Flower, that cancellation changes live authority, and that Flower never executes declared step actions. These are meaningful behavioral disclosures for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads purpose, then routing, prerequisites, effects, and a help pointer in a compact block. Slightly redundant, repeating the non-execution point twice ('performs those actions outside Flower' and 'Flower does not execute the declared step actions').

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Because an output schema exists, return values need not be described; the description covers routing, prerequisites, and effects for a complex 22-parameter multiplexer. It reasonably defers exact per-operation detail to fow_capabilities, though that leaves some ambiguity resolvable only by a follow-up call.

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

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

Schema description coverage is 100%, so every parameter is already documented with its per-operation applicability and requiredness. The description adds only the conceptual grouping of operations, so the baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Track who performs the implementation work: record a run, ordered dependent steps...') and enumerates the eleven canonical routes, so an agent can distinguish it from sibling multiplexers like fow_packet_advance or fow_campaign_advance without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear operational context (route via 'operation', prerequisites of a governed change/packet and existing IDs) and points to fow_capabilities for exact per-operation help. It stops short of explicitly naming when to prefer this tool over adjacent siblings.

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

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

Annotations declare non-readonly/non-idempotent/openWorld, so the safety profile is already carried. The description goes beyond them with per-route effects (prepare persists a prompt/authority snapshot, submit validates, adopt records declared provenance, execute_internal invokes inference) and a server-side file-read note, which is genuinely additive context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Structure is front-loaded: a one-line purpose sentence, then routing, prerequisites, effects, and a help pointer, each earning its place. For a six-route multiplexer it is dense but not wasteful; the trailing capabilities-help pointer is functional rather than filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need not be explained, and the description covers routing, prerequisites, per-route effects, and unsupported cases. Given the six-operation complexity it is largely complete, though it leaves the actual per-route field requirements to the referenced fow_capabilities help rather than stating them inline.

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

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

Schema description coverage is 100% and the schema already documents roles, execution modes, source path containment, and receipt/idempotency semantics at param level. The description adds little param-specific meaning beyond repeating the operation routes, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states concrete verbs and resources across the multiplexed operations (prepare bounded semantic assignments, validate submitted results, adopt audit evidence) and names the two supported roles. It is clear what the tool does, but it does not explicitly differentiate itself from siblings like fow_validate_srs or fow_ground_intent, whose names overlap with the roles it claims.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an explicit prerequisite sequence ('Use inventory, then prepare a supported role in host or internal mode; internal needs configured inference') and routes via the operation selector, plus an explicit exclusion ('Observed-behavior drafting is unsupported'). It stops short of telling the agent when to choose this tool over a sibling, so it is clear context without full alternative routing.

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

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

Annotations declare destructive=true and idempotent=false, and the description meaningfully extends them: ordinary guards apply, retirement/rejection can invalidate active authority, and human approval is not inferred by the tool. That tells the agent the blast radius of a state change, which the annotations alone do not.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded one-line purpose followed by labeled Prerequisites and Effects blocks that are easy to scan. The trailing capabilities-help pointer is useful but slightly boilerplate-y, keeping it short of a flawless 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, non-idempotent mutation with 7 parameters and an output schema, the description covers prerequisites, mutation effects, approval expectations, and even points to exact operation help for receipt/retry policy. Nothing an agent needs before calling is missing.

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

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 actor identity, reason, project vs. requirement IDs, request_id replay semantics, and the canonical lifecycle_status values. The description only restates that a reason and a policy-required approval reference accompany the move, adding negligible syntax or format detail beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: moving an existing requirement to a policy-permitted lifecycle state, with reason and approval reference. It also clarifies the invocation shape ('single operation; call directly without an operation argument'), which separates it from multi-route siblings. It stops short of naming the nearest neighbor (fow_revise_requirement), so the boundary is inferable rather than explicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear usage context plus prerequisites ('use an existing requirement and the approval reference required by its transition policy') and a call-directly instruction. No alternatives or when-not-to-use conditions are named, 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.

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world behavior, so the bar is lower. The description still adds real value beyond them: bounded paged reads, no provider/model execution, and no authority mutation — useful scoping for an inspection tool. It does not note rate limits or auth specifics, but nothing is contradicted.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Content is front-loaded and organized under Prerequisites/Effects labels, which helps scanning. The trailing 'Exact help' pointer to fow_capabilities is a useful affordance but adds boilerplate length, keeping it short of maximally tight.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With rich annotations, full schema coverage and an output schema, the description does not need to explain return values and correctly avoids doing so. It covers prerequisites, effects and pagination adequately; only the relationship to sibling inspection tools remains unstated.

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

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

Schema coverage is 100%, so the baseline would be 3. The description goes slightly beyond the schema by conveying that milestone and evidence ID are alternative optional selectors and that audit detail is a distinct projection, which the raw schema does not spell out as relationships. It still doesn't clarify limit/offset semantics, so it is not a full 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Inspect') and a concrete resource set (requirements, milestone scope, recorded verification evidence and how they correspond). It is clearly traceability-oriented, but it never names a sibling tool it must be distinguished from, so the agent must infer the boundary with tools like fow_get_requirement or fow_audit_phase.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives operating context ('Single operation; call directly without an operation argument') and prerequisites ('Select a project and optionally a milestone or exact evidence ID'), which tells the agent the entry conditions and the two read modes. It does not, however, state when to prefer this over the neighboring requirement/evidence tools, so the exclusions are only implicit.

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

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

Annotations already establish the profile (not read-only, not destructive, not idempotent, open world), so the bar is lower. The description still adds real context: a durable job is scheduled, the source is read, and no baseline import/acceptance occurs. It does not spell out receipt/retry policy, deferring that to the operation help, which keeps it at a 4 rather than 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action in the first clause, then organized under compact labeled lines (Prerequisites, Effects) with no filler. The help-pointer line is a deliberate routing aid rather than padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need no explanation, and the description covers scope, prerequisites, and non-effects for a mutation-class tool. It stops short of saying how the resulting durable job is polled (fow_get_job), leaving a small gap an agent must infer from siblings.

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

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

Schema description coverage is 100%, so all five parameters are already documented in the schema, including the server-side source_path constraint and the actor identity. The description only restates 'readable local Markdown SRS and supported standard_profile' and the profile-consistency advice, adding little beyond the schema — the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — structural validation of a local Markdown SRS against a supported profile — and explicitly bounds the scope by naming the sibling that handles the other half ('Semantic assignment validation is exposed separately by fow_semantic'). An agent can distinguish this from fow_import_srs and fow_semantic without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives prerequisites (readable local Markdown SRS plus supported standard_profile), an explicit when-not (semantic checks belong to fow_semantic; this does not import or accept a baseline), and disambiguates invocation ('Single operation; call directly without an operation argument'). It also routes to fow_capabilities for exact help.

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

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

Annotations already declare readOnly/idempotent/non-destructive/no-open-world, but the description adds real context: no code execution and no provider probes, plus that output arrives as bounded pages to be followed. It stops short of describing limits on the projection itself.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the purpose, then cleanly separates Prerequisites and Effects, so an agent can scan the constraints it needs. The trailing 'Exact help' pointer is somewhat meta boilerplate but is compact and self-contained.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return shape need not be explained, and the description covers prerequisites, read-only effects and pagination behavior for a 6-parameter tool. The main residual gap is explicit guidance on which sibling to call when the agent intends to act on the suggested work.

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

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

Schema description coverage is 100%, so limit, offset, scope_id, project_id, detail_level and milestone_id are all documented in the schema. The description only loosely gestures at project/scope/milestone selection and adds no format or syntax detail beyond that, matching the baseline for fully-covered schemas.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: it finds 'the next bounded lifecycle action' derived from gates, dependencies, requirements and evidence. It also implicitly separates itself from execution siblings by asserting that reading the projection does not execute work, though it never names those siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides a concrete prerequisite ('select existing project/scope and optional milestone, then follow returned bounded pages') and notes it is a single direct operation with no operation argument. The contrast with execution tools is implied rather than stated, so the when-not condition is left to inference.

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