Scored across 186 tools
Most tools have clearly distinct purposes and detailed descriptions, but there are several overlapping clusters that could cause misselection: graph tools (list_graphs/describe_graph vs list_property_graphs/describe_property_graph), query analysis tools (explain_query vs analyze_query_plan vs why_is_this_slow vs optimize_query), and multiple search variants (vector_search, hybrid_search, hybrid_bm25_vector_search, pg_search_run). The descriptions help disambiguate, but the sheer number of similar-sounding tools creates real ambiguity.
The vast majority of tools follow a consistent snake_case verb_noun pattern (list_*, get_*, generate_*, recommend_*, analyze_*, read_*, run_*). Minor deviations exist, such as why_is_this_slow (question-style rather than verb_noun) and some verb alternation between get/check/verify for status tools, but there is no chaotic mixing of conventions.
186 tools is an extreme count for any MCP server, even one covering PostgreSQL broadly. The surface is far beyond what an agent can reliably navigate, and many tools are hyper-specialized to optional extensions or niche PG19 features. This is a clear case of severe over-scoping rather than a coherent, curated toolset.
The toolset covers an enormous range of read-only introspection, advisory, and search functionality, but it has significant gaps for a 'production-grade PostgreSQL' server: run_write, prepare_migration, and validate_migration_schema are referenced in descriptions but not exposed as tools, and there is no general path to apply generated DDL or run migrations. Agents needing write or migration execution will fail without workarounds.
