# I Connected Oracle's Managed MCP Server to AI Chat Clients - Here's What Actually Worked

> Source: <https://dev.to/rkondoju/i-connected-oracles-managed-mcp-server-to-ai-chat-clients-heres-what-actually-worked-265>
> Published: 2026-06-17 04:48:47+00:00

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. 👇