Oracle opens Fusion Data Intelligence to agents with an MCP server

On 26 September, Oracle published on its blog a guide on getting business insights through AI conversations using the FDI MCP server. FDI stands for Fusion Data Intelligence, the analytics platform the company sells on top of its Fusion Cloud applications for ERP, human resources, supply chain and customer experience. The article explains how to query that data in natural language from an AI assistant, instead of opening a dashboard or asking the BI team for a report.

With no keynote or stage involved, the piece sends a clear signal to anyone working with corporate data: one of the big enterprise software vendors takes it for granted that its customers will interrogate financial or workforce information from an MCP client, and it has gone to the trouble of documenting how to do it.

What FDI is and where MCP fits

Fusion Data Intelligence, previously sold as Fusion Analytics, combines a managed data warehouse, processes that extract information from Fusion applications, a semantic model with predefined metrics and dashboards built on Oracle Analytics. Its pitch has always been to spare customers the most thankless part of BI: modelling ERP data so that someone can pull a reliable figure for margin or staff turnover.

MCP, the Model Context Protocol that Anthropic introduced in November 2024 as an open standard, solves the other half of the problem. An MCP server exposes tools with a name, a description and parameters; the client (Claude Desktop, Claude Code or any other compatible one) discovers them and decides when to call them based on what the user asks. In Claude Desktop you only need to declare the server in `claude_desktop_config.json`, and in Claude Code it is registered with `claude mcp add`.

Putting both pieces together lets a finance manager ask how supplier spend has evolved by region over the last quarter and get an answer built from FDI data, without needing to know which tables sit behind it.

Oracle is not starting from scratch here. In 2025 it had already added an MCP server to SQLcl, its command line tool for Oracle Database. The difference lies in the level of abstraction: SQLcl talks to the database, while FDI talks to a business model.

Why it matters

In an MCP server built on an analytics platform, what determines the quality of the answers is the layer it exposes. If the tools work against the semantic model, the assistant uses the same definition of "revenue" or "active employee" as the official dashboard, and two people asking the same question get the same figure. If the server allows free queries against the tables, the risk of the model improvising a plausible but wrong data join rises sharply.

The second point is security. Fusion data already has access rules by role and business unit, and a serious connector has to inherit them: the assistant of a purchasing manager at a subsidiary should only see what that person would see in their own dashboard. It is the first question we would ask any team planning to deploy it.

Who it is useful for

It fits three profiles above all. Finance, procurement and HR teams that already work with Fusion and ask lots of one-off questions that today end up as a ticket for the data team. BI teams themselves, who can offload repetitive requests and spend that time on the model. And integrators building custom agents, because an official connector avoids maintaining their own scripts against the ERP database.

For anyone who wants to try it, our recommendation is to start with questions whose answer is already known. Comparing what the assistant returns with the official report over a few weeks says more about the reliability of the system than any demo. It is also worth asking the model to state which metric or tool it used in each answer, and reviewing the server's call logs to spot expensive or repeated queries.

At ElephantPink we see official connectors as the sensible route for bringing agents to operational data: a server that respects the existing security model is better than ten homemade integrations. Even so, a figure that ends up in a board meeting should be traceable back to its source, however natural the question was.