Model Context Protocol gets pitched as one thing: a standard way to connect an AI model to tools. That framing is fine until you try to place a process orchestration platform, like Camunda, inside it, because Camunda doesn't sit on one side of that connection. It sits on all three.
The useful question isn't "does Camunda support MCP?" It's who is asking whom. Depending on the answer, you get a completely different architecture, a different set of use cases, and a different mental model for what "AI agent" even means inside an enterprise process.
To keep this concrete, everything below runs on one scenario I built as a working demonstration rather than three unrelated examples.
The scenario: one flight disruption, three MCP connections
TravelCo is a corporate travel platform. A traveler is mid-trip and their connecting flight just got cancelled. A Camunda process, Handle Flight Disruption, picks up that cancellation and has to get the traveler rebooked—which means looking up alternate flights, maybe booking an overnight hotel, and telling the traveler what's happening.
That single scenario touches MCP in all three directions, and the whole architecture fits in one picture:
Pattern 1: Camunda calls an MCP server
This pattern is Camunda as an MCP client. It lives inside the AI Agent connector's ad-hoc sub-process model. You give an LLM-backed agent a set of tools to choose from, and one (or several) of those tools can be an MCP Client connector pointing at any external MCP server—a filesystem, a search index, a partner's internal tool server, or something else.
This video shows an example of using MCP and Camunda using this first pattern.
In the demo video: Handle Flight Disruption wraps an AI Agent connector in an ad-hoc sub-process with two MCP tools available to it: find_alternate_flights on a flight-status MCP server, and find_overnight_hotel on a hotel MCP server. The agent gets the disrupted flight and decides what it needs. Same-day rebooking available? It only calls the flight tool. Nothing until tomorrow morning? It reaches for the hotel tool too. Nobody hardcoded that branch—but you can watch the agent make it, task by task, in Operate.
The architecturally interesting bit is exactly that: Camunda doesn't hide "which tool did the agent pick" inside a black box. It's modeled as a BPMN ad-hoc sub-process, a set of tools the agent selects from at runtime, so tool selection is a visible, auditable part of the process rather than a hidden LLM decision. There's a nuance worth knowing if you go looking in Operate: connecting an MCP client triggers a tools/list discovery call, and that shows up in the audit trail too. It's a deliberate tradeoff, transparency over a perfectly clean log, not a bug.
For cases where an agent's actions need a checkpoint, there's also a human-in-the-loop pattern: an intermediate event can gate an MCP tool call behind a confirmation step before it executes. In the demo, that gate sits in front of anything that actually commits the traveler to a new booking—the agent can look up whatever it likes, but spending money needs a human.
For more information, please see our documentation: MCP Client · MCP Client connector · MCP Remote Client connector
Pattern 2: someone calls Camunda via MCP
Now let’s flip the direction. This pattern is Camunda as an MCP server, specifically the Orchestration Cluster itself exposing an MCP endpoint. It's not a bolt-on integration; it's built into the cluster, on by default in Camunda 8 Run and Docker Compose, and available on SaaS clusters running version 8.9 or later. Same authentication as the REST API.
Connect any MCP-aware client—Claude Desktop, Cursor, a custom chat tool—and it can inspect process instances, search and resolve incidents, look up user tasks and their variables, and even start new instances, all through natural language instead of a REST client or an Operate login.
This video shows an example of using MCP and Camunda using the second pattern.
In the demo: with a few dozen disruption cases running (one of them deliberately broken, pointing at a dead MCP server port so it throws a real incident), I connect a chat client to the cluster and ask three questions in a row:
- "How many flight disruption cases are currently being handled?"
- "Are any of them stuck? What's the incident?"
- "Start a new disruption case for traveler T-4521, flight BA117, reason: cancelled."
Nobody built a dashboard for that. The third question isn't even a read; the chat client starts a real process instance. This is the pattern with the clearest "someone asked for this" origin story: it answers the ordinary need to let support staff, QA, and product ask a running system direct questions without learning its API surface first.
For more information, please see our documentation: Enable and connect
Pattern 3: a process becomes an MCP tool
The third pattern is the newest, and arguably the biggest shift. Instead of exposing Camunda's operational data, this pattern exposes a business capability, a specific process, as a callable MCP tool.
Apply the new MCP start event element template to a BPMN message start event, fill in a name, a description of what it does, its required inputs, and optional guidance on when (and when not) to use it. Deploy, and the Processes MCP Server picks it up automatically—no external documentation, no custom integration layer between your process engine and whatever agent framework wants to call it.
This video shows an example of using MCP and Camunda using the third pattern.
In the demo: the Rebook Trip process carries an MCP start event configured as the tool rebook_trip—"Rebooks a traveler onto an alternate flight after a disruption," with travelerId and originalFlightNumber as required inputs. I deploy it, then run a small external script that has never heard of Camunda's API. It lists available tools and rebook_trip is simply there, description and all, because that metadata shipped with the BPMN file. It calls the tool, gets a process instance key back immediately, and a moment later the instance is running in Operate.
Note the shape of that: fire-and-track, not request/response. The tool call starts work and hands you a receipt, which matters if you're building an agent that expects a synchronous answer.
The result is that your inventory of deployed processes becomes a library of capabilities any agent framework—Camunda's own or someone else's—can discover and invoke. "Rebook the trip." "Run KYC check." "Start onboarding." Whatever your business already models as a process becomes something an LLM can reach for as casually as a search tool.
What everyone else gives you
Most MCP write-ups stop at pattern one: point your agent at some tools and let it reason. That covers the "AI calls out" half of the story and ignores the other two directions entirely, so teams end up bolting together a chat interface for operational questions and a separate custom API layer to let outside agents trigger business processes—solving pattern two and three by hand, per project, every time.
What Camunda gives you instead
Look back at the previous architecture diagram: three doors, one cluster. The rebooking agent's outbound tool calls, ops asking about stuck cases, and an external framework invoking rebook_trip all land in the same process model, the same audit trail, the same governance. Nothing about the demo required a custom integration layer in any of the three directions.
The three MCP patterns
- Use Case 1: Internal AI agents calling external MCP services
- Use Case 2: External operators querying Camunda via MCP for observability
- Use Case 3: External systems triggering Camunda processes via MCP start events
That's the common thread. Camunda treats "which tool got called" and "what did the agent decide" as structured, modeled, auditable events rather than something that happens inside an opaque prompt—whichever direction the connection runs.
A rough decision guide
MCP is the wire format here. The audit trail is the point.
