What can you do with this server?

This server provides 11 tools for comprehensive Oracle database interaction, covering read-only queries, DML operations, transactions, schema exploration, and diagnostics. Read & Discovery: * db_health_check, db_session_info: Check connection health and session details. * db_list_tables, db_describe_table: Explore schema (list tables, describe columns). * db_list_tns: Parse TNS aliases from tnsnames.ora. Querying: * db_query: Execute read-only SELECT/WITH statements with bind variables, row limits, and timeouts. * db_explain_plan: Preview execution plans without running queries. Write Operations (DML): * db_insert, db_update, db_delete: Insert, update, or delete records. All support dry_run to preview SQL, enforce required WHERE clauses (for update/delete), and apply row caps to prevent mass changes. Transactions: * db_transaction: Run 1–10 DML steps atomically; all succeed and commit, or all roll back. Safety & Production Features: * SQL injection prevention via parameterized binds and identifier validation. * Table whitelist/blacklist for access control. * Optional global read-only mode to block all DML. * DML safety caps (pre-counts rows, blocks if exceeding limits). * Rate limiting (configurable per-minute cap). * Connection retry with exponential backoff and pool health checks.

How do I use Oracle Database MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Oracle Database MCP Server describe the employees table" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Oracle Database MCP Server

by monsterygy

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Oracle Database MCP Server — Production Edition

A production-grade Model Context Protocol (MCP) server for Oracle database interaction, providing 11 tools for full CRUD, transactions, execution plans, and comprehensive safety guardrails.

拿来即用 — 无需 clone、无需手动 build。配置好 mcp.json 就能用。

Features

11 Tools

Tool	Purpose	Read/Write	Safety
`db_health_check`	Verify driver & connection diagnostics	Read	—
`db_list_tns`	Parse tnsnames.ora aliases	Read	—
`db_list_tables`	List all tables (optional schema filter)	Read	—
`db_describe_table`	Get column schema of a table	Read	—
`db_query`	Execute read-only SQL (SELECT/WITH)	Read	Read-only enforced
`db_explain_plan`	Preview execution plan without running	Read	—
`db_insert`	Insert a record (with dry_run)	Write	Identifier validation
`db_update`	Update records matching WHERE (with dry_run)	Write	Safety row cap
`db_delete`	Delete records matching WHERE (with dry_run)	Write	Safety row cap
`db_transaction`	Multi-step atomic transaction	Write	All-or-nothing
`db_session_info`	Current session/privilege info	Read	—

Production-Grade Features

Centralized config validation — Fails fast on missing env vars at startup
Structured logging — Request IDs, log levels (DEBUG/INFO/WARN/ERROR), JSON or text format
Custom error types — ConnectionError, QueryError, ValidationError, TimeoutError, RateLimitError, AccessDeniedError with error codes
Rate limiting — Sliding window, configurable per-minute cap
Connection retry — Exponential backoff for transient failures (ORA-03113, TNS errors)
Pool resilience — Health check, dead connection detection, automatic reinitialization
Table whitelist/blacklist — Configurable table-level access control
Read-only mode — Optional flag to block all DML operations
DML safety cap — Pre-counts matching rows, refuses if exceeding DML_MAX_ROWS
Dry-run mode — Preview generated SQL without executing for INSERT/UPDATE/DELETE
Oracle type conversion — DATE, TIMESTAMP, CLOB, BLOB → JSON-serializable values
SQL injection prevention — Parameterized binds, identifier validation, multi-statement blocking
Big-number precision guard — Rejects numeric binds beyond 2^53 - 1 (silent JS precision loss); pass big integers as strings instead
ROWID-based insert fetch — db_insert returns the inserted row via ROWID, immune to big-number key corruption
Unit tested — 55 unit tests + 18 offline protocol tests covering all security boundary functions

Related MCP server: MCP Oracle Server

Quick Start

三种方式，按需选择：

方式一：GitHub npx（最简单，推荐给同事）

无需 clone、无需手动 build。prepare 脚本会自动编译。

npx -y github:monsterygy/oracle-mcp-server

MCP 客户端配置（同事拿到这段 JSON 填上账号密码即可）：

{
  "mcpServers": {
    "oracle-db": {
      "command": "npx",
      "args": ["-y", "github:monsterygy/oracle-mcp-server"],
      "env": {
        "ORACLE_USER": "hr",
        "ORACLE_PASSWORD": "yourpass",
        "ORACLE_CONNECT_STRING": "localhost:1521/ORCLPDB1"
      }
    }
  }
}

首次启动会从 GitHub 下载并自动编译（约 30 秒），之后使用缓存秒启。

方式二：离线 Tarball（适合内网/无外网环境）

打包（你执行一次，生成 .tgz 文件）：

cd database-mcp-server
npm pack
# → 生成 gy-oracle-database-mcp-server-3.1.0.tgz（约 45KB）

