What can you do with this server?

The mcp-oracle-dba server provides a secure, read-only MCP interface to Oracle databases (12.1+, 19c, 23ai; single instance and RAC), enabling LLMs to safely query metadata and data with multi-layer guardrails, PII redaction, and full audit logging. Core Tools: * list_schemas: Returns the configured allowlist of schemas the server can query (no database call required). * describe_table: Retrieves column metadata for a SCHEMA.TABLE, restricted to allowed schemas. * run_select: Executes SELECT or WITH queries with safety guards: * Blocks DDL, DML, PL/SQL, dangerous packages (DBMS_*, UTL_*, SYS.*), and multi-statement injections * Automatically redacts sensitive columns (SSN, SALARY, PASSWORD, etc.) * Caps returned rows (configurable via MCP_MAX_ROWS, default 100) * Enforces server-side statement timeouts * explain_plan: Returns Oracle EXPLAIN PLAN output for a given SELECT query — useful for diagnosing slow queries. * top_sql: Shows recent high-elapsed-time SQL from v$sql (default: last 60 min, top 10 results). Optional AWR/ASH Tools (requires MCP_ENABLE_AWR=true and Oracle Diagnostic Pack): * list_awr_snapshots: Lists available AWR snapshots. * awr_summary: Compact AWR analysis — top SQL, wait events, and DB-time breakdown. * awr_top_sql: Top SQL by elapsed time between two AWR snapshots. * awr_wait_events: Top ASH wait events between snapshots. * awr_time_model: DB-time breakdown across DBA_HIST_SYS_TIME_MODEL counters. What it will NOT do: * Execute INSERT, UPDATE, DELETE, MERGE, DROP, CREATE, ALTER, or any other mutating statement * Call dangerous packages or expose unredacted PII column values * Return more rows than the configured cap Every tool call (including rejections) is logged to an audit file for compliance. Security is enforced through five independent guardrail layers and a dedicated read-only database user.

How do I use mcp-oracle-dba?

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., "@mcp-oracle-dba List available Oracle schemas" 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.

mcp-oracle-dba

by shopsmartai

Overview Schema Source Related Servers Discussions Admin

Python

Remote

mcp-oracle-dba

A Model Context Protocol (MCP) server for Oracle Database — read-only, audited, and SQL-guarded. Lets Claude Desktop, Claude Code, Cursor, or any MCP client query your Oracle database safely.

Built by an Oracle Apps DBA. Designed so an LLM can explore production data without ever being able to mutate it.

demo

In the screenshot above, Claude (via this MCP server) successfully runs discovery + a real SELECT over my Oracle 23ai database — and is then refused when it tries to DROP TABLE. Every call is recorded in the audit log.

Why this exists

Most "let your LLM query the database" demos are unsafe by default: they give the LLM a connection string and trust it not to send DROP TABLE. This server flips that model. The LLM gets a narrow, explicit toolset, every call is parsed against a multi-layer SQL guardrail, the result rows are PII-redacted, and every call is audit-logged.

If the LLM hallucinates DROP TABLE users while debugging a slow query, the server refuses before the SQL ever reaches Oracle.

Related MCP server: mcp-sqlserver-readonly

Tools exposed

Core (5 tools, always enabled):

Tool	What it does
`list_schemas`	Returns the allowlist of schemas the server is configured to query.
`describe_table`	Column metadata for `SCHEMA.TABLE`. Allowlist-enforced.
`run_select`	Validates + runs a `SELECT` / `WITH` query. Row-capped, PII-redacted.
`explain_plan`	Oracle `EXPLAIN PLAN` output for a query (`DBMS_XPLAN.DISPLAY`).
`top_sql`	Top SQL by elapsed time from `v$sql` over the last N minutes.

AWR / ASH (5 tools, gated behind MCP_ENABLE_AWR=true):

