Scored across 18 tools
Every tool targets a distinct resource or action: introspective tools (schema, overview, table_info, health) are cleanly separated by granularity, read tools (find_many, find_first, count, aggregate) by return shape and purpose, and write tools (create, upsert, update_many, delete_many) by operation semantics. Even potentially adjacent tools like db_explain and db_raw_query are clearly differentiated. No two tools appear to do the same thing.
The overwhelming majority of tools follow a consistent db_ verb_noun snake_case pattern (db_find_many, db_update_many, db_backup, db_upsert). The only exception is mcp_status, which breaks the prefix convention but is still readable and logically separate (server health vs. database operations).
At 18 tools, this is on the heavier side but each tool serves a legitimate role in a comprehensive PostgreSQL access surface: discovery, monitoring, structured reads, analytics, raw SQL escape hatch, backup, and write operations. The count is justified by the breadth of the domain, though it slightly exceeds the ideal 3-15 sweet spot.
The tool set provides full CRUD coverage (create, read via find_many/find_first, update via update_many, delete via delete_many), plus upsert for idempotent writes. It also covers schema discovery, database switching, health monitoring, query explanation, aggregation, raw SQL escape hatch, and backups—no critical lifecycle dead ends. The intentional exclusion of DDL and raw write tools fits the read-safe design.