Writing  ·  22 September 2026

SQLcl MCP server alternatives for teams that cannot allow ad-hoc SQL

We have a fair comparison of SQLcl’s MCP server elsewhere, and its conclusion is “use both”. This page is for the reader who cannot.

Not because they disagree with it. Because somebody else already decided, and that decision arrived from outside engineering.

“We cannot allow ad-hoc SQL” is a constraint, not an opinion

It usually turns up in one of four ways, and none of them is an argument you can win by explaining that the account is read-only.

• A security review. Someone has to sign off the integration, and their question is what this thing is able to do, not what it is expected to do.
• An auditor or a regulator. The control being tested is that access is limited to defined operations. “The model decides” is the finding, not the mitigation.
• A customer contract. You process somebody else’s data and you have told them, in writing, what touches it.
• An incident. Something already went wrong, possibly not even involving an agent, and ad-hoc access is on a list now.

The distinguishing feature of all four is that the person applying the constraint is not going to evaluate your tool. They have set a boundary, and your job is to pick something that fits inside it. That changes what you are shopping for.

Why the usual answers do not clear the bar

Each of these is a reasonable engineering response, and each one fails for the same reason.

A read-only database account. The obvious move, and it genuinely removes a category of risk — what people mean by a read-only MCP server covers what it does and does not buy. But asked “what can this do to our data?”, the answer is “anything that account can read”, which is a description of a boundary rather than a list of operations. Reviewers do not accept descriptions.

Instructions in the prompt. Not a control. You cannot evidence it, and the six places a restriction can live piece is about which of them survive contact with someone who wants proof.

A statement allow-list in front of the database. Closer, and for some teams this is the answer. The question to ask is where the list lives, who can change it, and whether changing it requires a code review or a config reload nobody sees.

What to evaluate instead

Once ad-hoc SQL is off the table, the useful criteria are not about model quality at all. Six questions, in the order a reviewer will ask them.

1. Can you produce the list? Not a policy describing what the agent should do — an actual enumeration of every operation it can perform. If producing it requires reading source code or reasoning about grants, you do not have one.
2. Is the list reviewable before deployment? It should be a file that a human reads, a reviewer approves and version control diffs.
3. Does an operation you did not authorise exist at all? There is a real difference between a capability that is disabled and one that was never built. The first is a configuration away from being enabled; the second has to be written first.
4. What does it record? When the question becomes “what did it actually do on the fourteenth”, you want values, not a count of calls.
5. What account does it connect as, and does that answer survive the reviewer’s follow-up? This is its own subject — see least privilege for an Oracle MCP server.
6. Which Oracle versions does it actually support? Not which ones it claims. Dictionary behaviour differs sharply across releases, and a tool that introspects your schema can silently produce less on one version than another.

The three shapes that clear it

SQLcl with a heavily restricted account. Still worth considering, and for a small internal team it may be enough. It clears questions 4 and 5 and struggles with 1, 2 and 3, because the boundary is expressed as grants rather than as an enumeration. If your reviewer accepts a privilege model as the control, this is the cheapest thing on the list and it is already installed.

An MCP server you write yourself. This works, and we are not going to pretend otherwise — we have written about why you might. You expose exactly the operations you choose, so questions 1 to 3 answer themselves. The cost is every one of them is hand-maintained: each procedure’s parameters, each type that crosses the JSON boundary, each schema change. For five procedures that is an afternoon. For two hundred it is a project with an owner.

A generated server. You curate a list of procedures, tables, operations and SQL statements you wrote and tested; the tools are generated from it. The list is the security model, and it is also the reviewable artefact question 2 asks for. An operation you did not tick is not disabled — no method and no class exist for it, which is what question 3 is really getting at.

That last one is us, and the reason we exist is question 1. The list is not a report we generate about the server. The list is the server.

What you give up, and how to get it back

Exploration. Genuinely. Nothing in this shape lets somebody ask an unanticipated question of the database and get an answer in ten seconds, and anyone who tells you their curated tool set covers every future question has not maintained one.

The answer is the one from the comparison article, unchanged: SQLcl MCP stays on developer laptops, where a person is watching, using their own credentials, on data they could already reach. The constraint you are working to is almost never “nobody may run SQL” — it is “the unattended thing may not run SQL”. Those are different sentences and only one of them is on the auditor’s list.

If you want to check which one you currently have, your database already knows: detecting ad-hoc SQL in Oracle is two queries against Oracle’s own views, and it works against any MCP server, including ours.

How do I get MCP DB Wizard?

It’s available from our GitHub repo as a Docker image. It supports Oracle 12c through 26ai, and is regression-tested against six live instances spanning that range.