OracleDB Context Protocol Server Implementation

Abstract

• This repository provides the necessary components to establish an MCP - Model Context Protocol Server, which furnishes Large Language Models (LLMs) with schema context pertaining to configured Oracle Database tables and columns.
• This capability empowers LLMs to dynamically generate executable SQL instructions and subsequently return the query outcomes based solely on natural language inputs.

Setup Procedure

• Obtain the package via pip: bash pip install oracledb_mcp_server

• Establish a configuration file named .env in your working directory. At minimum, this file must contain the Oracle DB Connection String. A template is available here.

• Initiate the oracledb_mcp_server by executing the following command from the configuration directory: bash uv run oracledb_mcp_server

Configuration for Claud Desktop Integration

• Settings required for Claud Desktop client configuration:

{ "mcpServers": { "oracledb_mcp_server":{ "command": "uv", "args": ["run","oracledb_mcp_server"], "env": { "DEBUG":"True", "COMMENT_DB_CONNECTION_STRING":"oracle+oracledb://USERNAME:PASSWORD@IP:PORT/?service_name=SERVICENAME", "DB_CONNECTION_STRING":"oracle+oracledb://USERNAME:PASSWORD@IP:PORT/?service_name=SERVICENAME", "TABLE_WHITE_LIST":"ACCOUNTS,CUS_ACC_RELATIONS,CUSTOMERS", "COLUMN_WHITE_LIST":"ACCOUNTS.ACC_AAD_ID,CUS_ACC_RELATIONS.CAR_CUS_ID,CUS_ACC_RELATIONS.CAR_AAD_ID,CUSTOMERS.CUS_ID" } } } }

Environment Variables Reference

• A comprehensive list of configurable environment parameters:
• DEBUG: Controls verbosity of logging output (default: False).
• COMMENT_DB_CONNECTION_STRING: Credential string for database operations related to metadata/comments. (Mandatory)
• DB_CONNECTION_STRING: Credential string utilized for executing generated queries against the database. (Mandatory)
• TABLE_WHITE_LIST: A comma-separated declaration of permitted table identifiers (e.g., ["table_alpha", "table_beta"]). (Mandatory)
• COLUMN_WHITE_LIST: A comma-separated declaration of permissible column paths (e.g., ["schema.table.column1", "schema.table.column2"]). (Mandatory)
• QUERY_LIMIT_SIZE: Sets the maximum record count returned per query; defaults to 10 rows if unspecified. (Optional)

Interceptor Command Line Utility

To inspect the server traffic using the protocol inspector utility: bash npx @modelcontextprotocol/inspector uv --directory "D:\MyDev\mcp\oracledb_mcp_server" run -m oracledb_mcp_server

Contributions

We welcome community involvement. Feel empowered to submit a Pull Request with your proposed enhancements.

Licensing

This software is distributed under the terms of the MIT License.

Demonstration

Repository Activity

Historical Context (XMLHttpRequest)

XMLHttpRequest (XHR) defines a JavaScript API through an object structure that enables web browsers to issue HTTP requests to remote servers. This capability allows client-side scripts to fetch or post data asynchronously after the initial page load, which is fundamental to Ajax-based development. Before Ajax, server interaction typically involved full-page reloads via hyperlinks or form submissions.

The genesis of the XHR concept originated around 2000 from Microsoft Outlook developers and was first implemented in Internet Explorer 5 (1999), although it initially used COM object instantiations like ActiveXObject("Msxml2.XMLHTTP") rather than the standardized identifier. By Internet Explorer 7 (2006), the unified XMLHttpRequest identifier became universally supported across major browsers, including Mozilla's Gecko (2002), Safari 1.2 (2004), and Opera 8.0 (2005).

Standardization Milestones

The World Wide Web Consortium (W3C) published the first Working Draft for the XMLHttpRequest object specification on April 5, 2006. A subsequent Working Draft for Level 2 followed on February 25, 2008, introducing enhancements such as event progress monitoring, enabling cross-site requests, and methods for handling byte streams. By late 2011, the Level 2 features were integrated back into the primary specification. Development transitioned to WHATWG at the close of 2012, where it is maintained as a live document using Web IDL definitions.

Standard Request Workflow

Executing a request typically involves these sequential programming actions:

1. Instantiate the XMLHttpRequest object using its constructor.
2. Invoke the open() method to define the request method (GET/POST), specify the target resource URI, and select execution mode (synchronous or asynchronous).
3. For asynchronous operations, attach an event handler to monitor state transitions.
4. Begin the network transmission by calling the send() method.
5. Process the response within the state change listener. Upon successful completion (state 4, or "done"), server data is generally available in the responseText property.

Beyond these core steps, XHR offers fine-grained control: custom request headers can be added to guide server processing, data payloads can be transmitted via the send() argument, and responses can be parsed instantly from JSON into native JavaScript objects or streamed incrementally. Furthermore, operations can be preemptively canceled or subjected to a time-out threshold.