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
