Writing ·
Curated MCP tools instead of a SQL prompt: a side-by-side
Why does MCP DB Wizard use curated MCP tools instead of a SQL prompt? We would argue it’s a vastly superior way of doing things, even if there is an extra administrative step involved. Let’s look at an example.
Our example question is “what did customer 4491 order last month?”. Ordinary, answerable, and not the kind of thing anyone worries about.
Asked through a SQL prompt
The agent is given a tool that accepts SQL. It reads whatever schema description it has, writes a
query against orders and order_lines, joins on what looks like the right column, filters on a
date, and sends the text to Oracle. Oracle runs it, because it is valid SQL from an account that may
run it.
Asked through curated tools, such as those provided by MCP DB Wizard
The agent is given sales_orders_by_customer_and_month, because somebody decided that question gets
asked. It supplies 4491 and 2026-08 as bind values. The SQL was written, tested and reviewed
before any of this, and it is the same SQL every time.
Both return an answer. Everything else — the whole case for curated MCP tools instead of a SQL prompt — is in what happens around that answer.
| SQL prompt | Curated tools | |
|---|---|---|
| Who wrote the SQL | the model, this time | your team, once |
| What reaches Oracle | text the model composed | bind values for a fixed statement |
| What you can review beforehand | the prompt and the guard rules | the exact statements, as a file |
| When it is wrong | a plausible answer, silently | a tool that does not exist, or an error |
| A question nobody anticipated | answered, maybe correctly | not answerable without a change |
| Time to the first answer | minutes | a curation session |
| The schema changes underneath | the model adapts, or invents | the statement breaks, visibly |
| What prompt injection can reach | anything the account can | only the tools that exist |
| A runaway query | whatever it composed | a tested statement, called far more often than you tested it — bound by a timeout |
| What the audit trail shows | SQL text, to be read and judged | which tool, which arguments |
| Proving what was possible | reasoning about a filter | reading a list |
The three places where the SQL prompt wins
Time to the first answer. Point it at a schema and ask. There is no curation session, no decision about which questions matter, no second config for the second team. For a one-off investigation against a copy of the data, that is the right tool and we would not pretend otherwise.
A question nobody anticipated. This is the real cost of curation, and it is not a small one. If the question is not in the config, the answer is “not until someone adds it” — and the person asking is usually in a hurry. A SQL prompt answers anything the schema can support, immediately.
Exploration, where being wrong is cheap. Working out what is in a database is a legitimate job, and one where a wrong query costs you a minute rather than a decision. Not every use of an agent is in front of production.
Why exposing a SQL prompt leads to wrong answers
Look again at when it is wrong.
A SQL prompt that gets the join wrong returns an answer. Not an error — an answer, delivered with the usual chirpy confidence, which somebody then puts in a report. It has escaped by then, and the harm it does propagates freely through your enterprise. The failure is silent, and it is silent precisely because the model did the thing you asked it to do: compose a query.
A curated tool that does not fit the question fails differently: either the tool for it does not exist, or the call errors. Both are loud. Neither hands anybody a wrong answer that looks right.
That asymmetry is really important, and it is why the other ten rows matter less than this one. A system that is usually right and silently wrong is harder to operate than one that is narrower and noisy about its edges. It is also why the guards people put in front of a SQL prompt do not close the gap: each one is a filter over an unbounded set of inputs, and this failure is not an input you could have filtered — it is valid SQL that answers the wrong question.
Where they meet
The honest middle is that most questions are not novel. Ask your DBA team which statements carry the traffic and you will get a list shorter than anyone expects — which is why curated statements are worth the session it takes to write them, and why a config for one job stays small.
For the rest, the answer is not a SQL prompt bolted onto the side. It is a second config, or a new statement added to an existing one and reviewed like any other change. Slower. Also the only version where somebody read the query before an agent ran it against your production schema.
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.