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 still adds value by disclosing the underlying endpoints (GET /flow/about and /flow/current-user) and that it doubles as a connectivity check, which the annotations do not convey.

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?

Two sentences plus a two-line endpoint note, with the identity of the resource front-loaded and the usage directive immediately after. Nothing is wasted and nothing is buried.

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 connectivity check plus generation identification. Its only gap is not clarifying the division of labor with the very similarly named nifi_get_version_info sibling.

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?

The tool takes zero parameters, so per the rubric this is a baseline 4. There is no parameter meaning to add or omit.

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 resource (version, build, and identity information) for a named target (the connected NiFi instance), so the agent knows exactly what the tool returns. It does not differentiate itself from the sibling nifi_get_version_info, which is an overlapping concern, keeping it 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 a clear directive: 'Use this first to confirm connectivity and learn which NiFi generation you are talking to.' That tells the agent when to reach for it. It names no alternative or exclusion (e.g., versus nifi_get_version_info), so it stops short of explicit 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 the safety profile (readOnly, idempotent, non-destructive). The description adds no behavioral context beyond what annotations provide — it does not mention return format, rate limits, authentication, or any other operational trait. 'Backed by GET /counters' is redundant with readOnlyHint.

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 two brief sentences with no waste, front-loading the resource and current values. It is appropriately sized for a simple, zero-parameter 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?

Given the tool has no parameters, complete annotations, and an output schema, the description is nearly sufficient — the output schema handles return values. The only missing element is usage context relative to sibling tools, which is minor for a simple read operation.

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?

There are zero parameters, so the baseline is 4. No parameter semantics are needed, and the schema coverage is fully sufficient.

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 the resource (flow counters) and what it returns (current values), making it clear what the tool does. It lacks a verb and does not explicitly differentiate from siblings, but the resource is specific enough that an agent can identify its purpose.

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?

There is no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. The description only identifies the resource, leaving usage context entirely 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 readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds the backing endpoints (GET /flow/processor-types and /flow/controller-service-types), which is modest extra context, but says nothing about result volume, pagination, or ordering beyond the presence of a `limit` parameter.

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 action, then usage, then parameter semantics — a sensible order with no filler. The endpoint citation is mildly implementation-level but short, and the trailing newline formatting is harmless.

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 structure need not be described, and annotations cover the safety profile. Kind semantics and query scope are covered; what remains thin is `limit` behavior and whether results are ranked or paginated, which an agent might need for a catalogue search.

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 0%, so the description carries the burden. It defines the meaningful `kind` values ("processor", "controller_service", "both") that the schema leaves as an unconstrained string, and clarifies that `query` matches name, tag, or description. It does not explain `limit`, which is the remaining gap.

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 gives a specific verb (search) and resource (catalogue of installable component types) plus the searchable facets (name, tag, description). It implicitly separates itself from instance-listing siblings like nifi_list_processors by making clear these are installable *types*, not running components.

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 states the workflow: find the correct type before calling nifi_create_processor. That is clear usage context, but there is no when-not guidance (e.g., use nifi_list_processors instead when you want running instances) and no mention of prerequisites such as permissions.

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, so the safety profile is covered. The description usefully adds that it aggregates two endpoints (/flow/status and /flow/bulletin-board), but discloses no behavioral caveats such as cost, caching, or aggregation scope tradeoffs.

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?

Two compact sentences: the payload summary is front-loaded, followed by a backend endpoint note and a one-line use-case tag. Every clause carries information with no filler, though the endpoint detail is slightly lower value.

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 zero parameters remove all invocation ambiguity. The description is complete enough for the agent to select and call it, though a named alternative would fully close the loop.

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?

