Writing ·
How to limit which Oracle objects an AI agent can reach
An agent handed unlimited access to a two-hundred-table schema chooses badly. That is the first reason to limit the MCP tools it gets against your database, and the one said out loud least often. Most of the case for a short tool list is a security case, and we have made that one elsewhere.
An unlimited schema is a recipe for confusion
Almost all agents will have been written for specific use cases. Handing each use case full schema access (even if it is read-only…) does nothing to help it find the handful of objects that use case needs. For a large schema this could easily be hundreds of tables, representing decades of work, or possibly ‘technical debt’. If you hired an intern and asked them to implement your use case using an unlimited schema, would you seriously expect them to succeed? Of course not! So why do you assume an agent will, unless you limit the MCP tools available in the database?
MCP DB Wizard is designed from scratch to limit the tools available to an agent.
Start from the use case, not the schema
The instinct is to walk the schema and tick what looks useful. Instead you should look at real world session histories. What did they do, in what sequence, to implement a use case?
You’ll probably find that there will be a bunch of non-trivial SQL, some PL/SQL calls, and finally a table CRUD operation (maybe).
What you therefore need to do is create a situation where your agent has these tools, and only these tools to hand.
Prefer PL/SQL to SQL, and SQL to table level CRUD operations
If you are going to limit MCP tools access to the database, there is a clear hierarchy of what you should provide:
-
PL/SQL allows a lot of complexity to be handled by trained DBAs, and a complex problem to be reduced to an API call. While an agent can still call the wrong procedure with the wrong parameters, there is a limit to how much damage it can do.
-
Handwritten SQL statements are the backbone of real-world production systems. They allow DBAs or developers to manage the eccentricity and inherent complexity of the real world application. They frequently represent years of accumulated know-how and business knowledge.
-
Finally, direct CRUD operations are useful, but the first two options should be used to avoid scenarios where complex updates or inserts are expected in the use case, as you are giving your agent an opportunity to use its imagination and come up with new and exciting ways to corrupt your data.
Many small configs beat one large one
With MCP DB Wizard you create a config file for each use case.
The config is the boundary. An object that is not in it has no tool, no method and no class in the generated server: it is not refused at request time, it is absent from the binary.
Which means a role is not a runtime permission here. It is a separate config. The reporting agent and the operations agent get their own files, each naming only what that job needs, and neither can reach the other’s objects because the code to do it was never written. (An Oracle role is a different thing, on the other side of the connection — that belongs to the account the server logs in as.)
Two files are also easier to review than one file with a section you skim. The longer version of that argument — and why database roles are necessary but cannot tell an agent when to use a tool — is in role-based access for an MCP server.
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.