安装（同事拿到 .tgz 文件后执行）：

npm install -g gy-oracle-database-mcp-server-3.1.0.tgz
# → 全局安装，gy-oracle-mcp-server 命令可用

MCP 客户端配置（使用全局安装的命令，无需 npx）：

{
  "mcpServers": {
    "oracle-db": {
      "command": "gy-oracle-mcp-server",
      "env": {
        "ORACLE_USER": "hr",
        "ORACLE_PASSWORD": "yourpass",
        "ORACLE_CONNECT_STRING": "localhost:1521/ORCLPDB1"
      }
    }
  }
}

方式三：Clone & Build（开发调试用）

git clone https://github.com/monsterygy/oracle-mcp-server.git
cd oracle-mcp-server
npm install      # prepare 脚本自动 build
npm start

本地路径方式配置：

{
  "mcpServers": {
    "oracle-db": {
      "command": "node",
      "args": ["/absolute/path/to/oracle-mcp-server/dist/index.js"],
      "env": {
        "ORACLE_USER": "hr",
        "ORACLE_PASSWORD": "yourpass",
        "ORACLE_CONNECT_STRING": "localhost:1521/ORCLPDB1"
      }
    }
  }
}

Integrate with MCP Clients

WorkBuddy / ccswitch

Add to ~/.workbuddy/mcp.json:

{
  "mcpServers": {
    "oracle-db": {
      "command": "npx",
      "args": ["-y", "github:monsterygy/oracle-mcp-server"],
      "env": {
        "ORACLE_USER": "hr",
        "ORACLE_PASSWORD": "yourpass",
        "ORACLE_CONNECT_STRING": "localhost:1521/ORCLPDB1",
        "LOG_LEVEL": "INFO",
        "DML_MAX_ROWS": "1000"
      }
    }
  }
}

After saving, open the connector management page and click Trust to enable.

Claude Desktop

Add to claude_desktop_config.json (macOS: ~/Library/Application Support/Claude/claude_desktop_config.json):

{
  "mcpServers": {
    "oracle-db": {
      "command": "npx",
      "args": ["-y", "github:monsterygy/oracle-mcp-server"],
      "env": {
        "ORACLE_USER": "hr",
        "ORACLE_PASSWORD": "yourpass",
        "ORACLE_CONNECT_STRING": "localhost:1521/ORCLPDB1"
      }
    }
  }
}

Cursor / VS Code (with MCP support)

Add to .cursor/mcp.json or VS Code MCP settings:

{
  "mcpServers": {
    "oracle-db": {
      "command": "npx",
      "args": ["-y", "github:monsterygy/oracle-mcp-server"],
      "env": {
        "ORACLE_USER": "hr",
        "ORACLE_PASSWORD": "yourpass",
        "ORACLE_CONNECT_STRING": "localhost:1521/ORCLPDB1"
      }
    }
  }
}

Debug with MCP Inspector

npx @modelcontextprotocol/inspector npx -y github:monsterygy/oracle-mcp-server

Or with a local clone:

npm run inspector

Configuration

All configuration is managed via environment variables. See .env.example for the full list.

Minimum Required

ORACLE_USER=hr
ORACLE_PASSWORD=your_password
ORACLE_CONNECT_STRING=localhost:1521/ORCLPDB1

Connection Methods

Method 1: EZ Connect (simplest)

ORACLE_CONNECT_STRING=localhost:1521/ORCLPDB1

Method 2: TNS Alias

ORACLE_CONNECT_STRING=ORCLPDB1
TNS_ADMIN=/path/to/oracle/network/admin

Method 3: Full TNS Descriptor

ORACLE_CONNECT_STRING=(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1521))(CONNECT_DATA=(SERVICE_NAME=ORCLPDB1)))

Driver Modes

Mode	Requirement	Use When
Thin (default)	None (pure JS)	Oracle 12.1+
Thick	Oracle Instant Client	Oracle 11g, advanced features

To use thick mode:

ORACLE_CLIENT_DIR=/path/to/instantclient_19_22

Safety Configuration

# Query limits
QUERY_MAX_ROWS=500           # Max rows returned by db_query
QUERY_TIMEOUT_MS=10000       # Query timeout in ms
DML_MAX_ROWS=1000            # Max rows DML can affect (safety cap)

# Access control
ALLOWED_TABLES=USERS,ORDERS # Whitelist (comma-separated, uppercase)
BLOCKED_TABLES=AUDIT_LOG    # Blacklist
READ_ONLY_MODE=false        # Block all DML if true

# Rate limiting
RATE_LIMIT_ENABLED=true
RATE_LIMIT_PER_MINUTE=60

# Logging
LOG_LEVEL=INFO               # DEBUG | INFO | WARN | ERROR | NONE
LOG_JSON=false              # JSON-structured logs if true

Docker

Quick Start with Oracle XE

