The problem with direct database access
AI agents need schema context, but raw database access creates avoidable risk.
A database user can often see more than an AI workflow needs. Direct SQL access also makes it harder to enforce business-domain boundaries, column permissions, and audit rules.
Database to MCP solves this by publishing approved scopes instead of exposing the raw database.
Schema tools are metadata-only
Schema tools help an AI client understand structure without returning row payloads.
- Published tables become schema metadata tools.
- Schema tools describe approved tables, columns, keys, relationships, permissions, and allowed operations.
- Schema tools do not return database rows.
- Executor tools are separate and run only after Gateway validation.
Every executor call is validated
The Gateway validates the request before SQL reaches PostgreSQL or SQL Server.
For database scopes, validation checks active scope state, owner-aware resolution, published tables, allowed columns, relationships, read-only policy, limits, and executor mode.
Cross-database, cross-schema, cross-scope, and cross-owner access is forbidden by Gateway validation.
Operational model
Database MCP traffic should be observable without exposing secrets.
Audit logs and test tools help teams inspect validation behavior and execution results. Connection strings, secrets, and sensitive request values should not be returned through public pages, LLM context, or log output.
Common questions
Do schema tools return sample rows?
No. Schema tools are metadata-only and do not return row payloads.
Can executor tools use hidden columns?
No. Executor tools can only use columns published and permitted in the current database scope.
Does an LLM enforce database security?
No. LLMs can propose a QueryPlan or SQL candidate, but the Gateway validates every executor request before execution.