FlowSharp and MCP: when a small roadmap anticipates a big direction

A native MCP server less than a month after launch

On May 6, 2026, with FlowSharp version 0.6, we introduced a native Model Context Protocol (MCP) server. FlowSharp was less than a month old.

Our goal was simple to state, but decidedly ambitious: allow AI assistants to interact with business processes without bypassing rules, responsibilities and permissions. We didn't want to build just a chat capable of answering questions about flows. We wanted to enable an AI assistant to browse processes and activities, create and update items, complete tasks, generate new flows, analyze operational data, propose actions and operate within the permissions assigned to the user.

All of this using typed tools, role-bound API keys and an explicit selection of allowed operations.

Little more than a month later, on June 11, 2026, Pipefy publicly announced its own MCP integration, presenting it as the link between conversations with AI assistants and the execution of business workflows. For us it was an interesting moment. Not because FlowSharp and Pipefy are directly comparable products in size, history or international presence, nor because it makes much sense to turn innovation into a race to arrive a few weeks earlier. It was interesting because it represented an independent validation of the direction we had taken.

From conversation to governed action

Many AI tools are already very good at reading documents, processing information and suggesting what to do. The next step is allowing them to act. But an assistant that can modify data, start procedures or complete activities raises questions far more important than the mere quality of its answers: who is performing the action? With which permissions? Which processes can it touch? Which data can it read? Which operations require human confirmation? How can we reconstruct what happened? What happens when the AI gets it wrong?

The real value of MCP, in a product like FlowSharp, is therefore not letting a language model call a few APIs. It is bringing artificial intelligence inside a governed operating system.

The assistant does not act in a vacuum. It acts within processes that have states, tasks, roles, deadlines, rules, documentation, metrics and a verifiable history. This is the difference between an AI that suggests and an AI that can genuinely contribute to how the company runs.

Why it matters especially for SMBs

In small and medium businesses, work rarely lives inside a single piece of software. Information is scattered across ERPs, CRMs, Excel sheets, emails, documents, automations, chats and personal knowledge. Even when a procedure exists, what actually happens can be very different from what was formalized.

FlowSharp was born to reduce this distance. Processes become executable flows. Procedures are linked to activities. People retain responsibility and control. Automations are integrated into the operational path. Results can be measured.

MCP adds a further layer: it allows the AI assistants chosen by the user to access this context and use it operationally. A team member could ask their assistant: "Which cases are blocked and need my intervention?". Or: "Analyze this file, create an item for each valid row and flag missing data before proceeding". Or again: "Propose a new flow based on this procedure, but don't publish it until I've approved it".

Conversation becomes a new entry point to company work. The process, however, remains governed by FlowSharp.

MCP is not the strategy: it's the infrastructure

Being very fast in introducing MCP is an important signal, but the protocol alone is not a unique value proposition. MCP is rapidly becoming a shared standard. More and more platforms will adopt it and, over time, simply having an MCP server will no longer be a differentiator. The real game starts now.

FlowSharp's advantage lies in combining AI assistant access with elements that already belong to its architecture: formalized and executable processes, permissions and separation between organizations, operating procedures linked to tasks, human oversight, action audit trails, automations built with n8n, measurement of time, results and savings, process analysis and anomaly detection.

In other words, we don't want to merely connect AI to company data. We want to connect it to the way the company decides, operates, controls and improves.

The next evolution

The direction we are exploring goes beyond mere technical integration. We imagine FlowSharp packages usable by assistants like Codex, Claude and other agentic work environments: not just an MCP configuration, but a coherent set of company knowledge, policies, process descriptions and operational skills.

The assistant could thus understand how the organization works, which flows are available, which procedures must be respected, which actions it can perform, when it must stop and ask for confirmation, and which results are expected.

We are also studying a governance layer for autonomous agents: dedicated identities, granular permissions, budgets, approvals, action control and the ability to interrupt or correct an execution.

Because the future will not consist only of people using software. It will be made of people, systems and AI agents collaborating within the same processes.

A small confirmation, a big responsibility

Seeing an international platform like Pipefy present MCP as a new strategic direction, a few weeks after our implementation, was gratifying. It doesn't prove that every choice we make will be right. But it confirms that the problem we are tackling is real and that the direction deserves to be pursued.

FlowSharp adopted MCP when the product was less than a month old, before the integration between AI assistants and governed processes became a declared direction of the industry's big vendors. Now our goal is not simply to keep adding AI features. It is to build the place where procedures, people, automations and agents can work together without losing control, accountability and the ability to measure results.

Because AI becomes truly useful to a business not when it can merely answer. It becomes useful when it can contribute to real work, respecting the way the business needs to function.