nifi_bind_parameter_context

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

Annotations already cover readOnly=false, idempotent=true, destructive=false, so the bar is lower, yet the description adds real behavioral context beyond them: the default maps to the UI's 'Apply recursively', descendants' existing contexts are replaced, and the operation is atomic ('NiFi checks every group before changing any, so an error means no group was rebound'). It omits auth/permission requirements and error/report format, keeping it from 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 with the core action and its purpose, then behavioral detail in two compact paragraphs. Sentences carry distinct content (purpose, recursive default, atomicity, non-recursive option), though verbose/verbose-field prose could be trimmed.

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 the essential behavior a caller needs for this mutating tool. It is nearly complete, with the only gap being explicit auth/permission or failure-mode guidance.

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 schema coverage reported at 0%, the description compensates for the ambiguous parameters by explaining that 'null unbinds' the group (parameter_context_id) and that apply_recursively=false scopes the bind to only this group. It leaves verbose and process_group_id unaddressed in prose, so it only partly covers the parameter set.

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 ('Bind a parameter context to a process group') and gives the effect ('so #{name} references resolve'), which lets an agent distinguish this from sibling CRUD tools like nifi_create_parameter_context. It does not explicitly route the agent away from any sibling, 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?

The description implies the use case (resolving #{name} references) and implicitly guides parameter choices ('null unbinds', 'apply_recursively=false binds only this group'), but gives no explicit when-to-use/when-not and does not name alternatives or prerequisites. Usage 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.