Remote MCP Server for Oracle Database on Google Cloud: Letting AI Agents Query Oracle Safely

On this page

1. 01 · Why This Announcement Matters
2. 02 · MCP in Plain Words
3. 03 · Why Agents Need Governed SQL Access
4. 04 · How the Remote MCP Server Works
5. 05 · One Request, Step by Step
6. 06 · What It Replaces
7. 07 · Knowledge Catalog: Metadata and Governance (Preview)
8. 08 · Security Best Practices
9. 09 · Getting Started
10. 10 · Key Takeaways
11. 11 · Frequently Asked Questions

01 · Why This Announcement Matters

Oracle AI World, Las Vegas · 28 October 2026

Agents that cannot reach your data are just chatbots.

Every enterprise AI pilot hits the same wall. The model is clever, the demo is impressive, and then someone asks for this quarter's open orders or last night's failed payments. Those answers sit in an Oracle database, behind a firewall, guarded by credentials that nobody wants to hand to a language model. Teams end up writing glue code: a question-to-SQL service, a jump host and a password stored where it should not be.

Google Cloud's 28 October 2026 announcement for Oracle AI Database@Google Cloud takes that glue away. The Remote MCP Server with Data API, first announced at Google Cloud Next '26, is now generally available. It gives AI agents, Google Cloud services and enterprise applications one standard interface to run SQL against Oracle databases. Credentials are resolved automatically through Secret Manager, Google Cloud IAM policies are enforced on every call, and the work runs through the IAM-governed ExecuteSQL Data API.

02 · MCP in Plain Words

Answer: The Model Context Protocol (MCP) is an open standard that lets an AI agent discover and call tools, such as a tool that runs a SQL query, through one common interface. An MCP server publishes the tools; an MCP client inside the agent calls them. The agent does not need custom code for each database or API.

Think of MCP as a universal power socket for AI agents. Before it, every agent framework plugged into databases and other systems its own way, and every integration was a small custom project. With MCP, a server describes its tools and their inputs, and a client inside the agent calls them when the model needs them.

"Remote" matters here. A local MCP server runs on a developer's laptop next to the agent. A remote MCP server is a hosted service the agent reaches over the network. For Oracle AI Database@Google Cloud, that hosted service is run by Google Cloud, sits in front of your Oracle databases, and applies Google Cloud identity and secrets handling to every request.

03 · Why Agents Need Governed SQL Access

Answer: An agent decides at run time which queries to send, so you cannot review every statement in advance the way you review application code. Access has to be governed at the boundary instead: who the agent is, what it may call, which database account it uses, and a record of what happened.

A traditional application runs SQL that developers wrote and reviewed. An agent writes its own SQL in response to a prompt that might come from a user, a document or another agent. You are no longer approving queries; you are approving an identity and a set of privileges, and trusting the boundary to hold.

That boundary needs four properties. It must know who is calling, using the same identity system as the rest of your cloud. It must hold the database credentials itself, so a leaked prompt or log never exposes a password. It must enforce policy on each call, not once at deployment. And it must leave an audit trail that security teams can query. The table shows how the Remote MCP Server maps to each one.

04 · How the Remote MCP Server Works

Answer: Agents and apps call the Remote MCP Server using standard MCP. The server passes SQL work to the ExecuteSQL Data API, which checks Google Cloud IAM, resolves database credentials from Secret Manager, runs the statement on Oracle AI Database@Google Cloud and returns the results.

The figure below shows the main pieces in one Google Cloud region. On the left are the callers: AI agents built with agent frameworks, Google Cloud services, and enterprise applications. In the middle is the managed access layer: the Remote MCP Server, the ExecuteSQL Data API, Cloud IAM and Secret Manager. On the right is the Oracle-operated Exadata infrastructure that runs Oracle AI Database inside the Google Cloud region, linked to an OCI parent region as in any Oracle AI Database@Google Cloud deployment. Knowledge Catalog, still in preview, sits alongside and catalogs schemas and business metadata.

The black arrows are the only path SQL takes, and it never bypasses IAM or Secret Manager. Callers never hold a database password or a network route to the database. The dashed grey arrow is metadata only: Knowledge Catalog describes the data so agents can find the right tables, but it is a preview feature and not required to use the MCP Server.

What Google has not spelled out

The announcement describes the design, not every detail. The exact tool names the server exposes, the IAM roles and permissions involved, limits on result sizes, and which database services and versions are supported are documented separately. Check the setup guide at docs.cloud.google.com/oracle/database/docs/use-oracledatabase-mcp before you design around any of them.

05 · One Request, Step by Step

Answer: An agent calls the SQL tool, IAM checks the caller, the Data API resolves the database credentials from Secret Manager, the SQL runs on Oracle and the rows return to the agent. If IAM denies the call, the request stops before any secret is read or any SQL reaches the database.