The tool takes zero parameters, so the baseline is 4. There is nothing for the description to disambiguate, and none of the schema's empty surface needs compensating.

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 ('Aggregate controller status') and enumerates the content returned (running/stopped/invalid counts, queued data, bulletins). The controller-wide scope implicitly distinguishes it from the process-group-scoped sibling nifi_process_group_status, though no sibling is named.

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 fastest way to answer "is anything wrong right now?"' frames the use case as a quick health check, which is implied guidance. However, it names no alternatives (e.g., nifi_system_diagnostics or nifi_list_bulletins) and states no when-not condition, leaving the routing 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 cover the safety profile (readOnly/idempotent/non-destructive), so the bar is lower. The description adds useful behavior: depth bounds the recursion and beyond-depth groups are returned by id/name only, plus the backing endpoint. It doesn't mention pagination or response size limits, keeping it at a 4.

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 sentences: the what, the backing endpoint/behavior, and the guidance. Front-loaded with purpose and zero 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?

Output schema exists so return format needn't be described. Given a read-only overview tool with annotations and an output schema, the description supplies the meaning of depth and the entry-point guidance. It leaves pg_id and include_components unaddressed but the core is complete.

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 0%, so the description must compensate. It explains the semantics of `depth` ('bounds the recursion; groups beyond it are listed by id and name only'), which is the key non-obvious parameter behavior. It doesn't cover pg_id or include_components, so 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?

States a specific verb+resource (recursive process-group tree with processors and connections) and clearly distinguishes itself from siblings by being the high-level 'understand a flow's shape' entry point. The final sentence 'Start here to understand a flow's shape' explicitly routes the agent.

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 context ('Start here') positioning it as an overview tool versus the many list/get siblings. However it does not explicitly name an alternative (e.g., nifi_get_process_group_contents) or state when-not-to-use.

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?

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the underlying GET endpoint and a concise summary of returned fields, but says nothing about authentication, rate limits, or 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?

Two short, front-loaded lines with no wasted words. The retrieved fields are listed first, followed by the backing endpoint, making the description easy to scan.

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 structure need not be explained, and annotations already cover the safety profile. However, the description leaves the verbose parameter completely opaque and provides no usage context, which is a clear gap for a tool with undocumented parameters.

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 0%, yet the description does not explain either parameter. It never mentions connection_id or what the optional verbose flag changes, so it fails to compensate for the schema's silence.

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 identifies the resource as a single connection and enumerates the key details returned (endpoints, routed relationships, queue depth, prioritizers). The word 'One' implicitly distinguishes it from the sibling nifi_list_connections, but no explicit verb or alternative tool is named.

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?

There is no guidance on when to use this tool versus alternatives such as nifi_list_connections or nifi_queue_listing. The description only states what is returned, leaving the agent to infer that this is for retrieving a known connection by ID.

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, so the safety profile is covered. On top of that the description adds genuinely new context: the backing endpoint (GET /controller-services/{id}) and that sensitive values are masked in the response — a useful caveat an agent would not get from 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?

Two tight sentences that front-load the payload description before the implementation detail. No filler; every clause 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-value explanation is not required, and the description does sketch the returned content and the masking behavior. However, with 0% parameter schema coverage, the undefined meaning of service_id and verbose is a real completeness gap for a lookup 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 0%, so both parameters (service_id, verbose) are undocumented anywhere. The description never explains that service_id identifies the service or what verbose toggles, leaving the agent to guess the meaning of the verbose flag.

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 and scopes it as a single item ('One controller service'), with a clear inventory of what it returns (properties, state, references). This implicitly distinguishes it from the sibling list tool nifi_list_controller_services, but never names it 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?

No when-to-use guidance, prerequisites, or named alternatives. The word 'One' hints at single-record retrieval versus listing, but the agent must infer this. Nothing tells the agent when to prefer this over nifi_list_controller_services or nifi_get_processor.

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 the useful distinction that this returns metadata/attributes (not content) and discloses the backing REST endpoint, but says nothing about auth needs, rate limits, or behavior for missing/expired flowfiles.

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?

