The MCP server nobody built: exposing your processes to agents

Look at the MCP servers that exist today. They connect an agent to a database, a ticketing system, a file store, a search index, a calendar. Every one of them exposes a tool or a pile of data. Useful, and none of them answers the question the agent actually has to answer before it acts: how is this work supposed to go? The protocol did its job connecting agents to capabilities. The category quietly skipped the one capability that governs all the others.

What MCP connected, and what it left out

MCP is a clean idea. Standardize how an agent discovers and calls external capabilities, so you stop writing a bespoke integration for every model and every tool. In practice the capabilities people exposed fall into two buckets. Tools: do a thing, send the message, create the record, run the query. Resources: read a thing, fetch the document, list the rows, pull the context.

Both buckets assume the agent already knows what it is trying to do. They are verbs and nouns with no grammar. The grammar, the part that says which step comes next, under which condition, with whose approval, is the process. It is not a tool and it is not a document. It is the routed logic that decides which tools to call and which data matters, and it is exactly the primitive no one wrapped in an MCP server, because in most companies the process does not exist in a form you could wrap. It lives in someone's head, a stale SOP, or a dead Visio file.

What a process over MCP actually looks like

Make it concrete. Picture a cargo handling process exposed as an MCP resource, and an agent working a single shipment. Four things become possible that a wiki page never gave it.

It can read the process as structure, not prose. The agent asks for the process and gets back an object: the ordered steps, the conditions that gate each one, the owners, the constraints. Not a paragraph to summarize and hope it parsed correctly. Structure it can traverse.

It can resolve the scenario for the case. The agent hands over the conditions of this shipment, dangerous goods, a temperature excursion in transit, a specific lane, and gets back one resolved route: the exact steps that apply here, not the master document with ten branches it has to disambiguate on its own. This is the difference between an agent that follows the process and one that guesses which paragraph applies.

It can see whose sign-off a step needs. For the step in front of it, the agent reads the owner and the required approval before it proceeds. It knows that releasing this shipment needs the quality lead's sign-off, so it stops and routes for it rather than acting past a control that has a person's name on it.

It can report a step done. When the agent completes an action, it writes that back into the process record. What the agent did lands on the same governed, audited trail as what a person did, with a timestamp and a state change, not a message in a channel nobody keeps.

Why nobody built it

The reason is not that the protocol cannot carry a process. It is that you can only expose what you actually hold. To put a process behind an MCP tool, you need a version of it that is designed rather than drawn, current rather than stale, owned rather than anonymous, and resolvable to a route rather than a static picture. Most operations have none of those. Wrapping a Confluence space in an MCP server does not fix that; it just lets the agent read the same untrustworthy prose faster. The server nobody built is the one that requires a governed process record underneath it, and that record is the thing most stacks are missing. This is the same gap that the process record AI agents actually need describes from the agent's side.

How FLOW exposes the process

FLOW was built so that every capability is an API, a CLI command, and an MCP tool at the same time. The process is not a document you export and hope stays fresh; it is a governed, scenario-aware record that an agent queries directly. Ask it for the route for a case and it resolves the scenario. Ask it who signs off a step and it answers from the governed model. Tell it a step is done and it writes into the audited trail. Because it is the process system of record, the answer the agent reads today is the true one, versioned and signed off, not last quarter's diagram. See how the surfaces fit together in the product.

Where this matters first

It matters the instant an agent does more than draft text and starts taking actions with consequences: releasing a shipment, clearing an exception, closing a step in a regulated lane. There, an MCP server that only offers tools and data is a liability, because the agent will act plausibly and past the controls it never saw. An MCP surface over a governed process is what lets the agent act correctly and stop where a human has to sign. If your agent pilots stall the moment they touch real operations, the missing piece is usually not another tool integration. It is the process, exposed as a resource the agent can read.

Common questions