Provides read-only tools for exploring a PostgreSQL database schema (schemas, tables, views, columns, indexes, functions) and running guarded SELECT queries with row limits and safety validation.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@postgres-mcp show me the users table schema"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Universal read-only PostgreSQL MCP server for Antigravity IDE.
Exposes 8 tools to the agent so it can explore your database schema and run SELECT queries — without ever being able to mutate data.
Tool | Description |
| Server version, size, encoding, active connections |
| All non-system schemas in the database |
| Tables & views in a schema with sizes and row estimates |
| Columns, types, constraints, indexes for a table |
| First n rows (ordered by PK when available) |
| Run any read-only SELECT (guarded + row-limited) |
| EXPLAIN / EXPLAIN ANALYZE a query |
| User-defined functions and procedures in a schema |
Every SQL is validated by guard.py before execution (allowlist of first
keyword + blocklist of mutating patterns after comment stripping).
The database session is set to READ ONLY via
SET SESSION CHARACTERISTICS AS TRANSACTION READ ONLY.
execute_query wraps the user SQL in a subquery with a hard LIMIT
(max 5000 rows).
Related MCP server: PostgreSQL MCP Server
pip install "mcp[cli]>=1.0.0" "psycopg[binary]>=3.1.0"Or with uv:
uv pip install "mcp[cli]>=1.0.0" "psycopg[binary]>=3.1.0"Or install the whole project in editable mode:
pip install -e .Copy mcp_config.json from this repo to your global Antigravity config
directory:
~/.gemini/config/mcp_config.jsonEdit the POSTGRES_CONNECTION_STRING value:
{
"mcpServers": {
"postgres": {
"command": "python",
"args": ["-m", "postgres_mcp.server"],
"env": {
"POSTGRES_CONNECTION_STRING": "postgresql://user:password@host:5432/dbname",
"PYTHONPATH": "C:\\Users\\hdo01\\projects\\postgres-mcp\\src"
}
}
}
}If you installed via
pip install -e .you can remove thePYTHONPATHentry and replace["-m", "postgres_mcp.server"]with the installed script:"command": "postgres-mcp", "args": []
Navigate to Additional Options (…) → MCP Servers and confirm postgres
appears in the list with a green status indicator.
Standard PostgreSQL libpq URI:
postgresql://[user[:password]@][host][:port][/dbname][?param=value&...]Examples:
postgresql://admin:secret@localhost:5432/crm_dwh
postgresql://readonly_user@db.internal/analytics?sslmode=require
postgresql://user:pass@127.0.0.1:5433/mydb?connect_timeout=10# Run the server directly (for debugging)
POSTGRES_CONNECTION_STRING="postgresql://..." python -m postgres_mcp.server
# Or with the MCP dev inspector
mcp dev src/postgres_mcp/server.pyOnly ever use a read-only database role for the connection string — this is defence-in-depth on top of the application-level guard.
The mcp_config.json env block is the authoritative place for the
connection string; never commit secrets to version control.
Consider using a .env file or a secrets manager and referencing the
variable name rather than the literal value.
Show columns, data types, nullability, defaults, and constraints for a table.
Args: table: Table name. schema: Schema that owns the table (default: "public").
| Name | Required | Description | Default |
|---|---|---|---|
| table | Yes | ||
| schema | No | public |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full load and it does disclose the core behavior: a read-only, non-mutating introspection operation that returns table metadata. It does not mention edge cases like missing tables or permission requirements, but the behavior is plainly conveyed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one focused sentence followed by a tight, useful Args block. Every sentence earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple introspection tool with two parameters and an output schema, the description provides everything needed to call it correctly: required table name, optional schema with a default, and the exact information returned. No important gap remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by explaining each parameter: 'Table name' for table and 'Schema that owns the table' with the 'public' default. This adds meaning beyond the bare type/name fields in the input schema, though it stays minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Show') and resource ('a table'), and enumerates the exact metadata returned: columns, data types, nullability, defaults, and constraints. This clearly distinguishes it from siblings like list_tables or get_table_sample.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied rather than explicit: an agent can infer that this tool is for inspecting a table's schema, but the description does not state when to prefer it over alternatives or mention exclusions. It provides no explicit when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a read-only SQL query and return results as JSON.
The query must be a SELECT (or WITH … SELECT / EXPLAIN / SHOW / TABLE / VALUES). Mutating statements are rejected before they reach the database.
Args: sql: The SQL query to execute. limit: Maximum number of rows to return (default: 500, max: 5000).
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | ||
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly reveals that the tool is read-only, that mutating statements are rejected pre-database, and that results are returned as JSON with a configurable row limit. This is strong context, though it does not mention error handling, timeouts, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, opening with the core action and output format, then adding restrictions, then documenting parameters. Every sentence contributes meaningful information with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a straightforward two-parameter tool and the presence of an output schema, the description covers the essential operational details: allowed query types, mutation rejection, row limit constraints, and JSON result format. It is complete enough for an agent to invoke correctly, though it could optionally add an example or pointer to sibling explain_query for plan-only analysis.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the schema's lack of per-property descriptions. It does so for both parameters: sql is defined as the SQL query to execute, and limit is explained as the maximum number of rows with default and maximum values. This fully covers the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Execute a read-only SQL query and return results as JSON.' It clearly distinguishes this from sibling metadata tools by emphasizing arbitrary SQL execution with explicit allowed statement types (SELECT, WITH, EXPLAIN, SHOW, TABLE, VALUES) and by noting mutating statements are rejected.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear boundaries for use by listing accepted statement types and stating that mutating statements are rejected before reaching the database. However, it does not explicitly say when to use this tool versus sibling alternatives like explain_query or list_tables, so the usage guidance is implied rather than fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run EXPLAIN (or EXPLAIN ANALYZE) on a query and return the plan.
Args: sql: The SELECT query to explain. analyze: If True, actually executes the query to get runtime stats (EXPLAIN ANALYZE). Default: False (plan only, no execution).
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | ||
| analyze | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that analyze=True actually executes the query for runtime stats, and default is plan-only with no execution. This is key behavioral context beyond the schema. It does not explicitly state that EXPLAIN is read-only, but it specifies 'SELECT query' which implies it. Overall, it provides meaningful disclosure without contradicting anything.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Efficient and front-loaded. The first sentence states the purpose, followed by a compact bullet list of arguments. No redundant words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, it does not need to describe the return format. It covers the key parameter behavior and the execution mode distinction. It lacks explicit guidance on when to use this vs execute_query, which is a minor gap, but overall it is complete for a simple, well-scoped tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It fully explains both parameters: sql as 'The SELECT query to explain' and analyze with behavior and default ('If True, actually executes the query to get runtime stats... Default: False (plan only, no execution)'). This adds substantial meaning beyond the raw schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Run EXPLAIN') on a specific resource ('a SELECT query') and the output ('return the plan'). This clearly distinguishes the tool from its sibling execute_query, which would run the query itself. The purpose is unambiguous and scoped.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage: it is for examining execution plans without executing (plan-only by default), and analyze=True adds runtime stats. However, it does not explicitly contrast with execute_query or state when not to use it. There is no direct 'use this instead of X' guidance, so only implied usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return general information about the connected PostgreSQL database: version, current database, current user, encoding, timezone, and top-level statistics.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of explaining behavior. It communicates a read-only, informational operation by saying it returns database info, which implies no destructive side effects. However, it does not explicitly state non-mutating behavior, permission requirements, or potential costs of computing 'top-level statistics,' so some behavioral uncertainty remains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that starts with the action and immediately lists the concrete information returned. Every word earns its place, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has zero parameters, and an output schema exists, so the description does not need to justify return values further. It names the database type (PostgreSQL) and specific facts returned, making it fully actionable for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100%, so there is nothing missing. The description appropriately avoids inventing parameter details. Baseline 4 applies for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and resource ('general information about the connected PostgreSQL database'), and enumerates exactly what will be returned: version, current database, current user, encoding, timezone, and top-level statistics. This clearly distinguishes it from sibling tools like list_tables or execute_query, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly establishes the tool's context: retrieving database-level metadata with no arguments. Although it does not explicitly name alternative tools, the narrow scope and listed return fields make it obvious when to choose this over siblings like list_schemas or describe_table. A small explicit 'when to use' statement could improve it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the first n rows of a table (ORDER BY primary key if available).
Args: table: Table name. schema: Schema name (default: "public"). n: Number of rows to return (default: 20, max: 500).
| Name | Required | Description | Default |
|---|---|---|---|
| n | No | ||
| table | Yes | ||
| schema | No | public |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does disclose the ordering behavior (if primary key available) and the max row limit (500), which adds value. However, it does not mention error behavior, whether it is strictly read-only (though 'Return' implies so), or what happens when no primary key exists (non-deterministic order). These gaps are minor but present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-line summary followed by a clean parameter list. No redundant wording, and the most important detail (the ordering behavior) is front-loaded. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, so the return shape is covered. The description explains the core behavior and parameter constraints. It does not mention edge cases like negative n or empty results, but these are either self-evident or unlikely to affect correct usage. The description is complete enough for an agent to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain every parameter. It does so clearly: table name, schema (with default), and n (with default and max). It adds the max constraint (500) which is not in the schema. This fully compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Return the first *n* rows of a table' with an explicit ordering hint (ORDER BY primary key). It distinguishes itself from siblings like list_tables and execute_query by focusing on sampling rows. No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (quick sample of a table) but does not explicitly state when to choose this over alternatives like execute_query or describe_table. There are no when-not-to-use notes or direct comparisons to siblings. Usage context is inferred rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List user-defined functions and stored procedures in schema.
Args: schema: Schema name (default: "public").
| Name | Required | Description | Default |
|---|---|---|---|
| schema | No | public |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It doesn't mention whether it returns only names or full definitions, permissions required, if it's a read-only operation, or any limits. As a listing tool, it's likely safe, but the description doesn't state that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear opening sentence and an args section for the parameter. It's front-loaded with the main purpose, and the parameter details are brief and to the point. No superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description is mostly complete. It could benefit from specifying what the output looks like (e.g., list of function names) but the output schema covers that. It lacks detail on behavior like read-only nature, but for a listing tool, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter with 0% description coverage, but the description mentions 'schema' and its default value. This adds minimal meaning beyond the schema, but for a single simple parameter, it's adequate. The description could clarify that it accepts a schema name, but it does.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists user-defined functions and stored procedures in a schema, using a specific verb and resource. It distinguishes itself from siblings by focusing on functions rather than schemas or tables, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for inspecting functions and procedures, but doesn't explicitly state when to use this vs. sibling tools like list_tables or describe_table. It provides no exclusion criteria or alternative suggestions, leaving the agent to infer context from the resource type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all schemas in the connected PostgreSQL database.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the burden of behavioral disclosure. 'List' implies a read-only operation, but the description does not clarify whether system schemas such as pg_catalog are included, nor mention any permissions or limitations. Adequate for a simple zero-parameter tool, but lacking deeper behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the action and resource. No filler, every word contributes to meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with an output schema present, the description is largely sufficient for correct invocation. The only notable missing detail is whether 'all schemas' includes system schemas, which is a minor gap in an otherwise complete definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema, so there is nothing for the description to add. Baseline of 4 applies because no parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('List') and resource ('all schemas') scoped to the connected PostgreSQL database. Clearly distinguishes this from sibling tools like list_tables and list_functions. No ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no explicit guidance on when to use this tool versus alternatives such as list_tables or list_functions. Usage is only implied by the name and description, with no preconditions, exclusions, or recommended sequencing mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all tables (and views) in schema.
Args: schema: PostgreSQL schema name (default: "public").
| Name | Required | Description | Default |
|---|---|---|---|
| schema | No | public |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavior disclosure. It conveys that the operation is read-only and includes both tables and views, but it does not mention behaviors like whether system schemas are excluded, permission requirements, or behavior on an invalid schema. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: the main behavior is in the first sentence, followed by a minimal Args block. No fluff or unrelated detail is present, and both statements earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, one optional parameter, and presence of an output schema, the description is mostly complete. It could be improved by noting the relationship to list_schemas or behavior when the schema does not exist, but the core invocation information is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds semantic meaning by identifying 'schema' as a PostgreSQL schema name and restating the default value 'public.' Since there is only one optional parameter, this is sufficient compensation despite some redundancy with the schema's default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'List all tables (and views) in *schema*.' It clearly identifies what is returned and scopes the operation to a named schema, which also differentiates it from siblings like list_schemas and describe_table without needing extra explanation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance about when to use this tool instead of its siblings, such as list_schemas or describe_table. The description does not mention alternatives, exclusions, or prerequisites; the only context is the default schema argument, which is not a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0describe_tableexecute_queryexplain_queryget_database_infoget_table_samplelist_functionslist_schemaslist_tablesScored across 8 tools
Each tool targets a distinct aspect of database interaction: metadata discovery (schemas, tables, columns, functions), row retrieval (sample, query), and query analysis (explain, database info). The overlap between get_table_sample and execute_query is minimal because one is a convenience for a specific table while the other accepts arbitrary read-only SQL.
All tools follow a consistent verb_noun snake_case convention, with list_* for metadata enumeration, get_* for specific retrievals, and execute_query/explain_query/describe_table for actions. There are no mixed casing styles or vague verbs.
Eight tools is well-scoped for a PostgreSQL introspection and read-only query server. Each tool covers a meaningful capability without redundancy or bloat.
The tool surface covers the full read-only lifecycle: discovering schemas, tables, columns, functions, database info, sampling data, running arbitrary SELECTs, and explaining query plans. Since execute_query permits arbitrary read-only SQL, any remaining introspection gaps can be queried directly, so there are no dead ends.
Safe, read-only Postgres and MySQL access for AI agents. Audit log + column-level controls.
Generate, fix, explain and run read-only SQL on PostgreSQL, MySQL and SQL Server
Query PostgreSQL databases in plain English — LLM-generated, safety-validated SQL.
Query your Postgres from ChatGPT or Claude without exposing the database or handing over credentials. Run npx boltschema connect next to your database and it dials out over HTTPS — no inbound firewall rule, no open port, works with localhost and VPC-private databases. Read-only is enforced by a SQL guard, a Postgres READ ONLY transaction, and a scoped role generated for you.