Two short lines, front-loaded with the purpose, no filler. The endpoint line is compact and adds provenance, though it is arguably redundant with the tool name.

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 shape need not be described. However, in a large sibling set with an adjacent content tool, the absence of parameter explanations and routing guidance leaves the definition only minimally sufficient.

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 0%, so the description must carry the parameter burden, and it does not. Neither connection_id nor flowfile_uuid is explained; the agent can only infer their meaning from the endpoint template and the phrase 'one queued flowfile'.

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 resource and scope: metadata and attributes for exactly one queued flowfile, which is enough to distinguish it from nifi_get_flowfile_content (content) and nifi_queue_listing (bulk). It does not name those siblings explicitly, 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?

There is no when-to-use statement, no prerequisites, and no mention of the alternative tools an agent should consider (content retrieval vs. metadata, queue listing vs. single item). The phrase 'queued flowfile' only loosely implies the context.

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, so the safety profile is covered. The description adds genuinely useful behavior beyond that: truncation to max_bytes, base64 encoding for binary payloads, the `encoding` field as the signal, and the backing REST endpoint. It stops short of noting edge cases such as missing/expired flowfiles.

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 short clauses, front-loaded with what is returned, then the truncation rule, then the encoding caveat and provenance URL. No filler or repetition.

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 in prose; the description nonetheless usefully discloses that binary payloads come back base64-encoded. With only partial parameter explanation and no alternative routing, it is complete but not exhaustive.

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 0%, so the description carries the burden, yet it only explains max_bytes (truncation limit). connection_id and flowfile_uuid are named but never explained — that a UUID identifies a specific queued flowfile within a connection is left implicit, only partly recoverable from the URL template.

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: retrieving the content of one queued flowfile. The word 'content' implicitly separates it from the metadata-oriented sibling nifi_get_flowfile, but the description never explicitly names or contrasts that sibling, so sibling differentiation is left to inference.

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?

There is no explicit when-to-use guidance, no stated preconditions (the flowfile must be queued in a connection), and no mention of the sibling nifi_get_flowfile as the metadata-only alternative. Usage context is only implied by the noun phrase 'Content of one queued flowfile'.

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 readOnly, idempotent, non-destructive behavior. The description adds genuinely new context: the backend is POST /provenance/lineage and the result is polled to completion, which tells the agent to expect latency and eventual completion rather than an instant response. That is real behavioral disclosure beyond the annotation set.

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?

Two short sentences, front-loaded with the return shape, followed by the operational note and the input rule. No filler and no repetition of schema 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-value explanation is not needed. The core gap is the undocumented `direction` parameter and the absence of any guidance on choosing among provenance-related siblings, leaving the definition only adequate for a graph-retrieval 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 coverage is 0%, so the description carries the full burden. It explains the flowfile_uuid/event_id relationship but leaves the `direction` parameter completely undefined — no hint that values like PARENTS exist or which are valid, and no enum is declared in the schema. Two of three parameters get partial treatment; the most semantically loaded one gets none.

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 returns the lineage graph for a flowfile, described as nodes and links. That is clearly distinct from data-returning siblings like nifi_get_flowfile_content or filter-oriented ones like nifi_provenance_query, though it never explicitly names an alternative. Clear but with no sibling differentiation in text.

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 line 'Supply either `flowfile_uuid` or `event_id`' gives an input-selection rule, which is useful constraint information. However, it says nothing about when to reach for this tool versus nifi_provenance_query or nifi_get_provenance_event, so usage context is only 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 readOnlyHint, idempotentHint, and destructiveHint=false. The description adds useful scope by stating it returns parameters and bound process groups and mentions the backing GET endpoint, but it does not describe auth needs, pagination, or other behavioral traits.

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 only two sentences, front-loads the tool's purpose, and avoids waste. The second sentence about the backing endpoint is minor but informative context.

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 simple single-parameter getter, an output schema exists and annotations cover safety. The description states the returned content, but the context_id parameter remains unexplained and no usage guidance is provided, leaving moderate gaps.

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 0%, so the description must compensate for the undocumented context_id parameter. It does not explain what context_id is, its format, or where to obtain it, leaving the single required parameter without descriptive support.

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 resource and scope: one parameter context with its parameters and bound process groups. The singular 'one' distinguishes it from the sibling list_parameter_contexts, though no sibling is named 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?