docker-compose up -d

This starts:

Oracle XE 21c (gvenzl/oracle-xe:21-slim) on port 1521
MCP server connected to the Oracle XE instance

Custom Oracle Instance

docker build -t oracle-mcp-server .
docker run -i --rm \
  -e ORACLE_USER=hr \
  -e ORACLE_PASSWORD=yourpass \
  -e ORACLE_CONNECT_STRING=your-host:1521/your-service \
  oracle-mcp-server

Security Architecture

Request → [Rate Limiter] → [Zod Input Validation] → [Identifier Validation]
  → [Table Whitelist/Blacklist] → [Read-Only Check (for DML)]
  → [DML Safety Cap (pre-count)] → [Bind Variables (:1, :2)]
  → [Query Timeout] → [Row Limit (FETCH FIRST)] → Oracle DB

Security Layer	Implementation	Defends Against
Zod schema validation	`.strict()` + constraints	Invalid input, missing params
Identifier regex	`^[a-zA-Z_][a-zA-Z0-9_]{0,127}$`	SQL injection via table/column names
Table whitelist/blacklist	`ALLOWED_TABLES` / `BLOCKED_TABLES`	Unauthorized table access
Read-only enforcement	Regex check for SELECT/WITH only	DML/DDL in db_query
Multi-statement blocking	Semicolon detection	Statement injection
Parameterized binds	`:1, :2` / named binds	SQL injection in values
Bind precision guard	`assertSafeBindValues` (BIND_PRECISION_ERROR)	Silent data corruption for numeric binds beyond 2^53 - 1
DML safety cap	Pre-count + `DML_MAX_ROWS`	Mass UPDATE/DELETE
Query timeout	`Promise.race` with timer	Slow queries
Row limit	`FETCH FIRST n ROWS ONLY`	Result set overflow
Rate limiting	Sliding window	Abuse / DoS

Big-Number Precision Guard (bind safety)

JavaScript numbers are IEEE-754 doubles — any integer with an absolute value above 2^53 - 1 (9007199254740991) is silently rounded to the nearest representable value before it ever reaches Oracle. Oracle NUMBER keeps up to 38 decimal digits exact, so a bind like 9007199254740993 arrives as 9007199254740992 and corrupts the data.

The server enforces a bind precision guard (assertSafeBindValues) on every tool that accepts bind values (db_query, db_insert, db_update, db_delete, db_transaction, db_explain_plan). Unsafe numeric binds are rejected with error code BIND_PRECISION_ERROR instead of being sent to the database.

The fix: pass big integers as strings — Oracle converts them to NUMBER with full precision:

// ❌ silently corrupts: 9007199254740992 is written
{ "id": 9007199254740993 }

// ✅ exact: Oracle stores 9007199254740993
{ "id": "9007199254740993" }

ROWID Usage

db_insert fetches the inserted row back via ROWID (result.lastRowid), the physical row locator Oracle assigns to the newly inserted row:

SELECT * FROM <TABLE> WHERE ROWID = :rowid_val

Fetching by ROWID is the only reliable way to return the exact row just inserted — re-selecting by a numeric key is unsafe when the key exceeds 2^53 (see the precision guard above).

ROWID caveats (so repairs are never built on false assumptions):

ROWID is a physical locator, not a logical key — it can change after ALTER TABLE ... MOVE, partition operations, EXPORT/IMPORT, Flashback, or table reorganization.
ROWIDs are only meaningful in the database/session that produced them.
Repairing rows already corrupted by the 2^53 bug: locate the affected rows by ROWID (from a SELECT result or a previous db_insert/db_query response) and rewrite the big-number columns in a single transaction — never re-identify by the corrupted numeric key itself.

Development

# Run in dev mode with auto-reload
npm run dev

# Lint
npm run lint

Testing

Three layers of testing are provided:

1. Unit Tests (55 tests, no DB needed)

Tests pure security functions: isReadOnlyQuery, validateIdentifier, applyRowLimit, isTableAllowed, parseTnsAliasesContent, assertSafeBindValues (big-number precision guard), buildRowidSelectSql (ROWID fetch SQL).

npm test                    # Run all unit tests
npm run test:watch         # Watch mode (re-runs on file change)
npm run test:coverage       # With coverage report

2. Offline Protocol Tests (18 tests, no DB needed)

Tests the full MCP JSON-RPC handshake, tool listing, and safety guardrails (SQL injection rejection, input validation, dry-run mode) — all without an Oracle database.

npm run test:offline

This launches the MCP server with fake credentials and verifies:

JSON-RPC initialize handshake succeeds
tools/list returns all 11 tools with inputSchema
db_query rejects INSERT/DROP/multi-statement injection
db_insert rejects SQL-injected column names
db_update/db_delete reject missing WHERE clauses
db_insert dry-run returns SQL without executing
db_query rejects max_rows > 500 (Zod validation)
db_query / db_insert reject numeric binds beyond 2^53 (BIND_PRECISION_ERROR, no DB needed)
string-form big-number binds pass the precision guard
db_health_check returns structured diagnostics even on connection failure

