Skip to main content
Glama
srmadscience

MCP DB Wizard

MCPDBWizard

An MCP server for Oracle, built from the objects you choose. Tick the PL/SQL packages, tables, sequences and your own tested SQL statements in a console, and it generates a Model Context Protocol server exposing exactly those to an AI agent as typed tools — each carrying a JSON Schema derived from the procedure's real signature.

There is no run-sql tool. Anything you did not select has no tool, no method and no class: it is absent from the binary rather than refused at run time. Nothing composes a query at run time either — the generated code is ordinary Java with fixed SQL statements and typed binds, and the MCP server calls those wrappers rather than writing SQL for a model to run.

Generating that server means generating the whole calling layer, so you get it too: typed DAO factories, callable-statement wrappers, table managers and an optional SOAP layer. They are useful on their own, but the MCP server is the point.

Supports Oracle 12c through 26ai, and is regression-tested against six live instances spanning that range.

Listed on mcpservers.org

How MCPDBWizard works: at design time, objects selected against Oracle's data dictionary are saved as a config file and Java is generated for those objects only; at run time an MCP client calls a proxy that checks token, grant and rate limit, then forwards to the generated MCP server, which binds the arguments and calls Oracle.

How the full product fits together. This repository is the generator — the config file, generate & compile, and the generated MCP server. The Design pages, Runtime page and proxy are the web console in the Docker image; here you select objects with the Swing tool or a config file instead, and the generated server can be run on its own.


The part that is hard

The usual way round is to hand the agent a run-sql tool, and it works until the schema is real: published text‑to‑SQL accuracy falls sharply on enterprise‑scale schemas compared with tidy benchmarks, and a wrong UPDATE is not a wrong answer, it is an incident.

The alternative is curated tools — but writing one per procedure by hand does not scale past a few, and PL/SQL is unusually hostile to deriving them automatically:

  • a procedure can have any number of OUT and IN OUT parameters, not a single return value

  • parameters can be records (including records nested inside records), collections, %ROWTYPEs, REF CURSORs, package types, and overloads

  • Oracle's own data dictionary describes these differently between versions

This project does that derivation. Every generated MCP tool carries a real JSON Schema built from the procedure's actual signature, so the agent is told what the parameters are rather than inferring them from prose.

oracle:  PROCEDURE order_summary(p_customer IN  NUMBER,
                                 p_totals   OUT summary_rec,
                                 p_lines    OUT SYS_REFCURSOR)

tool:    order_summary { "p_customer": <number> }
      -> { "p_totals": { "orderCount": 12, "value": 4210.55 },
           "p_lines":  [ { "sku": "AB-1", "qty": 3 }, ... ] }

A record crosses as a JSON object, a REF CURSOR as an array of row objects, a DATE as an ISO‑8601 string, RAW and binary vectors as base64, CLOB as text, BLOB as base64.


Related MCP server: Mini Oracle MCP Server

Quick start

Requires Java 21 and Maven. The Oracle JDBC driver (com.oracle.database.jdbc:ojdbc11) comes from Maven Central — nothing to install by hand.

mvn clean package

That produces two jars in target/: a plain one, and a self‑contained mcpdbwizard-app-<version>-shaded.jar with the driver bundled.

# Interactive (Swing) -- pick objects and options, save a config
java -jar target/mcpdbwizard-app-*-shaded.jar <log_dir> myconfig.pb2

# Batch -- regenerate from a saved config
java -jar target/mcpdbwizard-app-*-shaded.jar <log_dir> build myconfig.pb2

<log_dir> is created if missing.

Changed in 2026-08: there used to be a leading <access_code> argument. It has been removed, and a command line that still passes one will be read as the log directory. It was validated for shape only — ≥19 characters, not a path, not the literal build — and then ignored, so it authenticated nothing. Drop it from any script that supplies it.

Configs are .pb2 (a flat properties file) or .json; both are accepted, and convert losslessly either way:

java -cp target/mcpdbwizard-app-*-shaded.jar \
     com.mcpdbwizard.schema.ConfigConverter myconfig.pb2 myconfig.json

What gets generated

DAO factory

one entry point per config, wiring connections and logging

PL/SQL wrappers

a class per procedure/function — setParamX, executeProc, getParamY

Table managers