No when-to-use guidance is given. The description does not explain when to choose this tool over nifi_list_parameter_contexts or other getters, leaving usage 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 readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds only the backing endpoint (GET /process-groups/{id}) and the 'root' default note; it says nothing about the cost of the call, pagination, or what 'verbose' changes behaviorally.

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?

Two short lines, front-loaded with the returned data and followed by the endpoint and the key default. Near-zero waste, though the opening noun fragment reads as a caption rather than a complete statement of action.

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 field-level return documentation is unnecessary, and the description does summarize the returned categories. However, with an undocumented 'verbose' parameter and no sibling differentiation, the definition is only minimally complete for an agent choosing among the many process-group 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 0% with two undocumented parameters. The description partially explains pg_id by noting that 'root' selects the top-level group, but the 'verbose' flag is left entirely unexplained in both schema and description, which is a meaningful gap given it presumably alters the response.

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 the resource (a process group) and enumerates the specific data returned: identity, component-state counts, and version-control state. It is a noun fragment rather than a verb phrase, and it never explicitly contrasts itself with close siblings like nifi_process_group_status or nifi_get_process_group_contents, so an agent must infer 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?

The only guidance is the parameter hint 'Pass "root" for the top-level group', which is argument syntax, not usage context. There is no statement of when to call this versus nifi_process_group_status or nifi_get_process_group_contents, and no preconditions.

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, and non-destructive, so safety is covered. The description adds genuinely useful behavioral context beyond that: the non-recursive scoping and the backing endpoint. It does not discuss return size or response shape, but the output schema exists, so the gap is minor.

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 sentences, front-loaded with the return contents before the differentiating note. Every sentence carries information; no 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 and annotations covering the safety profile, the description only needs to convey purpose and scoping, which it does. The one real gap is the undocumented 'verbose' flag, which the description should have clarified given 0% schema coverage.

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 0% and the description never mentions the two parameters. The 'pg_id' argument (default 'root') and especially the 'verbose' flag are left entirely unexplained, and the text does not compensate for the coverage gap despite the low baseline requiring 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?

Names a specific verb and resource ('direct contents of one process group') and enumerates what it returns (children, processors, connections, ports). It explicitly contrasts with the sibling nifi_flow_tree, so an agent can distinguish the two 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?

States the selecting condition ('cheaper choice when inspecting a single group') and names the alternative it is not ('Unlike nifi_flow_tree this does not recurse'). This is explicit when-to-use and which-alternative 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 declare readOnly/idempotent/non-destructive, but the description adds real context beyond them: it maps to the underlying GET /processors/{id} endpoint and discloses that sensitive property values are masked. That masking note is a genuinely useful behavioral trait not derivable from 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?

Two short sentences, front-loaded with the payload summary and followed by the endpoint/masking note. Zero filler; every clause 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 spelled out, and the description still summarizes the returned content. For a read-only single-resource fetch it is essentially complete, with only the 'verbose' parameter left unexplained.

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 0% and the description says nothing about either parameter. processor_id is inferable from the name, but 'verbose' is completely undocumented in both the schema and the description, so the description fails to compensate for the coverage gap.

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 ('One processor in full') and enumerates what the response contains (properties, scheduling, relationships, validation errors). The singular 'One processor' implicitly distinguishes it from the sibling nifi_list_processors, but no alternative is named 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?