Tool	What it does
`list_awr_snapshots`	Available AWR snapshots in the last N hours (one row per `snap_id`, multi-tenant dedup'd).
`awr_summary`	Compact AWR analysis: top SQL + wait events + DB-time breakdown in one JSON. Reach for this first when answering "why was the DB slow between X and Y?".
`awr_top_sql`	Top SQL by elapsed time between two snapshots. Per-`sql_id`: elapsed seconds, executions, sec/exec, buffer gets, disk reads, CPU seconds, 200-char SQL preview.
`awr_wait_events`	Top ASH wait events between snapshots. From `DBA_HIST_ACTIVE_SESS_HISTORY`.
`awr_time_model`	DB-time breakdown across cumulative `DBA_HIST_SYS_TIME_MODEL` counters. Useful for "where did DB time go?".

AWR/ASH tools require Oracle Diagnostic Pack licensing on Standard Edition and Enterprise Edition production databases. Oracle Database Free Edition (23ai) includes the diagnostic features for development use. Set MCP_ENABLE_AWR=true in .env to expose these tools.

Security model (defense in depth)

Five independent layers — any one of them rejects unsafe input before it reaches the database:

Single-statement parser: rejects ... ; DROP TABLE x injection.
First-keyword allowlist: only SELECT and WITH accepted.
Banned-keyword scan: blocks INSERT, UPDATE, DELETE, MERGE, TRUNCATE, DROP, CREATE, ALTER, GRANT, REVOKE, BEGIN, DECLARE, EXECUTE, CALL, COMMIT, ROLLBACK, SAVEPOINT, LOCK, RENAME, FLASHBACK — anywhere in the statement.
Dangerous-package regex: blocks any call into DBMS_*, UTL_*, or SYS.* (think DBMS_LOCK.sleep, UTL_HTTP.request, UTL_FILE.fopen).
Row cap: every approved query is wrapped in SELECT * FROM (...) FETCH FIRST :max_rows ROWS ONLY.

Plus:

Read-only DB user (mcp_ro): zero INSERT/UPDATE/DELETE privileges at the SQL layer. The guardrails are belt-and-suspenders on top of this.
Schema allowlist for describe_table: only configured schemas are introspectable.
PII redaction: column names matching SSN, SALARY, TAX_ID, PASSWORD, etc., are auto-replaced with [REDACTED] in returned rows.
Statement timeout: enforced server-side via oracledb's call_timeout.
Audit log: every tool call (including rejections) emits a JSON line to MCP_AUDIT_LOG (default ./audit.log).

The guardrails come with 45 security tests (pytest tests/) — every test represents a real attack vector explicitly blocked.

Quickstart

Prerequisites

Python 3.12+
uv: brew install uv
An Oracle database with a read-only user
Optional: an MCP client (Claude Desktop, Claude Code, Cursor)

1. Clone + install

git clone https://github.com/shopsmartai/mcp-oracle-dba.git
cd mcp-oracle-dba
uv sync

2. Configure environment

cp .env.example .env
# Edit .env — set ORA_USER, ORA_PASSWORD, ORA_DSN

ORA_DSN examples:

localhost:1521/FREEPDB1 — local Oracle 23ai Free
oracle23ai.orb.local:1521/FREEPDB1 — OrbStack on macOS, when running the server from a normal terminal (avoids port-forwarding NAT issues that mangle TNS handshakes)
192.168.215.2:1521/FREEPDB1 — OrbStack container direct IP, required when this MCP server is launched by Claude Desktop or any sandboxed macOS app. Sandboxed child processes do not have access to OrbStack's .orb.local DNS resolver — the connection fails with DPY-6005 / No route to host. Use docker inspect oracle23ai --format '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' to get the IP.
prod-db.example.com:1521/PRODPDB — production (use a read-only user!)

3. Run the tests (security check)

uv run pytest tests/ -v

You should see 45 passing. Every test maps to a real attack vector — DDL, DML, multi-statement injection, dangerous package calls, etc.

4. Smoke test

uv run python -c "
from mcp_oracle_dba.server import list_schemas, run_select
print('Schemas:', list_schemas())
print(run_select('SELECT user FROM dual'))
"

5. Wire to Claude Desktop

Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows):

{
  "mcpServers": {
    "oracle-dba": {
      "command": "/opt/homebrew/bin/uv",
      "args": [
        "--directory",
        "/absolute/path/to/mcp-oracle-dba",
        "run",
        "mcp-oracle-dba"
      ]
    }
  }
}

Restart Claude Desktop. The tools should appear under the 🔧 icon in the chat input.

Try asking: "List the schemas available in our Oracle DB", "Describe the FND_USER table", "What's the top SQL in the last hour?"

Configuration reference

All settings load from .env (see .env.example):

