Connecting Oracle's managed MCP server to AI chat clients via OAuth

Ranjith Kumar Kondoju set out to build a governed, read-only AI database assistant for an Oracle E-Business Suite instance running on Oracle Database 19c, using Oracle's managed OCI Database Tools MCP Server. The server runs in Oracle's own tenancy, so a Private Endpoint is required to give it a foothold inside a private VCN. Custom read-only SQL tools were built for instance overview, active sessions, blocking sessions, and concurrent-manager status, all scoped to a read-only database user — a control the post describes as stronger than any prompt-level instruction.

First, reusing a server URL from an earlier deployment with a different API-version date segment (e.g., `/20250830/`) produced HTTP 404 on every call, which initially looked like an authentication problem.

The journey surfaced several concrete failure modes. First, reusing a server URL from an earlier deployment with a different API-version date segment (e.g., `/20250830/`) produced HTTP 404 on every call, which initially looked like an authentication problem. Second, Oracle's server returns 404 to unauthenticated requests rather than the 401 with OAuth metadata that many clients expect for discovery-driven login flows; this prevented headless web UIs like LibreChat from ever constructing a login URL. Third, a client-credentials (app identity) token returned HTTP 200 on authentication but failed every tool call with "Missing required permissions" — because the access role is a user role, carried only by authorization-code (user) tokens, not by client-credentials tokens.

The working solution used `mcp-remote` with `--static-oauth-client-info` and `--static-oauth-server-metadata` flags to bypass the broken discovery flow, connecting from Claude Desktop and VS Code with Cline. Additional practical notes include using `npx.cmd` on Windows to avoid `ENOENT` errors, assigning each client its own OAuth callback port to avoid `EADDRINUSE` conflicts, using `gv$` views instead of `v$` for RAC visibility, and avoiding `TO_CHAR(date,'HH24:MI:SS')` in SQL because colons are parsed as bind variables.

Key facts

1. 01Oracle's OCI Database Tools MCP Server runs in Oracle's tenancy and requires a Private Endpoint to reach a private VCN database.
2. 02A stale API-version date segment in the server URL (e.g., /20250830/) causes HTTP 404 on every call, which can be mistaken for an auth failure.
3. 03Oracle's server returns 404 to unauthenticated requests instead of a 401 with OAuth metadata, breaking discovery-driven OAuth flows in headless web UIs like LibreChat.
4. 04Client-credentials tokens authenticate (HTTP 200) but fail tool calls with 'Missing required permissions' because the access role is a user role, not an app scope.
5. 05The working setup used mcp-remote with --static-oauth-client-info and --static-oauth-server-metadata flags, connecting from Claude Desktop and VS Code with Cline.
6. 06On Windows, clients must invoke npx.cmd (not npx) to avoid ENOENT errors; each client also needs its own OAuth callback port to prevent EADDRINUSE conflicts.
7. 07Using TO_CHAR(date,'HH24:MI:SS') in toolset SQL causes failures because colons are parsed as bind variables; returning the raw date avoids this.

Topics