adaptive-pg-mcp (PostgreSQL)
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DEMO_DSN | No | Connection string of the demo database. The introspection image starts its own empty Postgres and sets this itself. | |
| ADAPTIVE_PG_MCP_TOKEN | No | The caller's bearer token over stdio. The introspection image accepts only glama-introspection-only. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| aggregateA | Computes count, sum, avg, min or max over one table or view, with an optional filter and grouping. Returns at most 1,000 groups. |
| delete_rowsA | Deletes the rows of one table that match a where filter. Rolls back a call that changes more than 100 rows, triggers and cascades included. Returns rowsAffected and up to 1,000 returning rows. |
| describe_tableA | Describes the columns of one table or view that the read login may use: name, type, nullable, default and primary key. |
| execute_ddlA | Runs one DDL statement, such as CREATE, ALTER or DROP, or a TRUNCATE. Rolls back a statement that only works on rows, which needs execute_sql, and one that changes more than 100 rows in tables that existed before it. Returns at most 1,000 rows. Times out after 30s. |
| execute_sqlA | Runs one SQL statement that works on rows, such as INSERT, UPDATE, DELETE, MERGE, CALL or DO. Rolls back TRUNCATE and changes of structure, which need execute_ddl, and a statement that changes more than 100 rows across all tables. Returns at most 1,000 rows. Times out after 30s. |
| insert_rowsA | Inserts rows into one table. Rolls back a call that changes more than 100 rows, triggers and cascades included. Returns rowsAffected and up to 1,000 returning rows. |
| list_databasesA | Lists the databases the caller may use, 25 per page. Pass an object's value as database to the other tools. |
| list_schemasA | Lists the schemas that the read login may use, without the system schemas, 100 per page. |
| list_tablesA | Lists the tables, views, materialized views and foreign tables that the read login may use, with schema, name and kind, 100 per page. |
| query_sqlA | Runs one SQL statement in a read-only transaction, so it cannot change data. Returns at most 1,000 rows and 1,048,576 bytes. Times out after 30s. |
| read_rowsA | Reads rows of one table or view, with an optional filter, order and limit. Returns at most 1,000 rows and 1,048,576 bytes. |
| update_rowsA | Updates the rows of one table that match a where filter. Rolls back a call that changes more than 100 rows, triggers and cascades included. Returns rowsAffected and up to 1,000 returning rows. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 12 tools
Each tool has a stated purpose and the descriptions explicitly carve boundaries (execute_sql rejects TRUNCATE/structure changes; execute_ddl rejects row-only statements; query_sql is read-only). The main overlap is execute_sql versus insert_rows/update_rows/delete_rows and query_sql versus read_rows/aggregate, where an agent could reasonably pick either, though the specialized tools are clearly the safer/convenience option.
Nearly all names follow a verb_noun pattern (list_tables, read_rows, insert_rows, update_rows, delete_rows, execute_sql, describe_table), which is predictable and readable. The only deviation is the bare verb 'aggregate', which lacks a noun target.
Twelve tools is a well-scoped surface for a PostgreSQL server: discovery (list_databases/schemas/tables), inspection (describe_table), reads (read_rows, query_sql, aggregate), and writes (insert/update/delete/execute_sql/execute_ddl). No tool appears redundant enough to drop.
CRUD, DDL, arbitrary read SQL, aggregation, and schema/database discovery are all covered, so core lifecycle workflows have no dead ends. Gaps remain for transaction control (begin/commit/rollback across statements) and query plan introspection (EXPLAIN), and pagination beyond the first page is only implied for the list_* tools.