row CRUD by primary key, plus unique‑key, index and foreign‑key‑child lookups

SQL statement classes

your own SQL, with typed bind parameters

SOAP service layer

optional

JSON / JSON‑RPC connectors

optional

MCP server

optional (needs Java 17+ for the MCP SDK)

Generated code depends only on com.mcpdbwizard.pub, the runtime library in this repository.

The MCP server

A single generated <Factory>McpServer.java, speaking stdio by default or Streamable HTTP when started with http [port]. Optional bearer‑token auth and TLS both read their secrets from the environment at run time and fail closed if unset, so no secret is baked into the generated source.

It exposes PL/SQL routines, table row CRUD and secondary lookups, user SQL statements, sequences, and — on 23ai — JSON‑relational duality views with document CRUD and etag optimistic locking.

What is exposed is decided when you generate, not at run time. An object you did not select has no code generated for it at all, and TABLE_MCP_CRUD_<i> narrows a table to any subset of create/read/update/delete. An operation that is not exposed has no tool method emitted — it is absent from the binary, not merely unregistered.


Oracle datatype support

Beyond the ordinary scalars and LOBs: 12c identity columns and extended VARCHAR2/RAW; 21c native JSON; 23ai native BOOLEAN, VECTOR (dense, binary and sparse), and JSON‑relational duality views.

Known gaps: TIMESTAMP WITH [LOCAL] TIME ZONE and BFILE cross as procedure parameters but not yet as table columns; SDO_GEOMETRY has no JSON mapping, so a routine using one is skipped; FLOAT16 vectors are blocked server‑side.


Logging

Generated factories pick a LogInterface implementation from the config: console, text file, java.util.logging, Log4j 1.x, SLF4J, or Log4j 2. The SLF4J and Log4j 2 backends live in com.mcpdbwizard.pub and depend only on the facade jar, which is an optional dependency — supply the api plus a binding yourself if you use them.


Tests

The database‑free suite needs nothing and is green on a fresh clone:

mvn test

Tests that need Oracle are gated: with no database reachable they skip rather than fail. To point them at your own instance, copy the templates — the real files are gitignored and never leave your machine:

cp src/test/resources/test-boxes.properties.template src/test/resources/test-boxes.properties
cp Scripts/tns/tnsnames.ora.template                 Scripts/tns/tnsnames.ora
cp Scripts/boxes.env.template                        Scripts/boxes.env

Per setting, an environment variable (MCPDBWIZARD_TEST_HOST, …) always wins over the file, which is how a run selects one server over another.

A third tier links against generator output: Scripts/testrun_current.sh regenerates code from a set of configs and compiles it, and a family of harnesses then drives that code against a live database.

That tier is not part of this repository, and neither are the schemas it needs. The configs introspect Oracle schemas whose structure is not ours to publish — some of it came from customer work years ago — and a config enumerates the schema it points at, so the configs cannot ship either. The harnesses go with them: they name those schemas' tables and routines, and they only compile against a regenerated tree that cannot exist here.

What that costs you: nothing to run the generator, and nothing to run the suite. The database-free tests are complete and green on a fresh clone; the gated live tests skip. What you do not get is a ready-made corpus to regenerate against. Scripts/check_provisioning.sh stays, and will name the exact objects a config expects, which is the place to start if you build your own.

examples/generated-output/ shows what the generator emits, with no database at all.


Repository layout

Path

What

src/main/java/com/mcpdbwizard/pub

runtime library the generated code links against

src/main/java/com/mcpdbwizard/app

the generator — engine, Swing UI, shared helpers

src/main/java/com/mcpdbwizard/schema

typed model of a config; .pb2 ↔ .json

src/main/java/com/mcpdbwizard/mcpdbwizardconnector

JSON / JSON‑RPC connector generator

examples/generated-output

a checked‑in example of generator output, regenerated 2026‑08‑07

Scripts/

regeneration, provisioning checks, and the export gate

API docs

generated javadoc for com.mcpdbwizard.pub, the library you link against

Contributor notes — architecture, conventions and accumulated gotchas — are in CLAUDE.md.


API documentation

API docs for com.mcpdbwizard.pub

