What is happening on July 28
The team behind MCP locked the new edition of the rulebook back on May 21. On July 28, it becomes official. That gap was on purpose: it gave everyone who builds the software kits, the SDKs, about ten weeks to get ready.
MCP stands for Model Context Protocol. It is a standard way for AI tools like Claude or ChatGPT to talk to business systems like Oracle EPM Cloud. Think of it like a power outlet: any plug fits any socket, because everyone follows the same standard. In April I shared an open source MCP server that connects Claude to Oracle EPM Cloud through the REST APIs, and many of you have used it to run business rules, check job status, and export data, just by asking in plain English.
For those of us connecting AI to Oracle EPM Cloud, three areas matter. Let's go through them one by one.
Change 1: The handshake goes away
When you hear handshake, it might sound like credentials. It is not. This has nothing to do with passwords. It is about how Claude and the MCP server start talking to each other. And for a regular user, you will not notice any difference day to day.
The old way: when Claude connects to an MCP server, the first thing it sends is a small introduction. Something like: hey, I am Claude Desktop, I run on this version, and here is what I know how to do. The server introduces itself back, and they agree on how they will interact. Everything after that rides on that first introduction, held in memory.
Connect and remember
An introductions step first: names, abilities, rulebook version. Then a session both sides remember.
Like Smart View: you connect once, everything rides that connection, and when the session expires, nothing works until you reconnect.
Every request complete
The introduction travels inside each request, next to the work details, like which business rule to run and with which parameters.
Nothing to remember, nothing to expire. Like an Oracle EPM REST call.
There is a word for this: stateless. And you already trust it every day, because the Oracle EPM REST APIs work exactly this way. No session to expire. Every call complete on its own. In one sentence: MCP is moving from the Smart View pattern to the REST pattern.
Why it matters: shared team servers
If the server does not need to remember anyone, a company can run one shared MCP server for a whole team instead of every person keeping their own copy on their own laptop. Requests from the team go through a load balancer, a kind of triage system that looks at each incoming request and decides which copy of the server should take it, based on workload. Any copy can answer any request, because every request arrives complete.
The warning that matters more than the feature
Simpler to run does not mean simpler to secure. The tempting shortcut when teams build a shared setup is to wire it up with one stored account, sometimes even admin credentials. Do that, and every person who talks to that server gets that account's access. All of it. A user who should never see workforce data. A planner who should only see the Canadian entity. With one shared admin login behind the server, they now see everything. Your entire EPM security design gets stepped over in one move.
An agent is only as safe as the login it runs under.
The safe pattern: each person connects as themselves
The right way is that each person connects as themselves, so EPM security keeps working person by person, exactly as it was designed. The new rulebook was built with this in mind. Designing it for a real company, with the right accounts, the right scopes, and the right audit trail, is real architectural design work.
And the good news: if you use the open source server the way most people do, one user, on your own computer, with your own login, nothing really changes for you. The agent can only see what you can already see.
Change 2: Logins get stronger
There is a new piece called Enterprise Managed Authorization. Your IT team approves the MCP server once, in the company identity system, something like Okta or Microsoft Entra. After that, everyone on the approved team connects with their own company login, the same login they already use every morning. No more setting things up person by person, twenty times for twenty planners. Microsoft, Okta, and Anthropic are already using this, along with a growing list of business tools.
One honest limit: this controls who can connect. What each person can see inside EPM still depends on your EPM security design, and with agents in the picture, that job matters more, not less. That is exactly what Part 2 of the Security Field Guide for Finance Leaders covers, coming next Tuesday.
Change 3: Three features are being retired
Three older parts of the rulebook, called Roots, Sampling, and Logging, are marked for retirement, with a twelve month window before removal. I checked the open source EPM server line by line: it is built on tools only and uses none of the three. If you built from my videos, this change does not affect your setup.
What you should actually do
- On your own computer. Keep using it as it is. When the updated software kit ships, update it, test it once, done. The step by step update video is coming.
- Shared team setup. Now an option: one shared MCP server for the whole team, secured through your identity system. Run it against a test environment first, and only then production.
- Pin your versions. Lock the exact version numbers in your setup, so nothing updates itself quietly while the ecosystem rolls out the new specification.
- Planning a rollout. Ask your identity team one question: does our login system support the new MCP approval feature yet?
Resources
- The official MCP announcement of the new specification
- The Model Context Protocol standard
- The open source Oracle EPM MCP server on GitHub
- InfoQ on Enterprise Managed Authorization