3. End-to-End Tests (requires Oracle DB)

Sends real JSON-RPC tool calls to the MCP server connected to your Oracle database.

# Set env vars first
export ORACLE_USER=hr
export ORACLE_PASSWORD=yourpass
export ORACLE_CONNECT_STRING=localhost:1521/ORCLPDB1

# Run full e2e test suite
npm run test:e2e

# Or test a single tool
node scripts/test-mcp.mjs db_health_check
node scripts/test-mcp.mjs db_list_tables
node scripts/test-mcp.mjs db_query "SELECT * FROM dual"

# Or just list all available tools
node scripts/test-mcp.mjs list

4. MCP Inspector (interactive GUI)

npx @modelcontextprotocol/inspector npx -y github:monsterygy/oracle-mcp-server

Opens a web UI at http://localhost:5173 where you can:

View all 11 tool schemas
Call any tool with custom parameters
See raw JSON-RPC request/response
Debug connection issues

Project Structure

oracle-mcp-server/
├── src/
│   ├── config.ts          # Centralized config validation
│   ├── logger.ts          # Structured logging with request IDs
│   ├── errors.ts          # Custom error types with codes
│   ├── rateLimiter.ts     # Sliding window rate limiter
│   ├── security.ts        # Pure security functions (unit-tested)
│   ├── db.ts              # Oracle connection pool & query execution
│   ├── index.ts           # MCP server & tool registration
│   └── __tests__/
│       └── security.test.ts  # 42 unit tests
├── scripts/
│   ├── test-offline.mjs   # 15 offline protocol tests (no DB)
│   ├── test-mcp.mjs       # End-to-end tests (requires DB)
│   └── test-github-npx.mjs # GitHub npx verification test
├── Dockerfile             # Multi-stage build
├── docker-compose.yml    # Oracle XE + MCP server
├── .eslintrc.json        # Code quality rules
├── .env.example          # Configuration template
└── package.json

Generate a shareable tarball for colleagues (no npm registry needed):

npm pack
# → gy-oracle-database-mcp-server-3.1.0.tgz (≈45KB)

Colleagues install it:

npm install -g gy-oracle-database-mcp-server-3.1.0.tgz
# → gy-oracle-mcp-server 命令全局可用

License

MIT

Available Tools

11 tools

db_deleteDelete recordsA

Destructive

Delete one or more records from an Oracle database table using parameterized named binds.

Safety features:

WHERE clause is REQUIRED (deletes without conditions are blocked)
Pre-counts matching rows and refuses if exceeding DML_MAX_ROWS (default: 1000)
dry_run mode previews SQL + affected row count

Example: table_name: "users" where: "id = :w_1 AND status = :w_2" where_params: [42, "inactive"] dry_run: false

ParametersJSON Schema

Name	Required	Description
`where`	Yes	WHERE clause with named bind variables (:w_1, :w_2, ...). Example: 'id = :w_1'
`dry_run`	No	If true, return the generated SQL and affected row count without executing.
`table_name`	Yes	Target table name
`where_params`	Yes	Values for :w_1, :w_2, ... in order.

TDQS

A4.5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate destructiveHint=true. The description adds significant behavioral details beyond annotations: WHERE clause enforcement, pre-counting row limits, and dry_run mode. This fully informs the agent of safety constraints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a concise first sentence, bullet points for safety features, and an example. Every sentence is informative and earns its place; no unnecessary fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description thoroughly explains safety features and dry_run, but does not specify the return value for normal deletes (e.g., affected row count). Given no output schema, this is a notable gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the bind variable naming convention (:w_1) and providing an example usage, enhancing understanding beyond schema definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool deletes records from an Oracle database table using parameterized named binds, with a specific verb and resource. It distinguishes itself from sibling query and update tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit when-to-use guidance via safety features (WHERE required, row limit, dry_run) but does not explicitly contrast alternatives. It implies usage for safe, controlled deletes.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

db_describe_tableDescribe table schemaA

Read-onlyIdempotent

Get the column structure of a specific Oracle table: column names, data types, data lengths, nullable flag, and default values.

Use this after db_list_tables to understand a table's schema before writing queries.

Args:

table_name (string): The table name to inspect (case-insensitive)
owner (string, optional): Schema/owner name for cross-schema access

ParametersJSON Schema