Variable	Default	Meaning
`ORA_USER`	(required)	DB user (should be read-only)
`ORA_PASSWORD`	(required)	DB password
`ORA_DSN`	(required)	Easy-Connect or TNS-format DSN
`MCP_MAX_ROWS`	`100`	Hard cap on rows returned by `run_select`
`MCP_STATEMENT_TIMEOUT_SECONDS`	`5`	Server-side statement timeout
`MCP_SCHEMA_ALLOWLIST`	`APPS,APPLSYS,SYS,RAGAPP`	Comma-separated schemas allowed for `describe_table`
`MCP_COLUMN_DENYLIST`	`SSN,SALARY,TAX_ID,PASSWORD,…`	Column-name substrings to redact
`MCP_AUDIT_LOG`	`./audit.log`	JSON-line audit log path
`MCP_ENABLE_AWR`	`false`	Expose the 5 AWR/ASH tools (requires Diagnostic Pack on production)

Recommended database setup

A minimal read-only Oracle user for the MCP server:

CREATE USER mcp_ro IDENTIFIED BY "strong_password";
GRANT CREATE SESSION TO mcp_ro;
GRANT SELECT_CATALOG_ROLE TO mcp_ro;
-- For each business table you want exposed:
GRANT SELECT ON appsapp.fnd_user TO mcp_ro;
-- ...

SELECT_CATALOG_ROLE is preferred over individual V$ grants — it covers all data-dictionary and dynamic-performance views in one line, and avoids the "SYSTEM can't forward SYS-owned grants" issue you hit otherwise.

Oracle version compatibility

Version	Status	Notes
Oracle 23ai (CDB+PDB or single)	Tested	Primary development target
Oracle 19c	Works without code changes	Same tools, same syntax. The MCP server uses no 23ai-specific features. Most production EBS R12.2 environments are on 19c.
Oracle 12.1+	Works	`python-oracledb` thin mode supports anything from 12.1 onward
RAC	Works	`oracledb` handles SCAN listeners; tools query instance 1 by default

For EBS R12.2 + 19c specifically, customize MCP_SCHEMA_ALLOWLIST:

MCP_SCHEMA_ALLOWLIST=APPS,APPLSYS,FND,AR,AP,GL,SYS

What's NOT included (yet)

Connection pooling — current implementation opens one connection per tool call. Fine for sparse MCP workloads; swap in oracledb.create_pool() if you need higher throughput.
Write-mode tools — by design. There are no INSERT_* or UPDATE_* tools, and there never will be in this server. Write paths belong in dedicated, application-specific MCP servers with their own threat model.
Thick-mode support for environments requiring Oracle Wallet — thin mode handles most cases including SSL; thick mode would need a separate code path.

Roadmap

Core tools: list_schemas, describe_table, run_select, explain_plan, top_sql
SQL guardrails + 45 security tests
PII column redaction
JSON-line audit log
AWR summary tool (top SQL + waits + time model in one JSON blob)
ASH wait-event sampler tool
AWR top SQL + time model tools
AWR feature flag (MCP_ENABLE_AWR) for Diagnostic Pack gating
Connection pooling (oracledb.create_pool()) for higher throughput
Hybrid TNS + thick-mode support (for environments requiring Oracle Wallet)
Structured failure responses (machine-readable JSON refusals with policy ID + retry guidance, per community feedback)
CI integration tests against a Docker gvenzl/oracle-free service container

License

MIT. Oracle and Oracle Database are trademarks of Oracle Corporation. This project is not affiliated with or endorsed by Oracle.

Available Tools

5 tools

describe_tableA

Return column metadata for SCHEMA.TABLE.

Errors if `schema` is not in the configured allowlist.

ParametersJSON Schema

Name	Required	Description	Default
`schema`	Yes
`table`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior3/5

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

No annotations are present, so the description carries the burden. It mentions an error condition for schema allowlisting but does not explicitly state read-only behavior, response format beyond 'column metadata', or handling of non-existent tables. Adequate but lacking depth.

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 sentences. First sentence efficiently states the purpose; second adds a key constraint. No extraneous text. Front-loaded with the core action.

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 simple nature of the tool (returning column metadata) and presence of an output schema, the description covers the essential: what it does and a notable error condition. It could mention that results are read-only or that it describes exactly what columns exist, but overall sufficient.

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

Parameters2/5

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

