Part 16 · One Agent, Five Platforms

Two builds in, it's worth slowing down and looking at one tool in detail. Not the whole agent, just get_goods_receipt, built on MuleSoft (Part 11) and on Boomi (Parts 14 and 15).

It's a good test case. It's a simple read, so the differences aren't hidden behind business logic. And it has one named error, GR_MISSING, with a strict rule attached.

Like the builds, this is documentation-only. I re-checked every platform fact against the vendors' docs on 4 November 2026. Nothing below has been run yet.

get_goods_receipt on MuleSoft and Boomi, side by side

The tool, once

From the contract in Part 7 and the error rules in Part 8:

  • Input: a PO number and line.
  • Output: the goods receipt for that line, with quantities and dates.
  • Error: GR_MISSING when nothing has been received yet. It's not retryable: the invoice goes on hold, the scheduled re-check picks it up, and the agent never calls the tool again in the same run.

The error body is the same JSON on every platform:

{"code": "GR_MISSING", "retryable": false, "next_action": "hold_and_recheck", "details": {"po_id": "4500018822", "line": 20}}

Now the same tool, five ways of looking at it.

1. Where the tool is defined

MuleSoft. You declare it. A Tool Listener in a Mule flow has a name, a description ("detailed enough for an LLM to determine when this tool should be called", in the MCP Connector reference), a required Parameters Schema and an optional Output Schema. The flow behind it calls the process API.

Boomi. It's generated. With API Control Plane, "MCP tool definitions are automatically generated from the existing API definitions" (MCP in API Control Plane). get_goods_receipt is one endpoint on the API Product. The docs don't say which OpenAPI fields become the tool name and description.

The practical difference: on MuleSoft the tool definition is its own artefact. On Boomi it's a by-product of the API design, so the OpenAPI spec has to be written with the agent in mind. A reader made this point on Post 15: in the proofs of concept they'd seen, generated descriptions that were too generic were where tool selection went wrong.

2. Where the schema lives

MuleSoft. In the Mule app. The input schema is inline JSON; the output schema can be inline or a file reference, next to the flow.

Boomi. In the API's OpenAPI definition in API Control Plane. Output schemas aren't mentioned on the page.

For a contract that has to stay identical on five platforms, both work. What matters is having one source of truth. In my design, that's the Part 7 contract. MuleSoft copies it into the Tool Listener; Boomi copies it into the OpenAPI spec. Either way, the check is the same: compare the published tools/list with the contract.

3. How GR_MISSING reaches the agent

MuleSoft. The Tool Listener has On Error Responses, content items returned "when the flow finishes in error". That's where the JSON body goes. If you don't define one, the connector generates a text item with the error description, which loses the named error. The reference doesn't say whether the result carries isError: true.

Boomi. The API returns an error response with the JSON body. The page doesn't say how that's turned into an MCP result, or whether it's marked isError.

The MCP specification is clear about what should happen: business errors come back as tool results with isError: true, so the model can act on them. Neither page I read confirms it. This is the biggest open point on both platforms, and the first thing to test.

The good news is that the rule doesn't depend on it. The body says retryable: false and hold_and_recheck, and the agent's instructions say the same.

4. Who can call it

get_goods_receipt is a read tool, so it's in stage 1 of the rollout from Part 9 on both platforms.

MuleSoft. Omni Gateway has two policies for this (MCP access control). MCP Global Access "filters the overall tool list". MCP Attribute-Based Access Control gives each client "a tailored subset of the available tools" based on claims, headers, IPs or tiers.

Boomi. Each subscription gets its own agent key, and the API Product decides which tools exist. Part 15 found that MCP Gateway says it controls "which tools and methods are accessible to which agents", but without documented rule syntax.

So MuleSoft documents per-client tool filtering as a gateway policy today. On Boomi it's either one API Product per stage or an MCP Gateway policy to confirm.

5. How you test it

MuleSoft. MUnit tests flows with mocking, call verification and coverage, and runs in Maven. So you can mock the ERP's "no receipt" response and assert that the flow returns the exact GR_MISSING body.

Boomi. Test mode runs a process without deploying it, with per-step logging. But "the process actually runs", so it touches real data. It doesn't support listener processes, so how you test an API-triggered process this way needs checking.

On both, the final test is platform-neutral: call tools/list and tools/call from an MCP client, and compare names, schemas and the error body with the contract.

What the differences mean

Neither approach is better in general. On MuleSoft, the tool is explicit: more to write, but every field is yours. On Boomi, the tool falls out of the API: less to write, but the quality depends on how carefully the OpenAPI spec was written.

For this agent, two differences matter most:

  • Error visibility. Whether GR_MISSING arrives as a named, flagged error decides whether the agent can follow the Part 8 rule. Unconfirmed on both.
  • Per-agent tool access. Documented as a policy on MuleSoft; a design choice to confirm on Boomi.

SAP is next, with the same tool and the same five questions.

Which differences matter most to you?

This series describes a reference build on a fictional company. This part is based only on MuleSoft and Boomi documentation as of 4 November 2026; no hands-on build has been run yet. Views are my own. Check current docs before you build.