Name	Required	Description	Default
`owner`	No	Optional: schema/owner of the table (case-insensitive). Use when the table is in another schema.
`table_name`	Yes	Name of the table to describe (e.g., 'users', 'orders'). Case-insensitive — will be uppercased.

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare read-only, idempotent, non-destructive. Description adds case-insensitivity and uppercasing behavior. No contradictions, but could mention that it is a quick metadata lookup with no side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences plus a bullet list for args. Front-loaded with purpose, no wasted words. Every sentence contributes value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, parameters, and usage context. Lacks explicit output format specification, but given no output schema, the described output fields are sufficient. Could be improved by noting return type (array of columns).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, baseline 3. Description adds valuable context: case-insensitivity for table_name, optional owner for cross-schema access. Adds meaning beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it retrieves column structure of an Oracle table, listing specific attributes (names, data types, lengths, nullable, defaults). Distinguishes from sibling tools like db_list_tables (which lists tables, not columns).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises to use after db_list_tables and before writing queries, and mentions optional owner for cross-schema access. Provides clear context and sequencing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

db_explain_planPreview execution planA

Read-onlyIdempotent

Generate and display the execution plan for a SQL query WITHOUT executing it.

Uses Oracle's EXPLAIN PLAN to show how the query optimizer would run the query: table access methods (FULL SCAN, INDEX RANGE SCAN, etc.), join strategies, and filter predicates.

Use this to understand query performance before running expensive queries.

Args:

sql (string): Read-only SQL (SELECT/WITH only) to analyze
params (array): Bind variable values (default: [])

ParametersJSON Schema

Name	Required	Description	Default
`sql`	Yes	A read-only SQL query (SELECT or WITH) to analyze. Must not contain DML/DDL.
`params`	No	Parameter values for :1, :2, ... bind variables.

TDQS

A4.5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds significant behavioral context by explaining the tool uses EXPLAIN PLAN, does not execute the query, and details what the plan reveals (table access methods, joins, filters). This goes beyond annotations, providing a full picture of the tool's behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: a clear purpose statement, an explanation of what EXPLAIN PLAN shows, a usage recommendation, and a clean Args section. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no output schema, so the description should clarify the return format (e.g., string containing the plan). It states 'generate and display' but does not specify what the agent receives. While basic completeness is achieved, the missing output description is a gap for an analysis tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and both parameters have descriptions in the schema. The description's Args section adds slight extra context (e.g., 'Read-only SQL (SELECT/WITH only)' for sql and 'default: []' for params), enhancing understanding. Given the high schema coverage, this is a 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool generates and displays an execution plan for a SQL query without executing it, distinguishing it from sibling tools like db_query. It specifies the analysis of table access methods, join strategies, and filter predicates, leaving no ambiguity about the tool's function.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance to use this tool for understanding query performance before running expensive queries. It implies when not to use (when actual execution is needed) but does not explicitly compare to siblings like db_query. The usage context is clear, earning a 4.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

db_health_checkHealth check: verify driver & connectionA

Read-onlyIdempotent

Verify that the Oracle driver is loaded correctly and the database connection is working.

Reports: oracledb driver version, driver mode (thin/thick), connection status, Oracle DB version, connect string, TNS config, pool stats, and available TNS aliases.

Use this tool FIRST when setting up the MCP server or when troubleshooting connection issues.

No parameters required.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds detailed reporting info (driver version, mode, connection status, etc.) without contradicting annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four concise sentences, front-loaded with purpose. Every sentence adds value; no waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters and no output schema, description fully covers purpose, usage timing, and reported information. No gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters; schema coverage is 100%. Baseline for 0 params is 4. Description mentions 'No parameters required,' which is adequate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'Verify that the Oracle driver is loaded correctly and the database connection is working.' Uses specific verb and resource, and distinguishes from sibling tools like db_list_tables or db_query.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use this tool FIRST when setting up the MCP server or when troubleshooting connection issues.' Provides clear context for use, though no explicit alternatives or when-not-to-use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

db_insertInsert a recordA

Insert a single record into an Oracle database table using parameterized named binds.

Auto-generates an INSERT with named bind variables from the provided data object. Column names are validated to prevent SQL injection. After insert, the full row is fetched back via ROWID.

dry_run mode: Set dry_run=true to preview the generated SQL without executing it.

Example: table_name: "users" data: { "name": "Alice", "email": "alice@example.com", "active": true } dry_run: false

Args:

table_name (string): Target table name
data (object): Column-value pairs to insert
dry_run (boolean): Preview SQL without executing (default: false)

ParametersJSON Schema

