MCP Server

Q: Can the MCP server deploy processes or start instances?

No. Every tool reads, and model_pull writes only the local file it is asked for. Deploying models, starting instances and completing tasks go through the SDKs, the REST API or the console.

The QuantumBPM MCP server gives a coding agent the engine itself. Claude Code, Cursor, VS Code or any other Model Context Protocol client can evaluate FEEL, validate and test DMN decisions, dry run BPMN processes and search the documentation. The server embeds the same engine packages the platform runs, so a result from it is the result a deployment on the same release returns.

It runs on your machine as a single binary. The model tools need no account, and the server makes no network calls unless you connect it to a deployment.

Install

# macOS and Linux
curl -fsSL https://quantumbpm.com/install-mcp.sh | sh

# Windows
irm https://quantumbpm.com/install-mcp.ps1 | iex

The script detects your platform, downloads the latest release, checks it against its published SHA-256 digest and prints the command that registers it. Nothing needs to be installed first. The binary lands in ~/.quantumbpm/bin/quantumbpm-mcp on macOS and Linux, and in %LOCALAPPDATA%\QuantumBPM\bin\quantumbpm-mcp.exe on Windows. Enterprise customers also have access to versioned builds, see Versions and limits.

Register it with your agent

The server speaks MCP over stdio, so every client registers it the same way: the command is the binary, with no arguments.

Claude Code

claude mcp add quantumbpm -- ~/.quantumbpm/bin/quantumbpm-mcp

Cursor, Claude Desktop and other clients with an mcpServers file, for example ~/.cursor/mcp.json or .cursor/mcp.json in a project:

{
  "mcpServers": {
    "quantumbpm": {
      "command": "/home/you/.quantumbpm/bin/quantumbpm-mcp"
    }
  }
}

VS Code, in .vscode/mcp.json:

{
  "servers": {
    "quantumbpm": {
      "type": "stdio",
      "command": "/home/you/.quantumbpm/bin/quantumbpm-mcp"
    }
  }
}

Config files do not expand ~, so give them the absolute path the install script printed. To check the connection, ask the agent to validate a DMN model: the output ends with the engine release the server carries.

What the agent can do

Every model tool takes a path to a file or inline XML, so one session can work across as many models as it needs.

FEEL

Tool	What it does
`feel_eval`	Evaluate an expression against a set of variables.
`feel_builtins`	Look up built-in functions by name or by what they do.

Errors are written for the agent's next attempt rather than for a log file. A misspelled name comes back with the near miss and the names that were in scope:

line 1, column 4: unknown identifier custmer: did you mean customer?
in scope: amount, customer

DMN

Tool	What it does
`dmn_validate`	Parse a model, list what it contains, and report errors and structural findings by element id.
`dmn_evaluate`	Evaluate one decision against inputs, optionally with the dependency results and the matched rules.
`dmn_test`	Run a batch of cases and return a pass or fail table. Cases live inline or in a JSON suite file, and `save_as` writes an inline batch to a file so it can be rerun.
`dmn_get_element`	Read one element out of a large model by XPath, or by type and name.
`dmn_examples`	Runnable models for each kind of decision logic, searchable by element.

dmn_validate reports where a model reached for a FEEL literal expression when a boxed element does the job better, logic repeated across decisions, missing hit policies and untyped variables. Detection runs on the parsed FEEL, not the source text:

warnings
  structure
    shipping_cost: decisionTable declares no hitPolicy, so it silently defaults to UNIQUE
  typing
    shipping_cost: decision variable has no typeRef, so nothing downstream can be checked against it

BPMN

Tool	What it does
`bpmn_validate`	Parse a process and report each node and every validation issue with its element id. These are the checks the engine runs before it deploys a model.
`bpmn_dry_run`	Run a process on a virtual clock and return the path it took, one line per node with a timestamp.
`bpmn_examples`	Runnable models for each element, each verified by a dry run, plus the table of which attributes are FEEL.

A dry run answers what happens when nobody acts. Timers fire in virtual time, so a 24 hour deadline costs no waiting, and no Temporal server is involved. Here a claim review has an hourly reminder that repeats three times and an interrupting 24 hour deadline:

{
  "model": "claims/review.bpmn",
  "horizon": "7d",
  "expect": {"reaches": ["escalated_end"], "avoids": ["reviewed_end"], "instances": {"send_reminder": 3}}
}

PASS: every expectation held

Review With SLA completed at T+24h

  T+0       start                      StartEvent             completed
  T+0       review                     UserTask               started
  T+1h      remind                     BoundaryEvent          completed
  T+1h      send_reminder              ServiceTask            started
  T+1h      send_reminder              ServiceTask            completed
  T+1h      reminded_end               EndEvent               completed
  T+2h      remind                     BoundaryEvent          completed
  ...
  T+24h     deadline                   BoundaryEvent          completed
  T+24h     review                     UserTask               canceled
  T+24h     escalated_end              EndEvent               completed

