One governed MCP surface
Expose PostgreSQL without handing the model an unrestricted database connection.
PostgreSQL · MCP
PostgreSQL MCP Server for AI agents.
Connect AI clients to PostgreSQL through hs-sql-agent's MCP surface, typed SQL compiler, access policy, Safe DML workflow, and audit boundary.
Dialect-aware compiler
Keep PostgreSQL-specific SQL semantics inside an explicit source/target capability boundary.
Policy before execution
Apply database scope, table policy, tool restrictions, rate limits, Safe DML, and audit before commit.
PostgreSQL stays behind a compiler boundary
hs-sql-agent does not treat a model-generated PostgreSQL statement as trusted simply because the provider could execute it. SQL first enters the typed validation and capability pipeline.
Provider support means the runtime can connect, inspect metadata, compile supported statements, and execute them under policy. It does not mean every vendor-specific syntax form is accepted automatically.
Use metadata before guessing schema
MCP clients can discover schemas, tables, and columns through the built-in metadata tools before constructing PostgreSQL SQL. This reduces blind schema guessing and keeps discovery inside the same authenticated database scope.
- get_schemas
- get_tables
- get_columns
- execute_query_sql
- execute_dml_sql
Fail closed when semantics are not proven
The PostgreSQL path follows the same rule as every other provider: unsupported syntax or cross-provider semantics are rejected at the appropriate validation/capability boundary rather than silently rewritten into a query with different behavior.
PostgreSQL-specific SQL stays explicit
PostgreSQL is not treated as generic SQL with a different connection string. Provider-specific semantics stay inside the compiler capability model, and cross-database lowering is rejected when equivalent behavior has not been proven.
For example, the compiler has an explicit regression contract for PostgreSQL DISTINCT ON: targeting MySQL fails closed rather than inventing a first-row-per-group rewrite with different semantics.
| Compiler contract example | Behavior |
|---|---|
SELECT DISTINCT ON (customer_id) ... | Accepted only where the declared source/target capability contract can preserve PostgreSQL DISTINCT ON semantics. |
PostgreSQL → MySQL DISTINCT ON | Rejected at target capability when semantic equivalence is not proven. |
These examples are a search-oriented summary of the compiler boundary, not a complete SQL compatibility matrix. Unsupported or unproven semantics continue to fail closed.
Compare database MCP targets
The MCP tool surface is shared, but each database keeps its own source grammar, capability checks, and provider-specific rendering rules.
Why use a PostgreSQL MCP server instead of direct database access?
Direct database credentials make the model or MCP client responsible for everything the database account can do. hs-sql-agent keeps the real PostgreSQL connection server-side and evaluates SQL against the compiler, MCP-key scope, table policy, tool restrictions, and runtime limits before execution.
That keeps raw SQL available as an expressive agent interface without turning generated SQL into unrestricted database authority.
- raw SQL remains available for supported statements
- database credentials stay behind the server boundary
- unsupported semantics fail closed before execution
- DML can require explicit human approval