Name	Required	Description
`data`	Yes	Column-value pairs to insert. Example: {"name": "Alice", "age": 30, "active": true}
`dry_run`	No	If true, return the generated SQL without executing it. Useful for previewing before committing changes.
`table_name`	Yes	Target table name (e.g., 'users'). Oracle names are uppercase by default.

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description reveals key behaviors beyond annotations: parameterized named binds for SQL injection prevention, auto-generation of INSERT, validation of column names, and post-insert fetch via ROWID. Annotations indicate read-only is false and destructive is false, but the description adds rich context about execution and safety.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is succinct: a single-sentence purpose, a bullet for dry_run, an example code block, and a concise args list. No redundant information; every sentence contributes to understanding the tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (nested data object, no output schema) the description adequately covers input, behavior, and return value ('full row fetched back via ROWID'). However, the exact structure of the returned row is not specified, leaving minor ambiguity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, providing baseline 3. The description adds value with a concrete example (table_name: 'users', data with specific fields) and explains dry_run in a practical scenario (preview SQL without executing), making parameter usage clearer.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Insert a single record into an Oracle database table using parameterized named binds,' specifying the verb, resource, and technical approach. This distinguishes it from sibling tools like db_update or db_delete, which perform different operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains that the tool inserts a single record and supports a dry_run mode, but it does not explicitly state when to use this tool over alternatives (e.g., bulk inserts or transactions). Usage context is implied but lacks exclusion criteria or comparison with siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

db_list_tablesList database tablesA

Read-onlyIdempotent

List all tables in the connected Oracle database (excluding system schemas like SYS, SYSTEM, etc.).

Use this FIRST to discover what tables exist before running queries.

Args:

owner (string, optional): Filter by schema/owner name (case-insensitive)

ParametersJSON Schema

Name	Required	Description	Default
`owner`	No	Optional: filter by schema/owner name (case-insensitive). E.g., 'HR', 'APP'. If omitted, lists all non-system schemas.

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds value by noting that system schemas are excluded and that the optional owner filter is case-insensitive, enhancing behavioral understanding.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with two sentences plus a bullet, no wasted words. It is front-loaded with the core purpose and immediately provides usage advice.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool with one optional parameter and no output schema, the description covers the essential aspects: what it lists, what it excludes, and when to use it. Minor omission: no mention of pagination or result limits, but not critical.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents the single optional parameter. The description mirrors this without adding new semantic detail, warranting a baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists all tables in a connected Oracle database, excluding system schemas. This distinguishes it from sibling tools like db_describe_table or db_query, which operate on specific tables or run queries.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly advises to use this tool FIRST before running queries, providing clear usage context. It doesn't explicitly state when not to use it or compare to alternatives, but the guidance is sufficient for a discovery tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

db_list_tnsList TNS aliases from tnsnames.oraA

Read-onlyIdempotent

Read and parse the local tnsnames.ora file, returning all available TNS alias names.

Searches in order: TNS_ADMIN directory → ORACLE_HOME/network/admin → current directory.

Args:

file_path (string, optional): Explicit path to tnsnames.ora.

ParametersJSON Schema

Name	Required	Description	Default
`file_path`	No	Optional: explicit path to a tnsnames.ora file. If omitted, auto-searches TNS_ADMIN and ORACLE_HOME/network/admin.

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true and idempotentHint=true, so the description adds value by describing the search path. But it does not disclose behavior when the file is missing or other edge cases.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with three sentences that front-load the main purpose and efficiently provide the search order and parameter details. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the main functionality, search order, and parameter. It is fairly complete for a simple read-only list tool, but lacks explicit mention of error handling or return format.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already covers the single parameter with full description (100% coverage). The description reiterates the same information without adding new meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool reads and parses tnsnames.ora to return TNS alias names. It uses specific verbs and identifies the resource, and it distinguishes itself from sibling tools like db_query or db_list_tables which deal with database tables.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides search order and an optional explicit path parameter, giving clear context on when to use the tool. However, it does not explicitly state when not to use it or compare with siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

db_queryExecute read-only SQL queryA

Read-onlyIdempotent

Execute a read-only SQL query against the Oracle database. Only SELECT and WITH (CTE) statements are allowed.

IMPORTANT: Always use Oracle bind variables (:1, :2, ...) instead of string interpolation to prevent SQL injection.

Example: sql: "SELECT * FROM users WHERE active = :1 AND created_at > :2" params: ["Y", "2024-01-01"]

Safety:

Only SELECT/WITH queries allowed (INSERT/UPDATE/DELETE/DROP blocked)
Automatic row limit (FETCH FIRST n ROWS ONLY)
Query timeout enforced
Maximum 500 rows returned

Args:

sql (string): Read-only SQL with :1, :2, ... bind variables
params (array): Values for bind variables (default: [])
max_rows (number): Max rows to return (default: 100, max: 500)

ParametersJSON Schema

Name	Required	Description
`sql`	Yes	A read-only SQL query. Must start with SELECT or WITH. Use Oracle bind variables :1, :2, ... for parameters.
`params`	No	Parameter values for :1, :2, ... bind variables. ALWAYS use these instead of string interpolation to prevent SQL injection.
`max_rows`	No	Maximum rows to return (default: 100). Results beyond this are truncated.

TDQS

