nifi-mcp

Overview Schema Source Related Servers Discussions Admin

nifi_apply_flow_spec

Create a NiFi flow from a declarative spec, including process groups, services, processors, ports, and connections in one call.

Instructions

Create a complete flow from a declarative spec: process group, services, processors, ports, connections.

Property values starting with @ (processor or controller_service properties) are resolved to a controller service created earlier in the same spec. Services are enabled in spec order. JSON booleans and numbers become NiFi text (true -> "true", 10 -> "10"); null unsets a property. auto_terminated and relationships take a list or a single name. Connections refer to components by name. Prefer this over many create_* calls.

Every result, ok or error, has outcome (applied, not_applied or unknown: the failing request's) and lists created[] (kind, id, ref, outcome; services carry their state). ref is the item's place in the spec (process_group, objects[2], connections[0]). An ok result adds each item's name and name_map; an error names items by ref only, and never repeats a value from the spec. An error, or a build whose flow view could not be read, adds a hint saying how to roll back or inspect exactly what this call created. cause "spec" means the spec was refused before NiFi was asked (a missing name or type, an unknown connection end or @service, or an unknown key at the top level or in process_group): nothing was created. Top-level keys: process_group, objects, connections, parent_process_group_id, layout. process_group keys: name, comments, parameter_context_id, inherit_parameter_context, x, y, position. A request with no definite answer (a timeout, a 5xx, a lost connection) is in created[] with outcome "unknown": NiFi may have applied it, and the hint says what the server's read-back found. Check again before retrying. Only created[] items with an id are ever named for deletion.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`params`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 27, 2026

TDQS

A4.7/5.0

Behavior5/5

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

The annotations declare the safety profile (not read-only, not idempotent, open-world, non-destructive), and the description adds substantial context beyond that: @-prefixed property resolution, service enablement order, boolean/number coercion, null semantics, per-item outcome values, ref addressing, which items are eligible for deletion, and rollback hints. This is exactly the added behavioral detail the annotations do not cover.

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

Conciseness4/5

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

Front-loaded with purpose and the sibling-preference rule, and the dense result/error semantics are all non-redundant information. However the prose runs long and some sentences are run-ons that pack multiple distinct behaviors together, which slightly hurts scanability for an agent.

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

Completeness5/5

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

For a single-parameter, high-complexity, open-world mutation tool with 0% schema coverage, the description is complete: it covers spec structure, value conventions, error/cause taxonomy, unknown-outcome handling, and rollback guidance. An output schema exists, yet the error-path semantics it adds are genuinely necessary because they are not structured data.

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

Parameters5/5

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 and does so: it documents top-level keys, process_group keys, the @-service resolution convention, list-or-single acceptance for auto_terminated/relationships, and JSON-to-NiFi text conversion. That is far more than the bare nested schema provides.

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

Purpose5/5

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

Opens with a specific verb and resource ('Create a complete flow from a declarative spec') and enumerates the component kinds it builds (process group, services, processors, ports, connections). It also explicitly distinguishes itself from siblings via 'Prefer this over many create_* calls', which is exactly the kind of routing an agent needs.

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

Usage Guidelines4/5

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

Gives a clear preference rule: use this instead of many create_* calls. It also tells the agent to check again before retrying when an outcome is 'unknown'. It does not state explicit when-not conditions or name the specific create_* siblings to fall back to, so it falls 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.

Deploy Server