MCP servers can safely expose legacy SQL systems to AI clients using schema controls, masking, and read-only tools without driver rewrites. Read now.
Why legacy SQL systems need a controlled AI boundary
Many organizations still run critical data on proprietary or aging SQL platforms. Those systems often work well for reporting and operations, but they were never designed as free-form query surfaces for large language models. Giving an AI client a raw database connection creates real risk: overly broad schema access, accidental writes, leakage of sensitive columns, and unpredictable load from poorly shaped queries.
An MCP (Model Context Protocol) server sits between the AI client and the database as a deliberate boundary. Instead of teaching every model how to speak a vendor-specific driver, you expose a small set of tools the model can call—list tables, describe columns, run approved queries—and enforce policy on every call. The database stays on its existing drivers and connection paths; the server owns safety, not the model.
Schema controls: expose only what the agent should see
Start with a allowlist of catalogs, schemas, and tables. Hide staging tables, internal audit stores, and anything that has no business being in an AI workflow. Within allowed tables, publish a curated view of columns: names, types, and short descriptions that help the model write correct SQL without dumping the full information schema into the prompt.
Schema controls also set the vocabulary the agent uses. If your operational names are cryptic, map them to clearer labels in the tool responses while still returning the real identifiers the query engine needs. That reduces hallucinated table names and keeps the model from inventing joins against objects it was never meant to touch.
Masking and read-only tools as the default safety stack
Read-only is the baseline. Tools should run under a database role that cannot insert, update, delete, or alter schema. Prefer parameterized queries or a constrained query builder over open-ended string execution when your use case allows it. When free-form SQL is required, validate statements server-side: reject multi-statement batches, DDL, and any keyword patterns that imply mutation.
Column masking belongs in the MCP layer or in database views the server is forced to use. Mask identifiers, financial fields, and free-text that may hold secrets before results leave the server. Combine that with row limits, timeouts, and maximum result sizes so a single agent turn cannot scan an entire warehouse or stream unbounded payloads back into the model context.
- Allowlist schemas and tables; deny by default
- Serve column metadata that is accurate but intentionally incomplete for sensitive fields
- Mask or redact at response time, not only in the model’s instructions
- Cap rows, runtime, and concurrency per tool call
- Log tool inputs and outcomes for audit without storing full row payloads when policy forbids it
Ship value without rewriting drivers
A practical MCP SQL server reuses the connection stack you already trust: the same libraries, pool settings, TLS configuration, and credential rotation you use for internal services. The new work is the tool contract and the policy engine—not a second path into the database. That keeps operational ownership clear: DBAs still own access and capacity; platform teams own which tools exist and how results are shaped for AI clients.
Design tools around real jobs, not generic “run any SQL.” Common patterns include schema discovery, sample rows under strict limits, metric lookups behind fixed templates, and explain plans that never return full result sets. When something fails—permission denied, timeout, invalid identifier—return structured errors the model can act on. The result is a path for AI assistants to work with proprietary SQL systems safely: schema controls, masking, and read-only tools, without rewriting the database layer.