A4.5/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, etc. The description adds specific behavioral details: automatic row limit (FETCH FIRST), query timeout, max 500 rows, SQL injection prevention via bind variables. These go beyond annotations and provide clear safety context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with headings (IMPORTANT, Example, Safety, Args), bullet points, and front-loaded purpose. Every sentence adds value without redundancy. Suitable length for the complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Lacks explicit description of return value format (e.g., array of rows). With no output schema, the description should mention what the tool returns. Also lacks guidance on when to use db_query vs db_explain_plan or db_describe_table. Safety and parameter details are thorough, but output gap and sibling differentiation are missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema descriptions cover all 3 parameters (100% coverage). The tool description adds value with an example (using :1, :2), explains default behavior for max_rows, and reinforces bind variable usage. It clarifies the meaning beyond schema but repeats some info.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool executes read-only SQL queries against Oracle database, specifying allowed statements (SELECT, WITH) and safety constraints. It distinguishes itself from write siblings (db_insert, db_update, db_delete) and matches the title.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for read-only queries and safety constraints, but does not explicitly state when to use vs alternatives like db_explain_plan or db_describe_table. The context of siblings is provided, but no direct when-not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

db_session_infoGet current session infoA

Read-onlyIdempotent

Retrieve information about the current database session: connected user, schema, instance name, host, database name and version, session ID, NLS date format.

Useful for verifying which database/schema you're connected to and for debugging NLS-related issues.

No parameters required.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and idempotentHint, so safety is clear. The description adds value by specifying exactly what information is returned and confirming no parameters, which goes beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Every sentence adds value: purpose, listed fields, use case, and note about no parameters. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, the description lists all returned fields. It covers purpose, usage, and parameter info completely for this simple tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has no parameters; the description explicitly states 'No parameters required,' confirming and adding clarity beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Retrieve information about the current database session' and lists specific fields (connected user, schema, etc.), clearly distinguishing it from sibling tools like db_health_check or db_list_tables.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says it's useful for verifying database/schema connection and debugging NLS issues. While it doesn't mention when not to use it, the context is clear and sufficient for a simple tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

db_transactionExecute multi-step transactionA

Destructive

Execute multiple DML statements (INSERT/UPDATE/DELETE) in a single atomic transaction.

All steps either succeed and commit together, or fail and roll back together. This ensures data consistency for multi-step operations.

Limits: 1-10 steps per transaction. Each step must use Oracle bind variables (:1, :2, ...) — never string interpolation.

Example: steps: [ { sql: "UPDATE accounts SET balance = balance - :1 WHERE id = :2", params: [100, 1] }, { sql: "UPDATE accounts SET balance = balance + :1 WHERE id = :2", params: [100, 2] }, { sql: "INSERT INTO transfers (from_id, to_id, amount) VALUES (:1, :2, :3)", params: [1, 2, 100] } ]

This is an atomic money transfer: either all three succeed or none do.

ParametersJSON Schema

Name	Required	Description	Default
`steps`	Yes	Array of 1-10 DML steps to execute atomically. All succeed or all roll back.

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate destructiveHint=true and idempotentHint=false. The description adds atomicity behavior, rollback on failure, step limits, and explicit example. No contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise yet comprehensive, with a clear header, bullet for limits, and a detailed example. Every sentence provides value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description does not mention the return value (e.g., success status). However, the atomicity and step constraints are well-covered, making it mostly complete for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear descriptions for steps, sql, and params. The description adds an example and explains bind variable usage, which enhances understanding beyond schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it executes multiple DML statements atomically. It distinguishes from sibling tools like db_query, db_insert, etc. by emphasizing multi-step transactions and atomicity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains when to use: for multi-step DML operations needing atomicity. It provides limits and bind variable rules. However, it does not explicitly mention when not to use or suggest alternative tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

db_updateUpdate recordsA

Destructive

Update one or more records in an Oracle database table using parameterized named binds.

Auto-generates the SET clause from the data object. The WHERE clause MUST include named bind variables (:w_1, :w_2, ...) with corresponding where_params.

Safety features:

WHERE clause is REQUIRED (updates without conditions are blocked)
Pre-counts matching rows and refuses if exceeding DML_MAX_ROWS (default: 1000)
dry_run mode previews SQL + affected row count

Example: table_name: "users" data: { "status": "active" } where: "id = :w_1" where_params: [42] dry_run: false

Args:

table_name, data, where, where_params, dry_run (default: false)

ParametersJSON Schema

