DEV Community

Cover image for Part 14: Build 2a — Boomi: hosting the tool contract
Shakar Bisetty
Shakar Bisetty

Posted on Edited on

Part 14: Build 2a — Boomi: hosting the tool contract

#boomi #mcp #ai #agents

Part 14 · One Agent, Five Platforms

Same nine tools, new platform. Part 11 hosted the tool contract on MuleSoft. This part does the same on Boomi, and only that: where the tools live, how the agent finds them, and what happens to the schemas, the named errors and the approval gate on the way. The agent itself, the guardrails and the scores come in Part 15.

Like Parts 11 and 13, this build is documentation-only. Everything below comes from Boomi's official documentation as I read it on 2 November 2026, linked in the text. I haven't run the invoice agent on Boomi yet.

Three ways Boomi can host the tool contract

The short answer

Boomi documents three ways to give an agent tools, and they behave very differently:

  1. Agentstudio Integration tool. The agent runs a deployed Boomi process.
  2. API Control Plane MCP server. An API Product is exposed as a hosted MCP server, with one tool per API endpoint.
  3. MCP Server connector. A Boomi process becomes an MCP tool directly, on your own runtime.

For the invoice agent, the second one fits. Here's why, route by route.

Route 1: the Integration tool

The integration tool page is clear about the limits:

  • It only supports non-listener processes.
  • The agent gets back execution status only, success or failure, not the process's return documents.
  • Up to five input parameters, typed as integer, string or boolean. Tool names are limited to 32 characters and descriptions to 150.

That rules it out for this contract. Six of the nine tools from Part 7 are reads: get_invoice, get_purchase_order and the rest exist to return data. A read tool that only says "success" is no use. The page itself says that for data retrieval you should build an API and use an API tool instead.

Route 2: API Control Plane as an MCP server

This is the route the contract maps onto cleanly. The MCP in API Control Plane page describes it:

  • You turn on Expose REST APIs as Tools for an API Product. MCP is off by default.
  • "Each Tool is an endpoint in an API that is registered in API Control Plane." Tool definitions are generated from the APIs' OpenAPI specifications.
  • Each subscription gets its own AI Agent Key, sent in an x-agent-key header. Backend authentication, including OAuth, is passed through.
  • Supported MCP protocol versions go up to 2025-11-25.
  • Sessions end after 30 minutes, and a single tool call's response is capped at 1 MB. GraphQL APIs can't be exposed as tools.

The product gets an MCP Server Version and is listed in the MCP Registry. Published registry versions are read-only, so a change to the tool list means a new version. In Agentstudio, these show up as API Control Plane tools or MCP tools, and you choose which ones to import (adding capabilities to agents).

So the build is:

  • The nine process APIs as Boomi API services (or existing APIs), each with an OpenAPI definition that carries the Part 7 schemas.
  • One API Product containing the nine endpoints, with Expose REST APIs as Tools turned on.
  • The invoice agent in Agentstudio, importing those tools from the registry.

The process APIs stay the safety layer, exactly as in series 1 and Part 11. The MCP layer is generated from them, not hand-built.

Route 3: the MCP Server connector

The MCP Server connector is the most direct mapping: set a process's Start shape to MCP Server, import a JSON input schema, give the tool a name and description on the operation's Options tab, and end the process with Return Documents. It even has a Return application error response option, which sends the application error back "to the LLM for it to react appropriately". That's exactly where the named errors from Part 8 would go.

But today it doesn't fit a finance agent:

  • It's an early-access preview, and the page says not to use it in production or with production data.
  • It supports SSE only, over plain HTTP. No OAuth or basic auth; you supply API tokens.
  • No output schemas and no tool annotations.
  • It runs on your own runtimes or clusters, and Agentstudio needs a hybrid setup to use it.

It's the one to watch. If it reaches general availability with Streamable HTTP and TLS, it would be a simpler route than Route 2.

How the contract survives the trip

Checking Route 2 against the contract from Part 7:

  • Names. The docs say tools are generated from OpenAPI definitions, but not how the tool name is derived. I'd set operationId to the contract name (get_invoice, not getInvoiceById) and check that it comes through unchanged.
  • Input schemas. These come from the OpenAPI request definitions, so enums and additionalProperties: false have to be in the spec. Whether they survive generation needs checking.
  • Output schemas. The page doesn't say whether output schemas are generated. The tools should still return identifiers like posting_id, as Part 7 asked.
  • Named errors. The page doesn't say how an API error response reaches the agent, or whether it's marked isError. The Part 8 rule doesn't change: the error body carries the name, and the agent follows the rule for that name.
  • Annotations. Not mentioned. As Part 7 said, they describe; they don't enforce.

None of these gaps block the design. All of them are things a hands-on build answers in an afternoon.

The approval gate and the rollout stages

The gate stays in the process API, as in Part 6. The post_invoice_adjustment and notify_supplier processes check the approval_id against the workflow's approval record and return APPROVAL_MISSING if it's missing, expired, already used or doesn't match. That's ordinary Boomi process logic, and it doesn't care which route called it.

The stages from Part 9 need a little more thought. On MuleSoft, a gateway allow-list moves the agent between stages. In the Boomi docs I read, the unit of exposure is the API Product. One way to do it is three products: stage 1 with the six read endpoints, stage 2 adding request_approval, stage 3 with all nine. Each has its own MCP server and agent key, and moving a stage means switching the agent's server and key. That's still configuration, not code. Choosing which tools to import in Agentstudio also works, but that's agent configuration, not a gateway control, so I wouldn't rely on it alone.

Whether Boomi's AI Gateway or Agent Control Tower can do this as a policy instead is a question for Part 15.

What this sets up for Part 15

From the hosting side, Boomi is strong where it counts: tools generated from APIs you already govern, per-subscription agent keys, a registry, and current MCP protocol versions. The open points are specific: whether the names, schemas and named errors come through generation intact, and how cleanly the rollout stages can be switched.

Part 15 builds the agent in Agentstudio, adds the guardrails, and gives Boomi its provisional scores.

Boomi users: how do you expose integrations as tools?

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

Top comments (0)