Introduction

Oracle Autonomous AI Database MCP Server changes where integration logic lives. Instead of standing up a separate MCP bridge, Oracle provides a managed, per-database MCP endpoint that exposes Select AI Agent tools directly from the database.

In this implementation, we built an end-to-end Hybrid RAG (HRAG) pipeline inside Oracle Database 26ai: vector search, keyword search, chunk ranking, and LLM response generation. The result is not just “database connectivity from Cline”; it is a database-native MCP capability layer.

Solution Overview

Here’s the simple version: we built a focused policy-answering prototype where the database does more than store the source document.

• It retrieves the right chunks. 
• It combines semantic search with keyword search. 
• It ranks the context. 
• It sends the right prompt to the LLM. 
• It returns a structured answer. 
• And it exposes the tested capability through MCP so compatible clients or agents can discover and call it like a tool.

Think of it like this: instead of putting the retrieval pipeline behind a separate custom service, we moved the core retrieval and orchestration logic closer to the data.

The main pieces are:

1. Oracle Autonomous AI Database 26ai — Where the Retrieval Logic Lives

This is where the source document, indexes, retrieval logic, and orchestration function live. In our case, we used an HR policy-style document as the source. The same approach could be extended to other document-backed use cases, but this implementation was validated with the HRAG flow described here.

The database is not just waiting for another service to fetch rows. In this prototype, it participates in retrieval, context preparation, and response generation.

2. Hybrid RAG — The Better Retriever

Pure vector search is powerful, but enterprise documents are full of exact terms that matter: policy names, eligibility rules, legal phrases, acronyms, benefit types, and exception language.

That is why we used hybrid retrieval.

Semantic search helps when the user asks something in their own words. Keyword search helps when exact terms matter. Together, they give better answers than either approach alone—especially for HR and policy-heavy content.

3. PL/SQL HRAG Pipeline — The Orchestrator inside the Database

We created a PL/SQL function called `HRAG_PIPELINE`. Its job is to coordinate the flow:

• take the user’s question,
• retrieve relevant chunks,
• rank and prepare the context,
• call the LLM,
• format the response,
• return a clean JSON or CLOB result.

This gives us a callable database function for the HRAG flow, rather than a one-off query.

4. Oracle 26ai MCP Server — The Tool Doorway

This is where the integration becomes simpler.

Oracle 26ai MCP Server exposes registered database tools through a managed MCP endpoint. For this implementation, that meant we did not need a separate MCP bridge for the HRAG tool.

We registered the pipeline as `HRAG_PIPELINE_TOOL` using `DBMS_CLOUD_AI_AGENT.CREATE_TOOL`. Once registered, MCP-compatible clients can discover and invoke it.

5. MCP-Compatible Clients and Orchestrators — The Consumption Layer

We tested the flow in more than one way. One path used Cline for direct MCP validation, which was useful for quickly discovering and invoking the tool. Another path used a broader orchestrator-agent setup, where the main orchestrator agent also had MCP tool capability and could call the same Oracle 26ai HRAG tool as part of a larger enterprise workflow.

That is the useful part of the MCP pattern: the consumer does not need to know the internal details of the database-side hybrid retrieval logic. It could be a developer tool, the tested orchestrator-agent path, or another MCP-compatible workflow. It sees a tool with a defined interface.

Diagram 1: Technical Architecture/Design

Figure 1. Architecture overview of the in-database HRAG pipeline and managed MCP endpoint.

Diagram 2:Process Flow

Figure 2. Runtime query flow from MCP client request through hybrid retrieval and in-database LLM generation.

Problem Solved

Traditional RAG setups usually require multiple layers (retrieval APIs, orchestration services, middleware), which increases complexity and operational overhead.

This design solves that by keeping the core workflow inside Oracle Database 26ai:

• Better relevance from hybrid retrieval (semantic + keyword).
• Reduced architecture complexity (fewer external moving parts).
• Database-native governance for identity and access.
• Predictable integration output through structured JSON responses.

How the Tool Is Discovered

For an AI client or agent to call a database capability reliably, it needs a clean contract. In this case, that contract is the MCP tool definition.

The database function is registered as a Select AI Agent tool. The MCP server then makes that tool available through the database’s MCP endpoint. When a compatible client connects, it can discover the tool, inspect what it does, pass arguments, and receive the response.

For the user, this feels simple:

“What is the overtime policy?”

Behind the scenes, the client calls `HRAG_PIPELINE_TOOL`, the database runs the HRAG pipeline, and the answer comes back with the supporting context.

Connecting Cline (and Direct API)

We validated this using Cline with type: “streamableHttp”, the per-database MCP URL, and a short-lived Bearer token. Once the endpoint is enabled, Cline can discover and invoke both built-in and custom tools.

The same capability can also be consumed directly through API (not only via Cline):

Scope and Honest Callouts

Current scope includes one remote PDF, one ONNX embedding model, in-database hybrid retrieval, structured LLM output, and MCP tool registration. This is already functional end-to-end.

Future Enhancements

• Multi-document ingestion with metadata filters.
• Retrieval quality and hallucination evaluation suite.
• Observability metrics (latency, token usage, chunk quality).
• Optional enterprise MCP gateway for throttling and multi-tenant routing.

Conclusion

The key takeaway is that Oracle Database 26ai can own a major part of the retrieval-and-generation lifecycle. By packaging hybrid retrieval and in-database LLM generation as an MCP tool, we simplified integration while improving governance and maintainability. We used Cline as the client, but the same tool can be consumed by any MCP-compatible client or orchestrator that needs governed, database-native access to enterprise retrieval and generation.