Kenning PG MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PG_MCP_HOST | No | HTTP bind host | 127.0.0.1 |
| PG_MCP_PORT | No | HTTP bind port | 8000 |
| DATABASE_URI | Yes | Connection URI (required) | |
| PG_MCP_SCHEMAS | No | Schema allowlist (comma-separated), default all non-system | |
| PG_MCP_MAX_ROWS | No | Max rows | 1000 |
| PG_MCP_POOL_MAX | No | Pool max | 5 |
| PG_MCP_POOL_MIN | No | Pool min | 1 |
| PG_MCP_LOG_LEVEL | No | Log level | INFO |
| PG_MCP_MAX_BYTES | No | Max response bytes | 1048576 |
| PG_MCP_TRANSPORT | No | Transport | stdio |
| PG_MCP_ACCESS_MODE | No | Access mode | restricted |
| PG_MCP_ALLOW_REMOTE | No | Allow remote binding (requires PG_MCP_TRANSPORT=http) | |
| PG_MCP_ALLOWED_HOSTS | No | Allowed hosts for HTTP mode | |
| PG_MCP_ALLOWED_ORIGINS | No | Allowed origins for HTTP mode | |
| PG_MCP_STATEMENT_TIMEOUT | No | Statement timeout | 30s |
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": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_schemasA | List database schemas visible to this server, honoring the configured schema allowlist. Cheap. Call this first to see what exists; then use list_objects to look inside a schema. |
| list_objectsA | List tables, views, materialized views, sequences, and foreign tables in a schema, with comments and approximate row counts. Cheap. Filter by object_type and/or a SQL LIKE name_pattern (e.g. 'order%'). Prefer describe_object for the full shape of a single relation. |
| describe_objectA | Describe one relation: columns (name, type, nullable, default, comment), primary key, foreign keys in both directions, indexes, check and unique constraints, and an approximate row count from pg_class.reltuples. Cheap. Prefer this over querying catalogs by hand; use it before writing queries against unfamiliar tables. |
| execute_queryA | Run a single read-only SQL statement inside a READ ONLY transaction and return {columns, rows, row_count, truncated, notice?}. Exactly one statement per call. Use %s placeholders with the params list for user-supplied values. Results are capped at the configured row and byte limits with an explicit truncation notice when more data exists — no LIMIT is ever injected into your SQL. Cost depends entirely on the query; run explain_query first for anything potentially expensive. |
| explain_queryA | Return the PostgreSQL execution plan (EXPLAIN, FORMAT JSON) for a single statement. Cheap without analyze. With analyze=true the statement is actually executed to collect real timing — the transaction is always rolled back, so even in read-write mode nothing persists, but the statement's runtime cost is fully paid. Parameters are not supported here; inline literal values instead. |
| list_extensionsA | List installed and available PostgreSQL extensions with versions and descriptions. Cheap. Check here whether an extension (pg_stat_statements, postgis, hypopg, ...) exists before writing queries that depend on it. |
| server_infoA | Report server version, current role and database, effective access mode, and key settings (timeouts, search_path, recovery state). Cheap. Useful for orientation and for diagnosing permission or timeout surprises. |
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 7 tools
Each tool has a clearly distinct purpose: describe_object inspects a single relation's shape, execute_query runs SQL, explain_query plans SQL, list_extensions and list_schemas enumerate namespaces, list_objects lists relations in a schema, and server_info reports environment. No two tools overlap in function.
Most tools follow a consistent verb_object pattern (describe_object, execute_query, explain_query, list_extensions, list_schemas, list_objects, server_info). The only slight deviation is the phrase-based server_info which could be get_server_info, but it's still clearly readable and consistent with the snake_case convention.
Seven tools is a well-scoped count for a PostgreSQL inspection server. Each tool earns its place covering discovery, planning, execution, and environment introspection without bloat.
The surface covers the full inspection lifecycle: orientation (server_info, list_schemas, list_extensions), table discovery (list_objects), full schema detail (describe_object), planning (explain_query), and execution (execute_query). The guidance embedded in descriptions (e.g., run explain first, check extensions before depending on them) chains the tools into a complete workflow with no dead ends.