Usage is only implied: needing full detail on a single processor with a known id. There is no explicit when-to-use or when-not-to-use guidance, nor a pointer to nifi_list_processors or nifi_search for discovering processors first.

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=true, idempotentHint=true, destructiveHint=false, so the safety profile is fully covered structurally. The description adds useful context by naming the backing endpoint and the shape of returned data, but beyond that it discloses no further behavioral traits (e.g., token/rate behavior or behavior when the property name is invalid).

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 key information and kept to two tight sentences with no padding. The endpoint detail is slightly extraneous but still earns its place by grounding behavior.

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 spelled out, and annotations cover the safety profile. For a simple descriptor lookup with two params, the description supplies enough to call it correctly, with only parameter format guidance 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 0% for two required parameters, so the description must carry the burden. It implies a single processor and a single named property, but adds no format, expected identifier style, or validity guidance for processor_id or property_name, leaving the agent to infer parameter 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+resource ('Descriptor for one processor property') and enumerates the returned fields (type, default, allowable values), so an agent knows exactly what it produces. It doesn't explicitly differentiate itself from the many list/get siblings, which keeps it 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 a concrete when-to-use condition: call it before setting a property whose valid values are unknown. That is genuinely actionable context. It stops short of naming an alternative tool, so it's 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 readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety/behavior profile is covered. The description adds almost nothing beyond that – no mention of behavior on missing events, size of before/after sets, or access requirements.

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?

Two tight lines: the primary purpose is front-loaded and the endpoint reference is a short follow-up. Zero 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?

A simple read-only fetch with an output schema, so no return-value explanation is needed. Annotations cover safety. The main gap is the missing link to the query tool that produces event IDs, which is important for correct usage.

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 0% with 1 required param ('event_id'), so the description must compensate. It does so by implying the identifier comes from the provenance endpoint and that the event contains before/after attribute sets, but doesn't give format or source details. Baseline 3 is borderline; the description adds slight value but leaves format ambiguity.

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?

Names a specific verb+resource ('One provenance event') and clarifies the scope ('full before/after attribute set'), plus the backing endpoint. It distinguishes itself implicitly from nifi_provenance_query by being a single-event fetch, but does not explicitly name the 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?

No guidance on when to use this versus nifi_provenance_query or nifi_get_lineage, nor any prerequisites. The endpoint is stated but that's not usage 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds only the backing endpoint (GET /process-groups/{id}) and a rough sketch of returned fields; it does not describe behavior for non-versioned groups or edge cases, so it adds modest value beyond 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?

Two terse lines, front-loaded with the resource and the fields returned. It is efficient with no filler, though the endpoint note is somewhat redundant given the single-tool context.

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-value exposition is not required, and the safety profile is carried by annotations. The remaining gap is the undocumented pg_id parameter and the absence of any routing guidance among sibling tools, leaving it only minimally complete.

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?

There is exactly one parameter (pg_id, default 'root') with 0% schema description coverage, so the description carries the burden of explaining it – and it says nothing about pg_id or the 'root' default. It fails to compensate for the schema gap, though the parameter is simple and self-evident from its name.

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: it returns the 'version-control state of a process group' enumerating registry, bucket, flow, and version. This is precise enough for an agent to grasp the purpose, though it never distinguishes itself from sibling read tools like nifi_get_process_group or nifi_get_process_group_contents.

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 gives no when-to-use guidance, no conditions, and no exclusions relative to the many sibling read tools. Usage is only implied by the topic ('version-control state'), leaving the agent to guess when this is preferable to nifi_get_process_group.

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, and non-destructive, so the safety profile is covered. The description adds the upstream REST endpoint and the diagnostic intent, but says nothing about ordering, freshness, or filtering behavior. Adds modest value on top of 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?

Three tight lines: a definition, a backing endpoint, and a usage cue. Front-loaded with the core definition. The endpoint line is arguably low-value to an agent but harmless and brief.

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-value explanation is not required. The main gap is the undocumented limit parameter, but for a simple read-only listing tool the description is otherwise complete enough to call 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?