That is the runtime library generated code links against, and the only package documented — the generator's own internals are implementation, and publishing them would bury the part you call. The package summary explains what to reach for, and carries the compatibility contract: signatures there are load-bearing for every program this generator has produced, so they gain methods and do not change them.

The same pages are on the project site at mcpdbwizard.com/javadoc. Both are regenerated from source on publish rather than copied from one another.

Locally, mvn javadoc:javadoc writes them to target/reports/apidocs/. It runs with failOnWarnings, so a broken @link fails the build rather than shipping a dead cross-reference.


Known issues

Known issues — what is wrong, what a caller actually sees when it bites, and the workaround for each. Most of them do not announce themselves: a record whose JSON keys are the generated field names rather than the column names, a VECTOR routine parameter that takes a dense array only, a config whose tool count outgrows Oracle's open_cursors.

Every open entry there is also an issue in this repository, linked from the page. Read it before filing — and if one of them is biting you, say so on its issue rather than opening a new one. Three of those entries are documented rather than fixed because nobody has asked, so a comment is the whole difference between "nobody has ever needed this" and "somebody does".


Contributing

See CONTRIBUTING.md. One thing to run before opening a pull request:

Scripts/export/check-export-clean.sh

It fails if a private hostname, a credential or a jar has crept into the tree.

Licence

Apache License 2.0 — see LICENSE and NOTICE.

Code this generator emits is your own work and carries no licence obligation from this project. It links at run time against com.mcpdbwizard.pub, which is in this repository and likewise Apache‑2.0, so you can ship generated applications under whatever terms you like.

Available Tools

1 tool
select_from_dualA

Returns a single row with one column, DUMMY. This server has NO DATABASE CONNECTION: the value is a fixed message saying so, not a query result, and no SQL is executed. The tool exists to prove that an MCP client can reach this server before Oracle is configured.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.9/5.0
Behavior5/5

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

With no annotations, the description carries the full burden. It discloses that no database connection exists, no SQL is executed, and the return value is a fixed message. This is complete transparency about the tool's non-query behavior and its test nature.

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 with no wasted words. The core behavior is front-loaded ('Returns a single row...'), followed by the critical caveat and the tool's purpose. Every sentence earns its place.

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?

For a parameterless tool with no output schema and no siblings, this description is fully complete. It explains what the tool does, why it exists, and what the output is. Nothing an agent needs to call it correctly is 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?

The tool has zero parameters, so the description does not need to explain parameter semantics. The schema has 100% coverage of an empty property set, and the description adds useful context about the fixed output value, which satisfies the baseline for parameterless tools.

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 a specific verb and resource: 'Returns a single row with one column, DUMMY.' It also clarifies this is a fixed message, not a query result, making the purpose unmistakable. With no siblings, no further differentiation is needed.

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?

The description explicitly states when to use the tool: 'The tool exists to prove that an MCP client can reach this server before Oracle is configured.' This is a clear usage context. There are no alternatives to compare against, so no exclusions are required.

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.

  1. 1 tool updatev2.0.29
    • First observedselect_from_dual

TDQS

A4.3/5.0

Scored across 1 tool

Disambiguation5/5

Only one tool exists, so there is no possibility of confusing it with another. The description clearly states its purpose as a connectivity check.

Naming Consistency5/5

With a single tool, the naming pattern is trivially consistent. The name 'select_from_dual' follows a verb_preposition_noun convention, though it may mislead about actual behavior.

Tool Count1/5

The server is named 'MCP DB Wizard' but exposes only one trivial tool that does not perform any database operation. This is an extreme mismatch between scope and count.

Completeness1/5

The tool only returns a fixed message and executes no SQL. For a server implying database wizardry, the surface is severely incomplete, covering only a placeholder health check.

Maintenance

ActivityActive
ResponsivenessResponsive

Related MCP Connectors

Related MCP Servers

  • A
    license
    B
    quality
    C
    maintenance
    MCP server for accessing Oracle databases, enabling schema exploration, query execution, and performance analysis.
    12
    MIT
  • F
    license
    Not graded
    quality
    D
    maintenance
    Local MCP server for Roo Code that connects to Oracle DB and returns limited set of metadata through secure MCP tools.
    -
  • F
    license
    Not graded
    quality
    C
    maintenance
    Read-only MCP server that lets coding AI agents inspect Oracle Database schema through live metadata.
    -