Writing ·
What "the agent cannot compose SQL" means on a real schema
“The agent cannot write SQL” is the sort of claim that sounds like marketing, and it is usually heard as a bigger promise than it is. Here at MCP DB Wizard we’ve gone to considerable lengths to make it happen. Below we explain what we’ve done.
The MCP Server Cannot Write SQL, because we don’t expose a SQL prompt
There is no tool that takes a SQL string. That is the whole mechanism, and everything below follows from it.
An agent calls order_summary with a customer number. The number is a bind value, and a bind
value is data no matter how it is phrased — there is no spelling of a customer ID that becomes a
UNION, a DROP, or a second statement. Not because something inspected it and approved it, but
because nothing on that path ever parses it as SQL. And if whoever created the config file didn’t want
order_summary to be accessible, then not only is it not accessible but the running code has no means
to call it.
From the perspective of the agent there is no tool, no method and no class in the generated server. The
agent cannot reach PAYROLL.SALARY by being clever about it, because there is no name to say. It is
absent from the binary, not refused at runtime.
Why this matters more on a real schema
On a tidy schema, “the agent cannot compose SQL” sounds like a restriction you are accepting.
On a real one it is the opposite. A schema with three decades of history has columns that mean
something other than their names, a STATUS that is authoritative in one table and stale in another,
and joins that are only correct if you know which rows to exclude. That knowledge is not in the
schema, so
no amount of reading the schema recovers it.
An agent composing SQL against that has to reconstruct your business from column names. An agent
calling revenue_by_region does not, because somebody who knew about the intra-company transfers
wrote it once, years ago, and it has been right ever since.
The restriction is intentional, and if you cannot write SQL you cannot write the wrong SQL. It stops the model attempting something it was not envisaged doing.
The limitations of what we have done.
It can call the wrong tool. A finite list is a small list, not a correct one. We can’t guarantee tools will be called in the correct order, for example. Wrapping them into a single PL/SQL procedure might help in that case.
It can call the right tool with wrong arguments. On a real schema that surface is wider than a number: parameters can be records, collections and ref cursors, and a model that fills a record’s fields plausibly rather than correctly produces a call that succeeds and means something else.
It can chain correct calls into a wrong conclusion. Every step valid, the summary wrong.
It cannot rescue a statement that was wrong when you wrote it. Curation moves the authorship of the SQL from the model to your team. It does not audit your team.
So the claim is narrow. It removes an entire category of failure — the invented query — and leaves the ordinary ones, which is why the audit trail still matters.
The claim is checkable, so check it
You do not have to take anyone’s word for this, including ours. Ask the server for its tool list and read it. Every tool has a name, a description and a typed parameter schema.
If one of them accepts a free-text string that reaches the database, the claim is false for that deployment, whatever the marketing says. If none does, you are looking at the whole surface — and the list is short enough to read in a meeting.
How do I get MCP DB Wizard?
It’s available from our GitHub repo as a Docker image, and the quickstart will get you a running server against your own schema.