One parameter (limit) with 0% schema description coverage and no mention in the description. An agent cannot tell what limit caps, its units, or its default behavior from either source. The description should compensate for the coverage gap but does not.

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 ('list bulletins') and defines what bulletins are (NiFi's warning and error notices), which is genuinely clarifying for an ambiguous domain term. It doesn't explicitly distinguish from siblings like nifi_flow_status or nifi_system_diagnostics, but the resource is specific enough.

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 diagnostic context: 'The first place to look when a processor is failing but its configuration looks correct.' This is a real when-to-use signal. It doesn't name an alternative or exclusion, but the triggering condition 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 already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description earns credit by disclosing payload semantics: `queued.count`/`queued.bytes` are numeric while `_display` variants are formatted strings — a non-obvious trait that helps the agent parse results.

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?

Two short sentences plus the endpoint reference, front-loaded with the operation and scope. Efficient with no filler, though the trailing payload note is slightly clipped in presentation.

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 single-parameter read tool with an output schema and full annotation coverage, the description is essentially complete. The one gap is that pg_id behavior (default root) is left entirely to the 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 0% for the single pg_id parameter, so the schema documents little. The description only implies the ID via the endpoint template ('process-groups/{id}/connections') and never explains the default 'root' meaning, leaving the parameter semantics thin.

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 ('Connections in a process group') and adds scope detail (queue depth and backpressure settings). It is clearly distinguishable from the singular nifi_get_connection, though it does not explicitly name siblings it should not be confused with.

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?

No when-to-use guidance, no alternatives named, no exclusions. The agent must infer from the name and the backing endpoint (GET /process-groups/{id}/connections) that this is a read-listing operation scoped to one process group.

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 that results include state and referencing components and cites the backing endpoint, which is useful context beyond the annotations, but it says nothing about pagination or the visibility semantics of 'visible'.

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?

Two short, front-loaded sentences with no filler. The endpoint citation is marginally decorative but harmless.

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-value detail is not required, and annotations cover safety. However, with two undocumented parameters and no usage routing against a large sibling set, the definition is only minimally complete.

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 0% and the description adds no meaning for either parameter. Neither pg_id (including the 'root' default) nor include_ancestors (which controls whether ancestor-scoped services are included) is explained, leaving the agent to guess at their effect.

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?

Names a specific resource (controller services) and scope (visible to a process group), plus what the results contain (state and referencing components). It does not explicitly differentiate itself from the sibling nifi_get_controller_service (singular, by id), though the plural 'list' in the name makes the distinction reasonably inferable.

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?

There is no statement of when to use this tool versus nifi_get_controller_service, nifi_list_parameter_contexts, or nifi_get_process_group_contents. The agent must infer its place in the family from the name alone.

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 genuinely useful context beyond the annotations: sensitive values are masked in the output, and it discloses the backing endpoint (GET /flow/parameter-contexts).

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?

Two short sentences: the payload description is front-loaded, followed by the masking caveat and the endpoint. Every sentence earns its place with no 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?

An output schema exists, so the description need not enumerate return fields; it correctly confines itself to what is returned (contexts plus parameters) and the masking behavior. For a zero-parameter, read-only listing tool this is essentially complete, with only the list-vs-single routing 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?

The tool takes no parameters, so per the rubric the baseline is 4. There is nothing for the description to disambiguate, and it introduces no contradictory parameter talk.

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 the exact resource ('all parameter contexts and their parameters'), which cleanly distinguishes this list operation from the singular sibling nifi_get_parameter_context. It lacks an explicit verb like 'List', but the scope is unambiguous and an agent can match it to the right task.

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?

Usage is only implied: the plural 'all parameter contexts' suggests this is the bulk-retrieval option versus nifi_get_parameter_context for a single context, but the description never states that condition or names the alternative. No exclusions or prerequisites are given.

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 the returned attribute categories and the backing REST endpoint, which is useful for debugging, but says nothing about pagination, result size, or the default non-recursive scoping 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?

Two very short sentences with the resource and returned fields front-loaded and no filler. The REST endpoint line is marginal but plausible for debugging, so it does not seriously hurt the structure.

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 annotations cover safety. However, with 0% parameter coverage and no usage routing, the definition is only minimally viable for an agent deciding between this and several overlapping listing 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 0%, so the description carries the full burden for two parameters. It implies process-group scoping (pg_id) but is silent on include_descendants and on the 'root' default, leaving the recursion semantics completely undocumented in either place.

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 (list) and resource (processors) scoped to a process group, and even names the returned attributes (run status, validity, throughput). It implicitly distinguishes itself from the singular sibling nifi_get_processor, though it does not name any sibling 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?

The description gives no when-to-use guidance and never mentions alternatives such as nifi_get_process_group_contents, nifi_flow_status, or nifi_flow_tree, which overlap in listing/status territory. The agent must infer the routing decision entirely from the tool name.

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 safety is fully covered. The description's only added behavioral detail is the underlying REST endpoint (GET /controller/registry-clients), which is useful provenance but not operationally significant. It says nothing about pagination, filtering, or what happens on error.

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?

Two short lines, resource stated first, endpoint noted second. No waste, though the endpoint line is marginally informative rather than essential.

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 annotations carry the safety profile. The only real gap is the absence of sibling-routing guidance, which matters given the many similarly named nifi_list_* 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?

The tool takes zero parameters, so the baseline is 4. There is nothing for the description to compensate for, and the empty schema is unambiguous.

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 the resource precisely (NiFi Registry clients) and scopes it to 'configured on this instance', which distinguishes it from flow/process-group tools. The 'list' verb is only implied from the name rather than stated in the description, and no sibling is named, 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?

There is no when-to-use guidance, no conditions, and no mention of alternatives such as nifi_list_controller_services or nifi_list_parameter_contexts. The agent must infer the usage context entirely from the tool name.

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=true, idempotentHint=true, destructiveHint=false, so safety is covered. The description adds the recursive scope and the backing REST endpoint, which is useful context. It does not add rate-limit, auth, or freshness caveats beyond that, so a middle score is appropriate.

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?

Two short parts, front-loaded with the purpose and followed by the endpoint reference. No wasted prose. Not a 5 only because the endpoint line is arguably redundant given the tool name and adds little for an agent.

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?

There is an output schema, so return values need not be explained. Annotations cover safety. The main gap is that the description doesn't clarify how the recursive scoping affects output size or when a non-recursive status is preferable. Otherwise complete for a low-complexity read 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?

One parameter (pg_id) with 0% schema description coverage and a default of 'root'. The description does not explain the id format, the meaning of the default, or whether it accepts a composite path. Baseline 3 for a 1-param tool with an output schema, but the schema gap leaves the description short of adding real 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/resource combination: throughput and queue statistics for a process group. This is clear and distinguishable from siblings like nifi_flow_status (whole flow) and nifi_queue_listing (queues only). It doesn't explicitly name alternatives, but the scope is precise enough for an agent to select 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?

Implied usage only. The 'recursively' modifier and process-group scoping hint at when to use it, but there is no explicit when-to-use vs alternatives guidance, no exclusions, and no mention of siblings like nifi_flow_status or nifi_queue_listing.

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 read-only, idempotent, and non-destructive behavior, so the bar is lower. The description adds genuinely useful operational context beyond that: it is backed by POST /provenance, polled to completion (implying latency), and constrained to history reads.

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?

Extremely tight: three short sentences, purpose front-loaded first, with operational notes after. No filler or redundancy.

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 date format and polling behavior are covered. But with 7 undocumented parameters and no sibling disambiguation, the definition is only minimally complete for a query tool of this complexity.

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 0% across 7 parameters, so the description carries the full burden. It documents only the date format and leaves filename, event_type, component_id, flowfile_uuid, max_results, and the start/end pairing unexplained, so an agent cannot infer their semantics from the description alone.

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 (search), resource (provenance events), and goal (trace what happened to data), which is far more than a restatement. However, it does not differentiate from close siblings such as nifi_get_lineage or nifi_get_provenance_event, whose purposes overlap with historical data tracing.

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?

"This reads history only" implies a read-only historical context, but there is no explicit statement of when to use this versus nifi_get_lineage or nifi_get_provenance_event. Usage is implied rather than directed.

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 readOnly/idempotent/non-destructive, so the bar is lower, yet the description adds genuinely new behavioral context: it discloses the backend is a POST endpoint that is 'polled to completion,' signaling async latency. The 'reads state only' clause largely restates the annotations, but the polling detail earns credit beyond them.

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 short sentences, front-loaded with the core action, with no wasted words. The implementation note and read-only clause are useful though slightly redundant against the annotations.

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 needn't be explained, and annotations cover the safety profile. However, the 2-parameter schema has zero description coverage and the description compensates only for connection_id, leaving the limit parameter undocumented.

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 0%, so the description must carry parameter meaning, but it only implicitly implies connection_id via 'on a connection.' The limit parameter (default 25) is never explained, and neither parameter's format or effect is clarified.

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 ('List the flowfiles currently queued on a connection'), making the operation easy to identify. It is clear on its own but does not explicitly name or distinguish itself from siblings like nifi_get_flowfile.

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?

Usage is only implied via 'currently queued on a connection'; there is no explicit when-to-use guidance, no mention of alternatives such as nifi_get_flowfile, and no stated prerequisites. Adequate but with clear gaps.

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 that it is backed by GET /flow/search-results and matches UI behavior, which is useful parity context, but says nothing about result limits, pagination, or how pg_id scopes the search.

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?

Two short sentences, zero filler, with the core purpose front-loaded and the endpoint/UI-parity detail placed second. Every 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?

An output schema exists, so return values need no explanation, and the read-only annotations carry the safety story. The only real omission is the scope/behavior of the pg_id parameter, which an agent needs to target the right process group.

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 0%, so the description must compensate. It usefully explains that the required `query` matches four different component fields, but says nothing about `pg_id`, whose 'root' default and process-group scoping behavior are non-obvious for a multi-group flow.

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 (search) and resource (flow components) and enumerates the searchable fields (name, id, property value, comment). This distinguishes it from the retrieval siblings like nifi_list_processors or nifi_get_processor, though it does not explicitly name an alternative (e.g., nifi_find_component_types) to sharpen 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?

The field list and 'same search the NiFi UI uses' phrasing imply when this is the right tool (locating components when you don't have an exact id/handle), but there is no explicit when-to-use vs when-not guidance, no mention of filtering semantics, and no alternative named. Usage is inferred rather than directed.

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 safe-read profile is covered structurally. The description adds the backend GET /system-diagnostics hint, useful for anyone reasoning about caching or cost, but says nothing about the effect of the verbose flag or the response shape.

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?

Two short lines: the returned metrics lead, the routing condition follows. No filler and nothing buried.

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 annotations cover safety. The only real gap is the undocumented verbose parameter, which is minor for an optional flag defaulting to false.

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 0% for the single `verbose` parameter, and the description does not mention it at all, so nothing tells the agent what enabling verbose changes. With low coverage the description was expected to compensate, and it does not.

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 enumerates the exact resources returned — JVM heap, thread counts, repository disk usage, uptime — which is concrete and far more informative than a generic 'get system diagnostics'. It implicitly distinguishes itself from the flow-inspection siblings by scoping to system health, though no explicit verb frames the action.

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?

"Use when diagnosing performance or memory pressure rather than flow logic" gives a clear when-to-use condition and steers the agent away from the flow-logic sibling cluster. It stops short of naming a specific alternative tool for the flow-logic case, so it is strong context rather than a full routing rule.

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