A practitioner's walkthrough for exposing an Oracle Integration Cloud project as an MCP server, then registering it inside Fusion AI Agent Studio as a governed tool an agent can call.

Why This Pattern Matters

Most Oracle Integration Cloud (OIC) tenants already have a library of proven, governed integration flows — order lookups, HR actions, approval routing, ERP calls. The Model Context Protocol (MCP) gives those existing flows a second life: instead of building a bespoke REST wrapper every time an AI agent needs to call one, OIC can now expose a project's integrations directly as MCP tools over a standard protocol that any MCP-aware client understands.

Fusion AI Agent Studio speaks that same protocol natively. Its MCP tool type lets an agent connect straight to an external MCP server — including one running inside your own OIC instance — without a custom plugin or middle-tier translation layer. The result is a short, governed path from "integration flow" to "thing an agent can reason about and call."

This post walks through that path end to end: registering an OIC integration as an agentic tool, turning on MCP at the project level, and then registering that MCP server as a tool inside Agent Studio.

Architecture at a Glance

Before working through the configuration screens, it helps to see the whole chain in one view. Everything on the left runs inside OIC; everything on the right runs inside Agent Studio. The handoff between them is a single authenticated MCP connection.

Part A — Configure the OIC Side

Step 1: Start from an Existing Integration

Any OIC integration that already runs cleanly on its own is a good candidate. The pattern doesn't require anything special about the flow itself — the same integration you'd trigger from a schedule, a REST call, or another app can be registered as a tool. What matters is that its inputs and outputs are clean and predictable, since those become the contract the agent reasons against.

Step 2: Register the Integration as an Agentic AI Tool

From within the OIC project, each integration you want an agent to use has to be explicitly registered as a tool. This is where you set:

• A clear, action-oriented tool name and description — this is the text the agent's reasoning model reads to decide when to call it

• The input parameters the integration expects, with their types and whether they're required

• The output schema the caller should expect back

Step 3: Enable MCP at the Project Level

Registering individual integrations as tools doesn't automatically expose them. A project also needs MCP support switched on — this is a project-level setting that turns the set of registered tools into a live MCP server endpoint. Once enabled, the project's MCP endpoint takes a predictable form:

https://<oic-instance>.integration.<region>.ocp.oraclecloud.com/ic/api/.../mcp/v1/projects/<project-name>

Every tool registered in that project becomes discoverable by any MCP client that connects to this URL and authenticates correctly.

Step 4: Secure the Endpoint with a Confidential Application

The MCP endpoint isn't open by default — access runs through an OAuth confidential application, the same mechanism OIC uses for other externally invoked resources. You'll need a client ID, client secret, and a scope string tied to the OIC instance, generated from the confidential app definition. Agent Studio will use these three values on the other end of the connection.

Part B — Configure the Agent Studio Side

Step 5: Add a New MCP Tool

In Fusion AI Agent Studio, navigate to the Tools tab and add a new tool, setting its type to MCP. This creates a tool record independent of any single agent — once defined, it can be reused across multiple agents and workflow nodes.

1. Enter a Tool Name and let the Tool Code auto-populate.

2. Write a Description — this doubles as the reasoning hint the agent uses to decide when the tool applies, so keep it action-focused rather than generic.

3. Select the Product Family and Product the tool belongs to, for governance and discoverability within the tool catalog.

Step 6: Add the MCP Server Connection Details

This is where the OIC and Agent Studio sides meet. The connection block needs:

• Instance URL — the OIC project's MCP endpoint from Step 3

• Transport Type — Server-Sent Events (SSE) for one-way streaming, or StreamableHTTP, which handles concurrent client connections and is the better default for most production setups

• Credential Type — Client Credentials, populated with the client ID, secret, and scope from Step 4

{   "grant_type": "client_credentials",   "client_id": "<client-id>",   "client_secret": "<client-secret>",   "scope": "<oic-instance-scope>urn:opc:resource:consumer::all" }

Step 7: Discover, Preview, and Create

Once the connection details validate, Agent Studio queries the OIC MCP endpoint and lists every tool the project exposes. From that list you select the specific operations this Agent Studio tool should surface, and — importantly — you can preview each one directly in the console: pass sample parameters, run it, and inspect the response shape before anything touches a live agent.

Confirm the tool, and it's now available to attach to any agent or workflow node, the same way a Business Object Tool or External REST Tool would be.

Practitioner Gotchas

ACE Rubric Self-Audit

Mapping this post against the seven ACE contribution criteria before submission:

Wrapping Up

The bigger shift here isn't the specific field names — those will keep evolving release over release. It's that OIC no longer needs a purpose-built AI gateway to participate in agentic workflows. Any integration that's already trustworthy enough to run in production is now, with a small amount of registration work, trustworthy enough for an agent to call directly.