I've opened a PR for this: https://github.com/apache/nifi/pull/11863";
Il giorno mer 28 ott 2026 alle ore 14:35 VINCENZO LOMBARDO < [email protected]> ha scritto: > Hi all, > > I'd like to propose contributing a new extension that lets NiFi act as a > client of Model Context Protocol (MCP) servers, the open protocol many > tools > and data sources now use to expose capabilities to LLM-based applications. > > What it contains: > > - McpClientService (API) + StandardMcpClientService: a Controller Service > that manages a session with a remote MCP server over Streamable HTTP or > SSE, with optional SSLContextProvider (TLS/mTLS) and sensitive custom > headers for authentication. > - InvokeMcpServer: a processor that performs Call Tool, Read Resource, > Get Prompt and List Tools/Resources/Prompts. Arguments come from a > property (with Expression Language) or from the FlowFile content. Output > can be the full result, text only, or the tool's structuredContent JSON, > ready for record processors. Tool-level errors (isError) go to a separate > relationship from transport failures. > > Why: a growing number of SaaS and internal systems expose data only (or > most conveniently) through MCP servers. Today these are mostly consumed by > LLM agents, which means paying tokens, and accepting non-deterministic > behavior, even for repetitive work that is really just plain ETL: polling a > tool on a schedule, fetching the same resource every day, or moving its > output into a database or index. With an MCP client in NiFi, those calls > become deterministic flow steps, with no tokens spent and with NiFi's usual > retries, provenance, routing and record tooling. An LLM is then needed only > where real reasoning is required, and it can be fed small, pre-processed > data instead of raw tool output. > > More broadly, MCP is quickly becoming the standard way for systems to > expose their capabilities to AI applications. Supporting it gives NiFi a > natural role in those architectures: the deterministic layer that does the > repetitive data movement itself and hands an LLM only what actually needs > reasoning, reducing token cost and making the overall pipeline more > predictable and auditable. > > Dependencies: the official MCP Java SDK (io.modelcontextprotocol.sdk, MIT > licensed), which brings in Reactor Core, Jackson 3 and networknt > json-schema-validator (all Apache 2.0). Jackson 3 is already managed by > NiFi's BOM, so the bundle just uses the managed version. Everything else is > bundled in its own NAR. I'd keep it out of the default assembly behind an > optional include-mcp profile, like asn1 and snowflake. > > Scope of a first PR: HTTP-based transports only. A STDIO transport > (launching a local MCP server process) exists in my prototype, but I'd > leave it to a follow-up because of the security implications. It would be > a @Restricted(EXECUTE_CODE) component. > > The code is already structured as nifi-extension-bundles/nifi-mcp-bundle > (service-api, service-api-nar, processors, nar) on top of main. It passes > contrib-check, and its unit tests run against an in-process MCP server, so > no network is needed. > > Possible follow-ups: I also have working prototypes of the opposite > direction (NiFi as an MCP server): a pair of processors, McpToolRequest and > McpToolResponse, that expose flow-defined tools in the style of > HandleHttpRequest/HandleHttpResponse, and a ReportingTask exposing NiFi's > own management API as MCP tools. I'd propose those separately, after this > one, since they raise different security questions. > > Does this sound like a good fit for the main repository, or would you > rather see it elsewhere? Any concerns about the dependency set? If there is > interest, I'll open a JIRA and a PR. > > Thanks, > Vincenzo Lombardo >