It helps to follow one request end to end. Imagine an operations agent asked, "How many orders shipped late yesterday?" The agent's model decides it needs data, writes a SELECT statement and calls the SQL tool on the Remote MCP Server. The figure shows two runs of that call: one from an identity that holds the right IAM permission, and one from an identity that does not. The order of checks matters. Policy comes first, credentials second and SQL last, so a denied caller never gets near the database.

Path B is the reason this design exists. A misconfigured or compromised agent gets an error, not a connection. No secret is retrieved and no session is opened on the database, and the denial is available to your security team in the audit trail, where it is a useful early warning.

06 · What It Replaces

Answer: Google says the Remote MCP Server removes the need for custom natural-language-to-SQL middleware, bastion VMs and plaintext passwords. In their place you get a managed MCP endpoint, IAM policy on each call and credentials held in Secret Manager.

Most teams that already connect agents to Oracle built something like the left side of the figure below. A custom service turns a question into SQL. A bastion VM, a hardened jump host, sits on the network path because the agent runtime cannot reach the database directly. The service connects with a database password kept in a config file or environment variable. Every one of those parts is code or infrastructure you own, patch and explain to auditors.

The right side is the managed path. The agent still decides what to ask, and you still design database accounts and network access for Oracle AI Database@Google Cloud. What disappears is the custom plumbing between the two.

The red tags mark work that never ends: code to maintain, a VM to patch, a secret that can leak and sessions that are hard to tie to an agent. The green tags show the same jobs handled by managed Google Cloud services.

07 · Knowledge Catalog: Metadata and Governance (Preview)

Answer: Knowledge Catalog integration, in preview with sign-up, catalogs Oracle schemas and business metadata alongside Google's Agentic Data Cloud. It gives agents semantic context to find the right data, and gives governance teams consistent access controls and data provenance tracking.

Running SQL safely is half the problem. The other half is running the right SQL. An agent that sees a table called ORD_HDR_X has to guess what it holds, which columns mean "shipped" and whether it is even the authoritative copy. Knowledge Catalog addresses that. According to Google, it automatically catalogs Oracle schemas and business metadata, unifies metadata discovery and governance across Oracle databases and Google's Agentic Data Cloud, and adds consistent access controls, data provenance tracking and semantic context for agents.

In practice an agent can look up which table answers a business question before it writes a query, and a data steward can see where an answer's data came from. The Gemini Connector, covered in the next post, also uses Knowledge Catalog to ground its answers.

08 · Security Best Practices

Answer: Give each agent its own identity, grant it the narrowest IAM access, map it to a read-only database account, keep secrets in Secret Manager, and turn on auditing at both the Google Cloud and Oracle layers. Review denials and unusual queries regularly.

The managed path removes whole classes of mistakes, but it does not choose your privileges for you. These practices are general; combine them with the roles in Google's documentation and your existing Oracle security standards.

Govern the identity, not the query. Agents will write SQL you never predicted, so the boundary and the database account must be safe for every query they could write.

09 · Getting Started

Answer: Start with Google's setup guide at docs.cloud.google.com/oracle/database/docs/use-oracledatabase-mcp. Prepare a dedicated database account and a Secret Manager secret, grant a test identity the documented IAM access, connect an MCP client, and prove both an allowed and a denied request before you widen access.

The steps below are a practical order of work, not a substitute for the guide, which lists the exact roles and tool names.

1. Read the setup guide. Confirm prerequisites, supported database services and required IAM permissions at docs.cloud.google.com/oracle/database/docs/use-oracledatabase-mcp.
2. Create a dedicated database account. Grant it read-only access to the objects your first use case needs, and nothing else.
3. Store the credentials in Secret Manager. Restrict who can read or change that secret.
4. Create an identity for the agent. Grant it only the documented access needed to call the MCP Server.
5. Connect an MCP client. Point your agent framework or application at the Remote MCP Server and run a simple query.
6. Test the denial path. Call the same tool with an identity that lacks access and confirm it is refused and logged.
7. Turn on auditing and review. Enable the audit logs you need in Google Cloud and Oracle, then review them before adding more agents.

10 · Key Takeaways

1. The Remote MCP Server is GA. AI agents, Google Cloud services and apps get one standard MCP interface to run SQL on Oracle AI Database@Google Cloud.
2. It runs on the IAM-governed ExecuteSQL Data API. IAM policy is checked per call, and a denied caller never reaches the database.
3. Secrets stay in Secret Manager. Credentials are resolved automatically, so agents never see or store a password.
4. Less custom plumbing. No NL-to-SQL middleware, bastion VMs or plaintext passwords to build, patch and audit.
5. Database security still matters. Use read-only accounts, least-privilege IAM and auditing; Knowledge Catalog is a preview add-on.

11 · Frequently Asked Questions