Part 4: Turning Mule APIs into MCP tools with the MCP Connector

Part 4 of 10 · Building an Agentic Change-Approval MVP on MuleSoft

Part 3 drew the broker's graph. Four of its nine nodes are MCP tool calls, and that's where the integration team does its work. This part covers how a Mule flow becomes an MCP tool with the MCP Connector, and why the tool's name and description matter more than the code behind it.

The tools in the MVP

The MVP graph uses four tools. We also built a fifth, import_transport_to_qa, which stage 4 will need first. It's the example used below, because it's the one that must never run without an approval.

None of these maps one-to-one to an existing endpoint. Each one is a business action, and its flow calls the APIs it needs.

From Mule flow to MCP tool

The MCP Connector lets a Mule app act as an MCP server (and as a client, which we don't need here). Three pieces do the work.

1. The server configuration

One MCP server configuration per app. It has a server name and version, and a connection type. Use Streamable HTTP: SSE is deprecated in the connector and only supports single-replica deployments. Streamable HTTP serves one endpoint (/mcp by default), and with a distributed object store for sessions it runs across several replicas.

2. One Tool Listener per tool

Each tool is a flow that starts with a Tool Listener source. The listener carries the contract the agent sees:

• Name: import_transport_to_qa
• Description: what it does, when to use it, and what it needs first
• Input schema: the arguments, as JSON Schema
• Output schema (optional): a structured result the agent can rely on

The input schema for import_transport_to_qa:

{
  "type": "object",
  "properties": {
    "transport_id": {
      "type": "string",
      "pattern": "^[A-Z0-9]{3}K9[0-9]{5}$",
      "description": "SAP transport request, e.g. DEVK900123"
    },
    "approval_id": {
      "type": "string",
      "description": "Approval ID returned by request_approval"
    }
  },
  "required": ["transport_id", "approval_id"],
  "additionalProperties": false
}

When the agent calls the tool, the flow receives the arguments as its payload.

3. The flow body

The flow is ordinary Mule: validate, call the Process API, shape the response. It doesn't talk to SAP itself. The Process API checks the approval again and calls the SAP System API. If anything fails, the flow returns an error result with a named code, such as APPROVAL_MISSING or TRANSPORT_LOCKED, instead of a stack trace.

That's the whole pattern. If your team already builds API-led integrations, most of the work is already done: the System and Process APIs exist, and the MCP layer is a thin set of flows on top.

The contract is the hard part

The code in a tool flow is short. The name and description take longer, because the agent picks tools by reading them. A recent LinkedIn post in this series showed the before and after:

Four rules we follow:

1. Name the business action, not the HTTP verb. import_transport_to_qa, not postTransportImport.
2. Say when to use it, and when not to. Preconditions belong in the description the model reads.
3. Type and constrain every input. A pattern on transport_id and a required approval_id stop bad calls before they reach SAP.
4. Name the errors. An agent that gets APPROVAL_MISSING can tell the requester what's wrong. An agent that gets "500 Internal Server Error" retries.

One more: keep the tool list short. Every tool's description goes into the agent's context. Five well-described tools work better than twenty overlapping ones.

Where enforcement actually lives

The description guides the agent. It doesn't protect anything. Enforcement sits in three places:

• The input schema rejects malformed calls.
• The Process API checks the approval ID against the approval record before any import, whoever calls it.
• Omni Gateway decides which agent can see which tool at all. The Intake agent never sees import_transport_to_qa. That's Part 5.

If you remove the description entirely, the system is still safe. It just works worse.

Who owns what

• Integration team: the MCP server app, tool flows, schemas, descriptions and error codes, plus the Process and System APIs underneath.
• Agent team: reviews tool names and descriptions with the integration team, because they see how agents actually use them.
• Platform team: the gateway in front of /mcp and the policies on it.

Next

Part 5 puts Omni Gateway in front of the MCP server: tool allow-lists per agent, attribute-based access control, PII detection and token limits on LLM traffic.

What's the first tool you'd expose from your own APIs?

This series describes a reference model built on a fictional company. Product capabilities are based on MuleSoft documentation as of October 2026 (MCP Connector 1.7); check current docs before you build.