Writing ·
An MCP server with no run-sql tool: what that actually changes
Take the run-sql tool out of your MCP server and your life becomes a lot simpler, the system a lot
safer, and the risks a lot lower. Below we explain why.
Giving an agent a run-sql tool is putting the abstraction in the wrong place.
All modern software relies on layers and layers of abstraction. There is no such thing as ‘the cloud’. It’s just hardware and software in a warehouse somewhere. Entire languages, such as Java, are based on the premise that they run on an abstract, near-magical computer chip, because it turns out that makes life easier for almost everyone.
From a database access perspective this leads us into a trap. The easiest form of abstraction to
expose is the SQL layer, with a run-sql tool, which is what almost every database MCP server does.
It’s also a case of ludicrous overkill.
Agent database access needs to pass the ‘intern test’…
You wouldn’t give an intern a SQL manual, a live connection to production, some vague instructions about what you want done, and then go on vacation. But that’s how most database access via MCP servers works. It’s hedged with talk of ‘guardrails’, and UPPER CASE instructions, but it’s at best non-deterministic and at worst inherently unreliable.
Even (and this is a big ‘even’!) if you are 100% certain an end user will never try to induce, coerce, persuade, bribe, gaslight or offer a gift of a second-hand thesaurus in exchange for breaking the rules, you still have to consider that the agent will sooner or later do something unhelpful while trying to be helpful. This is like the ‘infinite number of monkeys with typewriters’ scenario, except the monkeys are agents and they are armed with SQL92 and unconstrained access to your data.
The bottom line is that SQL access is the wrong layer of abstraction.
So how do we get an MCP server without run-sql?
You need to limit the agent, and especially prevent it from using its imagination. Your agent will have an abstract awareness of millions of SQL statements that it saw while training. When it comes to SQL it has a toolbox of infinite size and depth, and no real clue what the tools do. So you need to do three things:
- Impose hard constraints on behaviour. Down to individual pre-approved SQL statements and PL/SQL procedure calls. The agent doesn’t write SQL. It uses tools which in turn use pre-approved SQL.
- Issue clear, tool level, instructions. The agent is given a finite list of tools, each of which has a clearly explained purpose.
- Audit everything, with an audit mechanism that doesn’t depend on the goodwill or diligence of the agent.
What this means, in practice, is you need to do non-trivial software engineering to make selected database objects and SQL appear as tools in an MCP server on a 1:1 basis.
We did this. We called it, with a stunning lack of originality, “MCP DB Wizard”.
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.