Bonus: Your MuleSoft APIs are already most of an MCP server

Bonus · Building an Agentic Change-Approval MVP on MuleSoft

The main series finished with Part 10. This bonus post answers the question I got most often along the way: "We've done API-led on MuleSoft for years. How much work is it to make that usable by agents?"

Less than most teams expect. If you have a healthy API-led estate, you already have most of an MCP server. What's missing is a thin layer and some writing.

What you already have

• RAML or OAS specs. Every Process API already has typed inputs and outputs. They translate into the input and output schemas of an MCP tool, so the agent gets the same contract your other consumers use.
• Process APIs. This is where your business rules live, such as "no SAP import without an approval". In our MVP, that one check in a Process API is what kept the agents safe, as described in the human-in-the-loop post.
• Exchange. A catalogue of what exists, who owns it and which version is current. That's exactly what you need when deciding which APIs become tools.
• Gateway policies. Client IDs, rate limits and access control are already in place for every API. Agent traffic sits on top of the same governance.
• MUnit. Tests for the behaviour agents will rely on, including the error cases.

What you add

• An MCP server app. A Mule app using the MCP Connector, with one Tool Listener per tool, each calling a Process API. Part 4 walks through it.
• Descriptions written for an agent. Not the API's summary line. Say when to use the tool, what it needs first and what it returns.
• Named errors. APPROVAL_MISSING tells an agent what to do next. A generic 400 makes it guess, or retry.
• Agent policies. Tool allow-lists per agent, PII detection and token limits in Omni Gateway, as in Part 5.

Expose Process APIs, never System APIs

This is the one rule worth repeating. A System API is a thin wrapper over a system of record. If an agent can call it directly, every business rule you built in the Process layer is bypassed. In our MVP, a git pre-commit hook rejected any tool that called a System API, so the rule couldn't drift.

Picking your first tool

Good first tools have three things in common:

1. Read-only. A lookup, such as "get transport status", can't do damage while you learn how agents use it.
2. Well documented. A clean spec and clear error codes make a good tool description almost write itself.
3. Used a lot by people today. If analysts look it up twenty times a day, an agent that can do it saves real time.

Write actions come later, behind a Process API that checks approvals.

Three mistakes to avoid

• Mapping every endpoint to a tool. Agents choose worse with more tools. Expose the handful a task needs, and give each agent only its own.
• Copying the API description. "Retrieves transport details" is written for developers. An agent needs "Use this before importing a transport, to confirm it's released and not locked".
• Skipping the error design. Most agent loops we saw came from errors the agent couldn't act on.

A checklist for one API

1. Pick a Process API, not a System API.
2. Translate its request and response types into the tool's input and output schemas.
3. Write the tool description: when to use it, what it needs first, what it returns.
4. Map each failure to a named error.
5. Add MUnit tests for the happy path and each named error.
6. Add the tool to the right agent's allow-list in Omni Gateway.

For a well-specified API, that can be an afternoon, not a project.

Which of your Process APIs would make the best first tool?

---

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