events say what arrives and when, such as a user completing a task after an hour or a message being published. mocks say what a service task or call activity returns, including BPMN errors and worker failures that retry the way a deployment retries them. A business rule task evaluates for real against the DMN given in decisions, so the gateway below it takes the path the decision actually sends it down. A run that stops early lists what is still waiting, with the event that would advance it.

Documentation

Tool	What it does
`docs_tree`	Walk the documentation: every section and page, or one page's headings.
`docs_read`	Read a page, or one section of it.
`docs_search`	Find the sections for a term, each with a snippet and the path to read.

The docs tools answer from the documentation and release notes of the server's own release, with no network access.

Connected to a deployment

Set QUANTUMBPM_URL and the server also reads a running deployment, such as the devserver on your machine or an Enterprise installation.

# the devserver
claude mcp add quantumbpm -e QUANTUMBPM_URL=http://localhost:9060/api -- ~/.quantumbpm/bin/quantumbpm-mcp

# Enterprise: the backend host, not the web UI, plus a token from its identity provider
claude mcp add quantumbpm -e QUANTUMBPM_URL=https://api.example.com -e QUANTUMBPM_TOKEN=eyJ... -- ~/.quantumbpm/bin/quantumbpm-mcp

Variable	Meaning
`QUANTUMBPM_URL`	API root. The devserver serves it under `/api`, an Enterprise backend at its own root.
`QUANTUMBPM_TOKEN`	Bearer token, sent only when set. The devserver needs none.
`QUANTUMBPM_PROJECT`	Project id or name. Only needed when the token can see more than one project.

Tool	What it does
`deployment_info`	The deployment's release, the project, and every deployed process and DMN model. Says when the embedded engine is a different release.
`model_pull`	Write a deployed process or DMN model to a local file, so the local tools run on what is deployed.
`instance_get`	One instance by `workflowId` or `businessId`: status, where it waits, open incidents and variables.
`instance_history`	The path an instance took, in the same layout as a dry run, with the start variables a dry run of it needs.
`incident_list`	Open or resolved incidents across the project, optionally for one process.

Every connected tool only reads. Deploying, starting instances and completing work stay with the SDKs and the console. model_pull writes nothing but the local file it was asked for.

This makes a debugging loop the agent can run on its own: pull the deployed model, dry run it with the start variables instance_history reports, and compare the two paths. The first line where they differ is where the real run left what the model predicts.

The token is read once when the server starts. An expired token comes back as a 401 that says so, and a fresh one needs a reconnect.

Versions and limits

The server carries the engine of exactly one release, and dmn_validate prints which. The install script always downloads the latest release. Enterprise customers have access to versioned builds, so the server can carry the same release as their deployment, which GET /version on the deployment reports. deployment_info flags a mismatch.

Evaluation is capped at the backend defaults: depth 256, one million iterations and 500 ms per evaluation. An expression that trips a limit in the server trips it in production too.

FAQ

Does the MCP server need a QuantumBPM account?

No. FEEL evaluation, DMN validation, evaluation and tests, BPMN validation and dry runs, and the documentation tools all run locally with no account and no network access. Only the connected tools need a deployment, and the devserver is a free local one that needs no sign-up.

Does the MCP server send my models anywhere?

No. The model tools read files from your machine and run the engine in the same process. The server makes network calls only when QUANTUMBPM_URL is set, and then only read requests to that deployment.

Which coding agents does it work with?

Any client that runs MCP servers over stdio, including Claude Code, Cursor, VS Code and Claude Desktop. Registration is the path to the binary with no arguments, plus the QUANTUMBPM_* environment variables for connected mode.

Can the MCP server deploy processes or start instances?

No. Every tool reads, and model_pull writes only the local file it is asked for. Deploying models, starting instances and completing tasks go through the SDKs, the REST API or the console.

Can I use it on DMN files from another modeler?

Yes. DMN is standard XML, and a DMN 1.3 file saved by Camunda Modeler validates and evaluates. Results are what the QuantumBPM engine returns. BPMN process extensions, such as task types and input and output mappings, use the quantum: namespace.

FEEL tooling - the language server behind autocomplete and diagnostics in the modeler and editors.
FEEL playground - evaluate FEEL in the browser.
Local development - the devserver the connected tools can read.
SDK overview - deploy models, start instances and run workers from code.

Install​

Register it with your agent​

What the agent can do​

FEEL​

DMN​

BPMN​

Documentation​

Connected to a deployment​

Versions and limits​

FAQ​