AI assistants are getting good at doing things, not just talking — largely thanks to MCP (Model Context Protocol), the open standard that lets an AI client call external tools. Oracle recently shipped a managed MCP server in OCI (Database Tools MCP Server) that lets an AI client run queries against an Oracle database, with OAuth and role-based access built in.
I wanted to use it for something practical: read-only health checks for an Oracle E‑Business Suite database on 19c, surfaced inside an AI chat — "Is the database up? Any blocking sessions? Which concurrent managers are down?"
It worked in the end — an AI assistant pulling live, read-only database health data. But getting there taught me a lot about how managed MCP + OAuth actually behaves. Here's the honest journey.
The MCP service is managed — it runs in Oracle's tenancy, not your network. So it can't reach a private database by itself. You attach a Private Endpoint to give it a foothold inside your VCN. Keeping things private is exactly why you need the endpoint, not a reason to skip it.
I pointed the connection at a read-only database user. Even though the toolset can run general SQL, the account simply can't write. That one decision beats any amount of "please be careful" prompting.
Every OCI MCP server URL has an API-version segment like /20250830/
. I reused a URL from an earlier server with a different date. Result: HTTP 404 on every call, no matter how perfect my auth was. Lesson: copy the exact Server URL from the console, version date included. The 404 looked like an auth problem for ages — it wasn't.
The big one. Many clients' MCP OAuth is discovery-driven: hit the server, expect a 401 with OAuth metadata, use it to launch the login. Oracle's server returns 404 to unauthenticated requests — so a self-hosted web chat UI (I tried LibreChat) never builds the login URL and can't start the flow, even when everything is configured correctly.
Two things compound it for server-hosted web UIs:
So server-hosted chat UIs aren't a good fit for this server today.
I tried a client-credentials token (app identity) to skip the browser. It authenticated (HTTP 200!) but every tool call returned Missing required permissions
. The access role is a user role — and client-credentials tokens carry scopes, not roles. The fix was an authorization_code (user) token: the user has the role, so their token is authorized.
Desktop AI clients have a browser for the login and happily do the user OAuth flow. Using mcp-remote
with static OAuth metadata (so it doesn't depend on the 404 discovery), I connected from Claude Desktop and VS Code + Cline:
{
"mcpServers": {
"db_diag": {
"command": "npx.cmd",
"args": [
"-y", "mcp-remote",
"<exact Server URL with the correct /YYYYMMDD/>",
"3334",
"--static-oauth-client-info", "{\"client_id\":\"<public client id>\"}",
"--static-oauth-server-metadata", "{\"issuer\":\"...\",\"authorization_endpoint\":\".../authorize\",\"token_endpoint\":\".../token\"}"
]
}
}
}
A browser opened, I logged in as a user with the right role, and the tools appeared. Asking "give me the instance overview" returned live data — instance name, version, open mode, uptime — all read-only.
npx
and fail with ENOENT
— use npx.cmd
EADDRINUSE
) — give each its own port and register both redirects.TO_CHAR(date,'HH24:MI:SS')
gv$
v$
) to see all RAC instances.If you're wiring an AI client to Oracle's managed MCP server, I hope this saves you a few hours. Questions welcome in the comments. 👇