Input schema has 0% property description coverage. The description uses 'SCHEMA.TABLE' to imply a dot-separated usage pattern but does not specify case sensitivity, allowed characters, or format conventions. Minimal value added beyond the schema's property names.

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 explicitly states 'Return column metadata for SCHEMA.TABLE', which clearly identifies the action (return) and resource (column metadata) for a specific schema and table. It distinguishes from sibling tools like list_schemas or run_select by implying DDL metadata retrieval.

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 provides a constraint ('Errors if schema is not in the configured allowlist') but does not explicitly guide when to use this tool over siblings (e.g., vs list_schemas for schema listing or run_select for data). Usage context is implied but not explicit.

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

explain_planB

Return Oracle EXPLAIN PLAN output for a SELECT query.

ParametersJSON Schema

Name	Required	Description	Default
`sql`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It states the tool returns output but does not mention that it is read-only, does not execute the query, or any prerequisites like required privileges. This lack of detail could mislead an agent into thinking the query is run or that it has 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?

The description is a single sentence that conveys the essential purpose without any fluff. It is front-loaded with the key information. Every word earns its place.

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

Completeness2/5

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

Given the tool has one parameter and an output schema exists, the description is still too minimal. It lacks usage guidelines, behavioral transparency, and any context about prerequisites or side effects. For an agent to use it correctly, more information is needed.

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 input schema has 0% description coverage, so the description must compensate. It adds that the 'sql' parameter must be a SELECT query, which is not indicated in the schema. However, it does not specify format, syntax rules, or restrictions (e.g., no DDL). This is minimal added value.

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 returns Oracle EXPLAIN PLAN output for a SELECT query. The verb 'Return' and resource 'Oracle EXPLAIN PLAN output' are specific. It distinguishes itself from sibling tools like 'run_select' (which executes the query) and 'top_sql' (which lists top SQL).

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 does not explicitly state when to use this tool versus alternatives. While it implies use for analyzing query execution plans without running the query, no when-not or alternative tools are mentioned. The guidance is adequate but not explicit.

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

list_schemasA

List schemas the MCP server is allowed to query.

Schemas are configured via MCP_SCHEMA_ALLOWLIST. This is a
metadata tool — no DB call required.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior4/5

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

Without annotations, the description carries the burden. It discloses that no DB call is required and that schemas are configured via an allowlist, which are key behavioral traits. However, it omits details like response format or permission requirements.

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 two sentences, front-loaded with purpose, and every sentence adds value: purpose, configuration context, and behavioral note. 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?

Given zero parameters and an output schema (not shown but exists), the description covers the tool's purpose, configuration source, and non-DB nature completely. No gaps remain.

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?

The tool has no parameters, and schema description coverage is 100% trivially. The baseline for 0 params is 4, and the description adds no param info since none exist.

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 explicitly states 'List schemas the MCP server is allowed to query' with a specific verb and resource. It distinguishes from siblings by noting it is a metadata tool requiring no DB call, which aligns with the sibling tools' focus on 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?

While the description implies this tool is for discovering allowed schemas before using database tools like describe_table or run_select, it does not explicitly state when to use or avoid it relative to siblings.

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

run_selectA

Run a SELECT or WITH query against Oracle.

Guardrails:
  - Only SELECT / WITH statements allowed
  - DDL, DML, PL/SQL blocks, DBMS_/UTL_/SYS. calls are rejected
  - Result row count is capped (see MCP_MAX_ROWS)
  - PII-named columns (SSN, SALARY, PASSWORD, …) are auto-redacted
  - Server-side statement timeout enforced

Returns a list of column-name dicts.

ParametersJSON Schema

Name	Required	Description	Default
`sql`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior4/5

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

With no annotations, description fully carries the burden. Discloses restrictions (statement type, row cap, PII redaction, timeout) and return format. 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?

Front-loaded with purpose, uses bullet points for guardrails. Some redundancy but overall efficient for the information conveyed.

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?

Covers purpose, guardrails, and basic return format. With output schema present, return details are adequate. However, lacks info on error handling or pagination behavior.

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

Parameters2/5

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

Single parameter 'sql' has 0% schema description coverage. Description adds no extra meaning or constraints beyond the schema's type definition. No examples or format guidance.

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 'Run a SELECT or WITH query against Oracle' with specific verb and resource. Distinct from siblings like describe_table, explain_plan, etc.

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 guardrails (only SELECT/WITH, rejects other types, row cap, PII redaction) that implicitly guide when to use. Lacks explicit alternatives but the guardrails sufficiently clarify scope.

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

