MCP serverOracle Fusion Cloud ERP Agent view

How to build an MCP server for Oracle Fusion Cloud ERP

Short answer

Write a small server that exposes a handful of read-only Fusion tools over MCP, authenticates to Fusion REST with a scoped service identity, and logs every call. Any MCP client, including Claude and ChatGPT, can then use it.

The Model Context Protocol gives AI clients a standard way to call tools. For Fusion, that means one server in front of REST and reports, rather than a custom integration per assistant.

The design work is not the protocol. It is deciding which tools exist, how they map onto Fusion resources, and how a human's permissions carry through. A server that forwards arbitrary REST paths is an open door. A server with eight named tools is something you can review.

Fusion has some quirks that shape the tool design: large collections that page slowly, release-specific attributes, and a split between transactional REST and reporting through OTBI or BI Publisher.

What teams use it for

Purchase order lookup tool

get_purchase_order takes an order number and returns header, schedules, distributions summary and approval status, in a trimmed shape.

On-hand and availability tool

get_onhand takes item and organization and returns quantities by subinventory, plus reservations, for planners and customer service.

Work order status tool

get_work_order returns status, operations progress and open component shortages for shop supervisors.

Supplier scorecard tool

get_supplier_performance runs a BI Publisher report on on-time and quality metrics and returns the summary rows.

Invoice hold tool

list_invoice_holds returns payables invoices on hold with reason codes for AP analysts.

Oracle Fusion Cloud ERP integration surface

  • Fusion REST resources such as purchase orders, items, on-hand balances and work orders, using q filters, fields and onlyData=true to return exactly what a tool needs. Names and versions vary, so verify against your pod's REST API catalog.
  • BI Publisher report service for tools that wrap an existing, trusted report, with parameters passed in and CSV or XML returned.
  • OAuth 2.0 token flows through your identity domain, with a service client for reads and, if you ever add writes, a separate client and role.
  • Fusion business events delivered through Oracle Integration, which the server can subscribe to for resource notifications if you choose to add them.
  • Standard HTTP response headers and error codes from REST, which the server should translate into clear, safe tool errors.

How it works

  1. 1

    Pick an SDK and transport

    Use an official MCP SDK in TypeScript or Python. Use stdio for local testing, and Streamable HTTP behind your gateway for shared users.

  2. 2

    Define tools with strict schemas

    Each tool has typed inputs with clear descriptions and bounded limits. Reject unknown fields. Avoid a generic call_rest tool.

  3. 3

    Implement the Fusion client

    Handle token refresh, paging, retries with backoff for throttling, and mapping of Fusion errors to short messages. Pin the REST version in one config value.

  4. 4

    Add authorization

    Authenticate the MCP client user, map them to allowed business units or roles, and apply that as a filter on every query rather than trusting the model.

  5. 5

    Add audit and limits

    Log user, tool, parameters, duration and row counts. Cap rows per call and calls per minute.

  6. 6

    Test with real clients

    Try Claude, ChatGPT where it supports MCP, and the MCP Inspector. Test adversarial text in descriptions and comments.

Example flows

Order status through any MCP client

Trigger: A user asks a client for the status of a purchase order

  1. Client calls get_purchase_order with the number
  2. Server checks the user's allowed business units
  3. Server queries Fusion REST and trims the response

Result: A consistent answer regardless of which assistant asked.

Throttle protection

Trigger: A client loops over many item lookups

  1. Server counts calls per user per minute
  2. It returns a clear rate-limit message after the cap
  3. It offers a bulk tool that returns many items in one call

Result: Fusion stays responsive and the model learns to batch.

Keeping data on-prem

The MCP server is just a service, so it can run in your network or sovereign cloud, next to a self-hosted model if you use one. Fusion remains Oracle-hosted, so the server reaches it outbound over HTTPS and nothing inbound is needed. For restricted programs, run the server and an open-weight model on-prem, mirror required Fusion data through BICC into your own store, and have most tools read from that mirror, using live REST only to confirm a single record.

Security checklist

  • Use least-privilege service roles and avoid the seeded administrator roles for integration users.
  • Never expose raw REST passthrough, arbitrary report names or free-form query strings.
  • Treat all text returned from Fusion as untrusted input to the model, including comments and attachment names.
  • Keep tokens and client secrets in a vault, rotate them, and never log them.
  • Start read-only, and require proposals with human approval for any later write tool.

Ways to get it done

Build your own MCP server

Effort: A few days for a read-only prototype, weeks to harden.

Teams with a developer who knows Fusion REST and wants control.

Use Oracle Integration as the back end

Effort: Moderate, with the MCP layer still custom.

Shops that already run OIC and want its monitoring and adapters.

Partner build with Netray

Effort: Pilot with a short tool list, then extend.

You want governed tools across Fusion and other systems with a private model option.

Pitfalls

  • !Tools that return whole REST payloads waste context and leak fields. Map to small shapes.
  • !Fusion paging defaults are small. Always set limit and handle hasMore.
  • !Running the server under a single super-user hides who asked what. Carry the human identity into the audit log.
  • !Sharing an stdio server config with credentials across a team spreads secrets. Use HTTP and central auth.
  • !No version pinning means a quarterly update can change tool outputs unnoticed.

Frequently asked questions

Is there an official Oracle Fusion MCP server?

Availability changes quickly, so check Oracle's current offerings. Even if one exists, many manufacturers build a narrow server of their own so they control the tools, scoping and audit.

Which Fusion tools should come first?

Start with read-only lookups people already ask for: purchase order status, item on-hand, work order status and invoice holds. They give quick value and carry little risk. Add anything that changes data much later.

Stdio or HTTP transport?

Use stdio for local development and single-user trials. Use HTTP with proper authentication for shared deployments so credentials stay on the server and you can centralize logging and rate limits.

Will this work with ChatGPT as well as Claude?

Any client that supports MCP can use it. Support and capabilities differ by client and plan, so test each. A plain REST API alongside the MCP server covers clients that do not speak MCP.

How do I stop the model reading data it should not?

Do not rely on the model. Enforce business unit and role filters inside the server on every query, using the authenticated user, and keep the Fusion service account scoped to the minimum.

Want MCP server working on your Oracle Fusion Cloud ERP?

A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.

Get a free assessment