Name	Required	Description
`data`	Yes	Column-value pairs to SET. Example: {"status": "active"}
`where`	Yes	WHERE clause with named bind variables (:w_1, :w_2, ...). Example: 'id = :w_1 AND status = :w_2'
`dry_run`	No	If true, return the generated SQL and affected row count without executing.
`table_name`	Yes	Target table name
`where_params`	Yes	Values for :w_1, :w_2, ... in order. Example: [42, 'inactive']

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses key behaviors: mandatory WHERE clause, DML_MAX_ROWS check, dry_run mode. These add context beyond annotations (destructiveHint=true, readOnlyHint=false). No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well-structured with bullet points and example, but could be slightly more concise. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, but description covers return behavior for dry_run. Safety features and defaults are clearly documented. Complete for a mutation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%; description adds value by explaining auto-generated SET clause and naming convention for where_params, enhancing understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool updates records in an Oracle database using parameterized named binds. It distinguishes from siblings like db_insert and db_delete.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear guidance on required WHERE clause and safety limits, but does not explicitly contrast with other tools or provide when-not-to-use scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

11 tool updatesv3.1.0Jul 29, 2026
- First observeddb_delete
- First observeddb_describe_table
- First observeddb_explain_plan
- First observeddb_health_check
- First observeddb_insert
- First observeddb_list_tables
- First observeddb_list_tns
- First observeddb_query
- First observeddb_session_info
- First observeddb_transaction
- First observeddb_update

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.4/5.0

Scored 2026-07-29 10:25 across 11 tools

Disambiguation5/5

Each tool has a distinct, well-defined purpose: health check, TNS listing, table listing, table description, session info, query, explain plan, insert, update, delete, and transaction. There is no functional overlap or ambiguity between tools.

Naming Consistency5/5

All tool names follow the same 'db_' prefix followed by a clear verb_noun or verb pattern (e.g., db_list_tables, db_describe_table, db_insert). The naming is fully consistent in style and convention.

Tool Count5/5

With 11 tools, the server is well-scoped for an Oracle database interface. Each tool covers a necessary operation without unnecessary redundancy or bloat.

Completeness5/5

The tool set provides complete lifecycle coverage: connection verification, schema exploration (list tables, describe), querying with explain plan, and full DML operations (insert, update, delete) plus transaction support. No obvious gaps.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

ChrysaiOAuth
com.chrysai.www
Hosted MCP server for AI-driven data ops. Create apps, manage schemas, and CRUD structured data.
Data Platforms Developer Tools App Automation
2
mcpOAuth
io.prisma
MCP server for managing Prisma Postgres.
Databases Developer Tools
247
mcpOAuth
com.gibsonai
GibsonAI MCP server: manage your databases with natural language
Databases Search
233
runtime
com.formatho
Self-hosted MCP server: 26 deterministic dev, security, and EVM tools.
Developer Tools Blockchain Security
1

Related MCP Servers

oracle-sqlplus-mcp
Databases Developer Tools
sagar1012
A
license
A
quality
D
maintenance
An MCP server that connects to Oracle databases using sqlplus, enabling SQL queries, schema exploration, and DDL/DML execution through natural language.
Updated 4 months ago (2026-05-09 10:29 UTC)
8
12 npm
MIT
MCP Oracle Server
Databases Developer Tools
jaikishpai
A
license
Not graded
quality
D
maintenance
A production-grade Node.js MCP server for Oracle Database with HTTP transport, enabling SQL query execution, table listing, schema retrieval, and natural language to SQL conversion via MCP tools.
Updated 9 months ago (2025-12-10 06:51 UTC)
11 npm
1
MIT
oracle-db-mcp
Databases Developer Tools
Kuass
A
license
B
quality
C
maintenance
MCP server for accessing Oracle databases, enabling schema exploration, query execution, and performance analysis.
Updated 8 months ago (2026-01-26 07:27 UTC)
12
MIT
Mini Oracle MCP Server
Databases Developer Tools
Giafn
A
license
Not graded
quality
C
maintenance
MCP server to connect to Oracle databases and run SQL queries (up to 150 rows) via a single 'query' tool.
Updated 4 months ago (2026-05-04 03:33 UTC)
10 npm
MIT

Oracle Database MCP Server — Production Edition

Features

11 Tools

Production-Grade Features

Quick Start

方式一：GitHub npx（最简单，推荐给同事）

方式二：离线 Tarball（适合内网/无外网环境）

方式三：Clone & Build（开发调试用）

Integrate with MCP Clients

WorkBuddy / ccswitch

Claude Desktop

Cursor / VS Code (with MCP support)

Debug with MCP Inspector

Configuration

Minimum Required

Connection Methods

Method 1: EZ Connect (simplest)

Method 2: TNS Alias

Method 3: Full TNS Descriptor

Driver Modes

Safety Configuration

Docker

Quick Start with Oracle XE

Custom Oracle Instance

Security Architecture

Big-Number Precision Guard (bind safety)

ROWID Usage

Development

Testing

1. Unit Tests (55 tests, no DB needed)

2. Offline Protocol Tests (18 tests, no DB needed)

3. End-to-End Tests (requires Oracle DB)

4. MCP Inspector (interactive GUI)

Project Structure

Local Sharing (npm pack)

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers