The column_values tool solves a surprisingly annoying problem. Agents confidently writing WHERE status = 'active' when the real value is 'ACTIVE' or 'enabled' causes a lot of unnecessary back-and-forth. Nice that it's addressed explicitly.
Read-only by design is a smart constraint for agent tooling — eliminates a whole class of "oops the LLM dropped my table" failure modes. Curious about a couple things: how do you handle schema introspection? Do the tools auto-discover tables/columns or is there a config step? And for the query tools, is there any cost/complexity guardrail (e.g. preventing a full sequential scan on a 500M row table)?
No config step, the tools discover everything from pg_catalog at call time. list_schemas → list_tables → describe_table is the typical agent workflow, and there's a query_guide prompt baked in that suggests that progression.
On query guardrails: every query runs in a readonly transaction and results are capped at 500 rows via a wrapping SELECT * FROM (...) sub LIMIT 500. There's also explain_query which returns the plan without executing, so agents can check before running something expensive. That said, there's no cost-based gate that blocks a bad plan automatically; that's an interesting idea worth exploring.
Most Postgres MCP servers expose query and list_tables. Agents end up guessing column values, enum casing, and join paths - then retrying until something works.
pglens gives agents the context to get it right the first time: column_values shows real distinct values with counts, find_join_path does BFS over the FK graph and returns join conditions through
intermediate tables, describe_table gives columns/PKs/FKs/indexes in one call. Plus production health tools like bloat_stats, blocking_locks, and sequence_health.
Everything runs in readonly transactions, identifiers escaped via Postgres's quote_ident(), no extensions required. Works on any Postgres 12+ (self-hosted, RDS, Aurora, etc.). Two dependencies:
asyncpg and mcp.
The column_values tool solves a surprisingly annoying problem. Agents confidently writing WHERE status = 'active' when the real value is 'ACTIVE' or 'enabled' causes a lot of unnecessary back-and-forth. Nice that it's addressed explicitly.
Read-only by design is a smart constraint for agent tooling — eliminates a whole class of "oops the LLM dropped my table" failure modes. Curious about a couple things: how do you handle schema introspection? Do the tools auto-discover tables/columns or is there a config step? And for the query tools, is there any cost/complexity guardrail (e.g. preventing a full sequential scan on a 500M row table)?
No config step, the tools discover everything from pg_catalog at call time. list_schemas → list_tables → describe_table is the typical agent workflow, and there's a query_guide prompt baked in that suggests that progression.
On query guardrails: every query runs in a readonly transaction and results are capped at 500 rows via a wrapping SELECT * FROM (...) sub LIMIT 500. There's also explain_query which returns the plan without executing, so agents can check before running something expensive. That said, there's no cost-based gate that blocks a bad plan automatically; that's an interesting idea worth exploring.
Most Postgres MCP servers expose query and list_tables. Agents end up guessing column values, enum casing, and join paths - then retrying until something works.
pglens gives agents the context to get it right the first time: column_values shows real distinct values with counts, find_join_path does BFS over the FK graph and returns join conditions through intermediate tables, describe_table gives columns/PKs/FKs/indexes in one call. Plus production health tools like bloat_stats, blocking_locks, and sequence_health.
Everything runs in readonly transactions, identifiers escaped via Postgres's quote_ident(), no extensions required. Works on any Postgres 12+ (self-hosted, RDS, Aurora, etc.). Two dependencies: asyncpg and mcp.
https://github.com/janbjorge/pglens
pip install pglen
This is really nicely, read only is the right way to start
Thanks! Read-only felt like the obvious constraint; agents shouldn't need write access to understand a database.
[dead]
[flagged]
[dead]
[flagged]
I don't know why but all your comments are getting hidden/flagged/killed for some reason.
[flagged]
[dead]