Connection
Save the PostgreSQL or SQL Server connection in the Gateway. The stored connection string is protected and is not returned to the browser, LLM files, or MCP clients after save.
Database to MCP
Publish database surfaces as MCP tools
Connect PostgreSQL or SQL Server, create a safe MCP surface for one schema or business workflow, publish only approved tables and columns, then let AI clients use metadata-only schema tools and validated executors through the Gateway. Credentials stay server-side, and Gateway Chat lets you test the surface before external MCP clients use it.
No credit card required.
Database to MCPPostgreSQLSQL ServerMetadata-only schema toolsGateway Chat
app.swaggertomcp.com/databases/acme/scopes/support
Swagger to MCP
Database scope publishing
support_readonly
PostgreSQL · 4 tables · 28 columns
customers
9 columns · PII blocked
orders
8 columns · Read-only
tickets
7 columns · Scoped
Gateway validation
Scope, table, column, and read-only checks
Schema tool
metadata onlyQueryPlan
validatedExecutor
approved scopeRecent audit
query_support_scope · allowed columns only
schema_customers · returned metadata
Publishing model
A database is not exposed as one broad AI tool
The Gateway turns a database connection into smaller MCP surfaces. Each surface has its own URL key, published tables, column rules, execution mode, and audit trail.
MCP surface
Create an MCP surface for a database, schema, or business domain such as sales, finance, support, or inventory. The public MCP URL resolves to that account-bound surface.
Published tables and columns
Select the tables and columns the AI workflow may use. The same physical table can have different permissions in different MCP surfaces.
Agent-ready context
Give the model enough structure without giving it the database
A useful database agent needs table meaning, relationship context, and query rules. Database to MCP gives the model a structured catalog first, then validates every execution request in the Gateway.
Schema tools first
AI clients can inspect table names, column descriptions, keys, relationships, permissions, and allowed operations before they propose a query.
Descriptions and relationships
Add scope, table, column, and relationship descriptions so generated schema tools explain business meaning instead of only exposing raw database names.
Chat before client rollout
Use Gateway Chat to ask real questions, watch schema tools and executor tools being called, and confirm that the scope behaves correctly before configuring Claude, Cursor, or another MCP client.
Use cases
Give AI agents scoped database access
Use Database to MCP for reporting, internal operations, and approved analytics where AI needs current structured data without direct database credentials.
Operational reporting
Let assistants answer questions over approved sales, support, finance, or inventory scopes without crossing database or schema boundaries.
Internal analytics
Publish safe read-oriented scopes for teams that need natural language access to approved database domains, limits, and columns.
Mixed API and database workflows
Combine Database to MCP for governed context with OpenAPI to MCP for actions, so an agent can inspect data and then call the right business operation.
Runtime surface
What AI clients can see and call
The MCP catalog is intentionally smaller than the database. AI clients receive metadata and validated tools, not raw credentials or unrestricted SQL access.
| Surface | What AI sees | Gateway behavior |
|---|---|---|
| Schema tools | One schema tool per published table, with metadata for columns, permissions, keys, relationships, indexes, and allowed operations. | Schema tool calls never return table rows. They help the model understand the approved data shape before execution. |
| QueryPlan executor | validate_query_plan and execute_query_plan tools for structured, provider-independent query requests. | The Gateway validates scope, tables, aliases, joins, columns, aggregates, sorting, limits, and policy before generating provider-specific SQL. |
| SQL mode executor | validate_sql and execute_sql tools for advanced SQL plus parameter workflows when a scope is configured for SQL mode. | SQL mode is conservative: single-statement SELECT behavior, published-table boundaries, relationship-gated joins, column permissions, and limit policy are enforced. |
| Gateway Chat | Active database scopes appear as chat-callable MCP surfaces when they have published tables and a supported executor mode. | Chat uses schema tools for context, validates the plan or SQL candidate, then executes only through the same Gateway MCP path external clients use. |
| Audit logs | Execution metadata such as mode, action, success or error, duration, row count, truncation, and validation errors. | Connection strings, provider secrets, and sensitive request values stay out of stored logs; request details are redacted before persistence. |
Hard boundaries
What the database flow does not expose
Database to MCP is useful because the Gateway keeps model context, execution, credentials, and audit controls separated.
No client-side database credentials
MCP clients authenticate to the Gateway. They do not receive the database connection string, and stored connection strings are not returned after save.
No rows from schema tools
Schema tools describe the approved data model. Data rows can only be returned by validated executor tools, never by metadata inspection.
No unpublished columns
Hidden, sensitive, or unpublished columns are blocked by scope-based permission checks before execution. The same column can be allowed in one scope and restricted in another.
No cross-scope access
Cross-database, cross-schema, cross-scope, and cross-owner access is rejected. The `/mcp/{scopeKey}` resolver is owner-aware.
No model-as-security-boundary
Semantic Kernel or an LLM may propose a QueryPlan or SQL candidate, but validation, permissions, SQL safety checks, redaction, and audit logging happen in the Gateway.
Workflow
From source to MCP endpoint
The Gateway keeps source discovery, publishing, execution, and monitoring separated so the AI-facing surface stays controlled.
Step 1
Connect and discover metadata
Connect PostgreSQL or SQL Server and run metadata discovery for schemas, tables, columns, keys, relationships, and indexes. Discovery does not read sample rows.
Step 2
Create a database surface
Choose a surface key for a database, schema, or business domain. This becomes the account-bound MCP surface exposed at `/mcp/{surfaceKey}`.
Step 3
Publish tables and tune columns
Publish the tables the AI workflow may use, add helpful table and column descriptions, and set visibility, filtering, sorting, grouping, and aggregation permissions.
Step 4
Select QueryPlan or SQL mode
Use QueryPlan as the recommended default. Use SQL mode only for advanced scopes that need SQL candidates and can accept stricter SQL validation.
Step 5
Test in chat and review logs
Ask real questions in Gateway Chat, confirm the model uses schema tools and the executor correctly, then inspect validation results, latency, row counts, and redacted audit logs.
FAQ
Common questions
Short answers for teams comparing MCP adapters, API gateways, and database access for AI agents.
Is Database to MCP the same as giving an AI agent database credentials?
No. The database connection stays in the Gateway. MCP clients see a published scope with schema tools and validated executor tools, not the raw connection string or a direct database login.
What is a database scope?
A database scope is the MCP surface for a database, schema, or business domain. For example, a large ERP database can be split into erp-sales, erp-finance, and erp-inventory scopes with different tables and column permissions.
Do schema tools return database rows?
No. Schema tools are metadata-only. They describe tables, columns, keys, relationships, permissions, and allowed operations without returning data row payloads.
When can data rows be returned?
Rows can be returned only by validated executor tools such as execute_query_plan or execute_sql. The executor must pass Gateway validation for scope, tables, columns, relationships, limits, and policy before it runs.
What is QueryPlan mode?
QueryPlan mode is the recommended database executor mode. The client submits a structured plan, the Gateway validates the plan, then generates PostgreSQL or SQL Server SQL for the approved scope.
How is SQL mode different from QueryPlan mode?
QueryPlan mode uses a structured request that is easier to validate conservatively. SQL mode accepts SQL candidates for advanced use cases, but it is still validated before execution and is not published together with QueryPlan mode for the same scope.
Can QueryPlan and SQL executor tools be published together?
No. One scope publishes either QueryPlan mode or SQL mode executor tools, never both at the same time. Schema tools appear in both modes.
Can Gateway Chat query a database scope?
Yes. Published database scopes can be selected in Gateway Chat when the scope is active, has published tables, and uses a supported executor mode. Chat uses schema tools for context and follows Gateway validation before execution.
How are sensitive columns blocked?
Published database scopes include column-level permissions. Executor tools can only use columns allowed in the current scope, and sensitive, hidden, or unpublished columns are blocked by Gateway validation.
Can a query cross schemas, databases, scopes, or owners?
No. Cross-database, cross-schema, cross-scope, and cross-owner access is forbidden by Gateway validation. Executor tools stay inside the published scope and its approved tables, columns, and relationships.
Does Database to MCP support arbitrary write queries?
No. The current database flow is designed for governed, read-oriented access. SQL mode is conservative and validates single-statement SELECT queries by default; QueryPlan execution also follows scope, column, relationship, limit, and read-only policy.
Which databases are supported?
Database to MCP supports PostgreSQL and SQL Server scopes. The Gateway keeps provider behavior explicit so validation and SQL generation can remain conservative.
Is the database connection string shown after save?
No. Connection strings are protected by the Gateway and are not returned after save. Public docs, LLM-readable files, and logs must not expose connection string values.