MCP Without the Buzzwords: What Decision-Makers Need to Know

When a technology vendor says “we support AI agents,” ask how those agents connect to your systems. An open protocol can make integrations easier to reuse. A procurement decision still needs evidence: which clients work, which operations are exposed, and how permissions are enforced.

What MCP is, without the jargon

MCP, the Model Context Protocol, is an open protocol for connecting AI applications to external tools and data. An application acts as a host, manages MCP clients, and connects them to servers that expose capabilities such as searching a database or calling a business service. The model does not connect to those systems on its own.

The MCP architecture specification describes how clients and servers negotiate the features they support. A shared protocol reduces the need for a unique connection format for every integration, but “supports MCP” does not mean that every client supports every server’s features, transport, or authentication method.

Think of a standard connector: it makes reuse easier, but you still need to check what works at each end. MCP also does not replace the business logic and system access behind a tool.

The three directions Camunda describes for MCP

Camunda’s three-pattern example uses a flight disruption scenario to explain who calls whom. The patterns have different setup and version requirements:

1. Camunda as an MCP client. An AI agent in a Camunda process can use MCP connectors to call external tools. For example, it could look up alternative flights and route a proposed booking for approval. The MCP Client connector requires runtime configuration; it is not directly included in the managed SaaS connector runtime, though a custom runtime can connect to SaaS. Check the remote connector option and deployment requirements for your environment.

2. Camunda as an MCP server. An external AI application can use exposed tools to inspect or act on a cluster, subject to its access rights. Natural-language interaction comes from that application; the server provides the tool interface. The Orchestration Cluster MCP Server setup guide documents SaaS support from 8.9.0, with MCP explicitly enabled. Client authentication compatibility still needs checking, and a proxy may be needed.

3. BPMN processes exposed as MCP tools. This is a separate capability. A process needs a configured MCP start-event template and tool metadata; deploying any ordinary BPMN model does not automatically expose it. As of September 30, 2026, the Processes MCP Server guide is marked 8.10 (unreleased) and specifies SaaS support from 8.10.0. Treat it as a forthcoming capability when planning production work. Camunda’s demonstration starts a process and returns its instance key, rather than waiting for the business outcome.

Where MCP can reduce procurement and architecture risk

• More reusable connections. Supporting a common protocol can reduce adapter work when changing an AI application. It does not automatically migrate prompts, process models, credentials, data, or vendor-specific features.
• Clearer integration testing. Test the actual client-server pair, including discovery, permissions, error handling, and long-running operations. A protocol logo is not an acceptance test.
• A firmer basis for comparing vendors. Ask each supplier to demonstrate the same business operation with the clients you expect to use. A documented API may also be appropriate; lack of MCP alone does not prove lock-in.
• An explicit audit design. Decide where tool requests, approvals, results, and process events are recorded and how they are correlated. MCP alone does not provide a complete audit trail.

What this means for your organization

In your next procurement conversation, ask: “Which MCP role do you support, in which released version, and can you demonstrate it with our authentication setup?” Then test a read operation, a permitted write, and an operation the user must not be allowed to perform.

At NG Workshop, we see MCP as a useful extension of our process-first approach. A shared interface helps connect the agent, the tool, and the process; explicit controls make that connection usable in the organization. We covered the orchestration layer around AI agents in AI Agents Need a Conductor.

Sources

• MCP: Architecture and capability negotiation
• Camunda: Three Ways Camunda Speaks MCP
• Camunda: Orchestration Cluster MCP Server setup
• Camunda: Processes MCP Server setup, 8.10 unreleased documentation

Summary

• MCP standardizes part of the connection between AI applications and tools; it does not guarantee universal compatibility.
• Camunda describes client, cluster-server, and process-as-tool patterns with different release and setup requirements.
• For procurement, verify the released capability, permissions, integration effort, and cost of switching components.

Want to evaluate your AI architecture against open standards? Let’s talk