top_sqlA

Top SQL by elapsed time from v$sql within the last N minutes.

Useful for "what's been slow recently?" investigations from Claude Desktop.

ParametersJSON Schema

Name	Required	Description	Default
`window_minutes`	No
`limit`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It reveals the tool queries v$sql but does not disclose potential performance impact, required privileges, or return format (e.g., SQL text truncation). Minimal behavioral details beyond the core function.

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, front-loaded with purpose and a clear usage hint. No redundant information.

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?

For a simple tool with 2 parameters and an output schema, the description is minimally adequate. However, it lacks parameter explanations and behavioral context (e.g., whether results are sorted by elapsed time descending). The presence of an output schema partially compensates, but gaps remain.

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

Parameters2/5

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

Schema description coverage is 0%, and the description does not explain the two parameters (window_minutes, limit). The text only vaguely references 'N minutes' without mapping to the parameter. No additional meaning beyond parameter names and defaults.

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 action ('Top SQL by elapsed time'), the source ('v$sql'), and the temporal scope ('within the last N minutes'). It also provides a specific use case ('what's been slow recently?'), distinguishing it from sibling tools like run_select or explain_plan.

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 mentions the tool is useful for investigating recent slow queries, providing clear context. However, it does not list when to avoid using it or explicitly name alternative tools for other 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.

5 tool updatesv0.1.0May 13, 2026
- First observeddescribe_table
- First observedexplain_plan
- First observedlist_schemas
- First observedrun_select
- First observedtop_sql

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/5.0

Scored 2026-05-13 01:45 across 5 tools

Disambiguation5/5

Each tool has a distinct purpose: listing schemas, describing table columns, executing arbitrary SELECT queries, explaining query plans, and showing top SQL by elapsed time. No overlaps.

Naming Consistency5/5

All tool names follow a consistent lowercase snake_case verb_noun pattern (describe_table, explain_plan, list_schemas, run_select, top_sql).

Tool Count5/5

5 tools is well-scoped for an Oracle DBA assistant covering metadata, query execution, performance analysis, and plan analysis.

Completeness4/5

Covers core DBA query workflow: schema discovery, table structure, arbitrary queries, explain plans, and top SQL. Missing list tables in a schema but that can be done via run_select.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

DB Query Guard MCP
com.clauxel.dbqueryguard
Paid remote MCP for governed database query review, SQL simulation, approvals, and audits.
Databases Security
2
The Quiet Protocol Growth Offense MCP A
com.thequietprotocol.www
Read-only MCP server for The Quiet Protocol's engines, benchmarks, proof, and business data.
Databases Research & Data Finance
292
Word Of Clout ACN MCP Server
io.github.wordofclout
Guarded MCP server for agent-readable business truth, provenance, readiness, and discovery.
CRM Customer Data Platforms
2
thoughtsOAuth
ai.thoughtbox.api
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
Cloud Storage Finance
2

Related MCP Servers

MCP Oracle Server
Databases Developer Tools
YrsonHTM
A
license
B
quality
D
maintenance
Enables interaction with Oracle databases through MCP by executing SELECT queries, describing table structures, and listing available tables with secure, read-only access.
Updated a year ago (2025-06-17 18:17 UTC)
3
7 npm
2
MIT
mcp-sqlserver-readonly
Databases Developer Tools
gbfeliped
A
license
Not graded
quality
D
maintenance
Read-only SQL Server MCP server enabling safe database queries, table listing, and schema inspection with built-in security protections.
Updated 3 months ago (2026-06-18 13:49 UTC)
MIT
Oracle Read-Only MCP Server
Databases Developer Tools
pos123
F
license
Not graded
quality
C
maintenance
A read-only MCP server for Oracle databases that enables SQL queries, schema inspection, and data sampling without requiring OCI client libraries. It supports both TNS alias and direct connection modes with robust security guardrails.
Updated 2 months ago (2026-07-12 08:08 UTC)
-
Oracle MCP Server
Databases Developer Tools
AlexandruDodita
F
license
Not graded
quality
C
maintenance
A read-only MCP server for exploring and querying Oracle schemas safely. Provides tools for table listing, schema description, column search, and validated SELECT execution.
Updated 2 months ago (2026-07-13 13:48 UTC)
2
-