Provides comprehensive PostgreSQL database management including health monitoring, index tuning, query plan analysis, schema intelligence, and configurable SQL execution with support for both development and production environments.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Postgres MCP Pro analyze query performance for the users table and suggest indexes"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Postgres MCP Pro is an open source Model Context Protocol (MCP) server built to support you and your AI agents throughout the entire development process—from initial coding, through testing and deployment, and to production tuning and maintenance.
Postgres MCP Pro does much more than wrap a database connection.
Features include:
🔍 Database Health - analyze index health, connection utilization, buffer cache, vacuum health, sequence limits, replication lag, and more.
⚡ Index Tuning - explore thousands of possible indexes to find the best solution for your workload, using industrial-strength algorithms.
📈 Query Plans - validate and optimize performance by reviewing EXPLAIN plans and simulating the impact of hypothetical indexes.
🧠 Schema Intelligence - context-aware SQL generation based on detailed understanding of the database schema.
🛡️ Safe SQL Execution - configurable access control, including support for read-only mode and safe SQL parsing, making it usable for both development and production.
Postgres MCP Pro supports both the Standard Input/Output (stdio) and Server-Sent Events (SSE) transports, for flexibility in different environments.
For additional background on why we built Postgres MCP Pro, see our launch blog post.
Related MCP server: PostgreSQL MCP Server
From Unusable to Lightning Fast
Challenge: We generated a movie app using an AI assistant, but the SQLAlchemy ORM code ran painfully slow.
Solution: Using Postgres MCP Pro with Cursor, we fixed the performance issues in minutes.
What we did:
🚀 Fixed performance - including ORM queries, indexing, and caching
🛠️ Fixed a broken page - by prompting the agent to explore the data, fix queries, and add related content.
🧠 Improved the top movies - by exploring the data and fixing the ORM query to surface more relevant results.
See the video below or read the play-by-play.
https://github.com/user-attachments/assets/24e05745-65e9-4998-b877-a368f1eadc13
Before getting started, ensure you have:
Access credentials for your database.
Docker or Python 3.12 or higher.
You can confirm your access credentials are valid by using psql or a GUI tool such as pgAdmin.
The choice to use Docker or Python is yours. We generally recommend Docker because Python users can encounter more environment-specific issues. However, it often makes sense to use whichever method you are most familiar with.
Choose one of the following methods to install Postgres MCP Pro:
Pull the Postgres MCP Pro MCP server Docker image. This image contains all necessary dependencies, providing a reliable way to run Postgres MCP Pro in a variety of environments.
docker pull crystaldba/postgres-mcpIf you have pipx installed you can install Postgres MCP Pro with:
pipx install postgres-mcpOtherwise, install Postgres MCP Pro with uv:
uv pip install postgres-mcpIf you need to install uv, see the uv installation instructions.
We provide full instructions for configuring Postgres MCP Pro with Claude Desktop. Many MCP clients have similar configuration files, you can adapt these steps to work with the client of your choice.
You will need to edit the Claude Desktop configuration file to add Postgres MCP Pro. The location of this file depends on your operating system:
MacOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%/Claude/claude_desktop_config.json
You can also use Settings menu item in Claude Desktop to locate the configuration file.
You will now edit the mcpServers section of the configuration file.
{
"mcpServers": {
"postgres": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"-e",
"DATABASE_URI",
"crystaldba/postgres-mcp",
"--access-mode=unrestricted"
],
"env": {
"DATABASE_URI": "postgresql://username:password@localhost:5432/dbname"
}
}
}
}The Postgres MCP Pro Docker image will automatically remap the hostname localhost to work from inside of the container.
MacOS/Windows: Uses host.docker.internal automatically
Linux: Uses 172.17.0.1 or the appropriate host address automatically
pipx{
"mcpServers": {
"postgres": {
"command": "postgres-mcp",
"args": [
"--access-mode=unrestricted"
],
"env": {
"DATABASE_URI": "postgresql://username:password@localhost:5432/dbname"
}
}
}
}uv{
"mcpServers": {
"postgres": {
"command": "uv",
"args": [
"run",
"postgres-mcp",
"--access-mode=unrestricted"
],
"env": {
"DATABASE_URI": "postgresql://username:password@localhost:5432/dbname"
}
}
}
}Replace postgresql://... with your Postgres database connection URI.
Postgres MCP Pro supports multiple access modes to give you control over the operations that the AI agent can perform on the database:
Unrestricted Mode: Allows full read/write access to modify data and schema. It is suitable for development environments.
Restricted Mode: Limits operations to read-only transactions and imposes constraints on resource utilization (presently only execution time). It is suitable for production environments.
To use restricted mode, replace --access-mode=unrestricted with --access-mode=restricted in the configuration examples above.
Many MCP clients have similar configuration files to Claude Desktop, and you can adapt the examples above to work with the client of your choice.
If you are using Cursor, you can use navigate from the Command Palette to Cursor Settings, then open the MCP tab to access the configuration file.
If you are using Windsurf, you can navigate to from the Command Palette to Open Windsurf Settings Page to access the configuration file.
If you are using Goose run goose configure, then select Add Extension.
Postgres MCP Pro supports the SSE transport, which allows multiple MCP clients to share one server, possibly a remote server.
To use the SSE transport, you need to start the server with the --transport=sse option.
For example, with Docker run:
docker run -p 8000:8000 \
-e DATABASE_URI=postgresql://username:password@localhost:5432/dbname \
crystaldba/postgres-mcp --access-mode=unrestricted --transport=sseThen update your MCP client configuration to call the the MCP server.
For example, in Cursor's mcp.json or Cline's cline_mcp_settings.json you can put:
{
"mcpServers": {
"postgres": {
"type": "sse",
"url": "http://localhost:8000/sse"
}
}
}For Windsurf, the format in mcp_config.json is slightly different:
{
"mcpServers": {
"postgres": {
"type": "sse",
"serverUrl": "http://localhost:8000/sse"
}
}
}To enable index tuning and comprehensive performance analysis you need to load the pg_stat_statements and hypopg extensions on your database.
The pg_stat_statements extension allows Postgres MCP Pro to analyze query execution statistics.
For example, this allows it to understand which queries are running slow or consuming significant resources.
The hypopg extension allows Postgres MCP Pro to simulate the behavior of the Postgres query planner after adding indexes.
If your Postgres database is running on a cloud provider managed service, the pg_stat_statements and hypopg extensions should already be available on the system.
In this case, you can just run CREATE EXTENSION commands using a role with sufficient privileges:
CREATE EXTENSION IF NOT EXISTS pg_stat_statements;
CREATE EXTENSION IF NOT EXISTS hypopg;If you are managing your own Postgres installation, you may need to do additional work.
Before loading the pg_stat_statements extension you must ensure that it is listed in the shared_preload_libraries in the Postgres configuration file.
The hypopg extension may also require additional system-level installation (e.g., via your package manager) because it does not always ship with Postgres.
Ask:
Check the health of my database and identify any issues.
Ask:
What are the slowest queries in my database? And how can I speed them up?
Ask:
My app is slow. How can I make it faster?
Ask:
Analyze my database workload and suggest indexes to improve performance.
Ask:
Help me optimize this query: SELECT * FROM orders JOIN customers ON orders.customer_id = customers.id WHERE orders.created_at > '2023-01-01';
The MCP standard defines various types of endpoints: Tools, Resources, Prompts, and others.
Postgres MCP Pro provides functionality via MCP tools alone. We chose this approach because the MCP client ecosystem has widespread support for MCP tools. This contrasts with the approach of other Postgres MCP servers, including the Reference Postgres MCP Server, which use MCP resources to expose schema information.
Postgres MCP Pro Tools:
Tool Name | Description |
| Lists all database schemas available in the PostgreSQL instance. |
| Lists database objects (tables, views, sequences, extensions) within a specified schema. |
| Provides information about a specific database object, for example, a table's columns, constraints, and indexes. |
| Executes SQL statements on the database, with read-only limitations when connected in restricted mode. |
| Gets the execution plan for a SQL query describing how PostgreSQL will process it and exposing the query planner's cost model. Can be invoked with hypothetical indexes to simulate the behavior after adding indexes. |
| Reports the slowest SQL queries based on total execution time using |
| Analyzes the database workload to identify resource-intensive queries, then recommends optimal indexes for them. |
| Analyzes a list of specific SQL queries (up to 10) and recommends optimal indexes for them. |
| Performs comprehensive health checks including: buffer cache hit rates, connection health, constraint validation, index health (duplicate/unused/invalid), sequence limits, and vacuum health. |
Postgres MCP Servers
Query MCP. An MCP server for Supabase Postgres with a three-tier safety architecture and Supabase management API support.
PG-MCP. An MCP server for PostgreSQL with flexible connection options, explain plans, extension context, and more.
Reference PostgreSQL MCP Server. A simple MCP Server implementation exposing schema information as MCP resources and executing read-only queries.
Supabase Postgres MCP Server. This MCP Server provides Supabase management features and is actively maintained by the Supabase community.
Nile MCP Server. An MCP server providing access to the management API for the Nile's multi-tenant Postgres service.
Neon MCP Server. An MCP server providing access to the management API for Neon's serverless Postgres service.
Wren MCP Server. Provides a semantic engine powering business intelligence for Postgres and other databases.
DBA Tools (including commercial offerings)
Aiven Database Optimizer. A tool that provides holistic database workload analysis, query optimizations, and other performance improvements.
dba.ai. An AI-powered database administration assistant that integrates with GitHub to resolve code issues.
pgAnalyze. A comprehensive monitoring and analytics platform for identifying performance bottlenecks, optimizing queries, and real-time alerting.
Postgres.ai. An interactive chat experience combining an extensive Postgres knowledge base and GPT-4.
Xata Agent. An open-source AI agent that automatically monitors database health, diagnoses issues, and provides recommendations using LLM-powered reasoning and playbooks.
Postgres Utilities
Dexter. A tool for generating and testing hypothetical indexes on PostgreSQL.
PgHero. A performance dashboard for Postgres, with recommendations. Postgres MCP Pro incorporates health checks from PgHero.
PgTune. Heuristics for tuning Postgres configuration.
How is Postgres MCP Pro different from other Postgres MCP servers? There are many MCP servers allow an AI agent to run queries against a Postgres database. Postgres MCP Pro does that too, but also adds tools for understanding and improving the performance of your Postgres database. For example, it implements a version of the Anytime Algorithm of Database Tuning Advisor for Microsoft SQL Server, a modern industrial-strength algorithm for automatic index tuning.
Postgres MCP Pro | Other Postgres MCP Servers |
✅ Deterministic database health checks | ❌ Unrepeatable LLM-generated health queries |
✅ Principled indexing search strategies | ❌ Gen-AI guesses at indexing improvements |
✅ Workload analysis to find top problems | ❌ Inconsistent problem analysis |
✅ Simulates performance improvements | ❌ Try it yourself and see if it works |
Postgres MCP Pro complements generative AI by adding deterministic tools and classical optimization algorithms The combination is both reliable and flexible.
Why are MCP tools needed when the LLM can reason, generate SQL, etc? LLMs are invaluable for tasks that involve ambiguity, reasoning, or natural language. When compared to procedural code, however, they can be slow, expensive, non-deterministic, and sometimes produce unreliable results. In the case of database tuning, we have well established algorithms, developed over decades, that are proven to work. Postgres MCP Pro lets you combine the best of both worlds by pairing LLMs with classical optimization algorithms and other procedural tools.
How do you test Postgres MCP Pro? Testing is critical to ensuring that Postgres MCP Pro is reliable and accurate. We are building out a suite of AI-generated adversarial workloads designed to challenge Postgres MCP Pro and ensure it performs under a broad variety of scenarios.
What Postgres versions are supported? Our testing presently focuses on Postgres 15, 16, and 17. We plan to support Postgres versions 13 through 17.
Who created this project? This project is created and maintained by Crystal DBA.
TBD
You and your needs are a critical driver for what we build. Tell us what you want to see by opening an issue or a pull request. You can also contact us on Discord.
This section includes a high-level overview technical considerations that influenced the design of Postgres MCP Pro.
Developers know that missing indexes are one of the most common causes of database performance issues. Indexes provide access methods that allow Postgres to quickly locate data that is required to execute a query. When tables are small, indexes make little difference, but as the size of the data grows, the difference in algorithmic complexity between a table scan and an index lookup becomes significant (typically O(n) vs O(log n), potentially more if joins on multiple tables are involved).
Generating suggested indexes in Postgres MCP Pro proceeds in several stages:
Identify SQL queries in need of tuning.
If you know you are having a problem with a specific SQL query you can provide it.
Postgres MCP Pro can also analyze the workload to identify index tuning targets.
To do this, it relies on the pg_stat_statements extension, which records the runtime and resource consumption of each query.
A query is a candidate for index tuning if it is a top resource consumer, either on a per-execution basis or in aggregate.
At present, we use execution time as a proxy for cumulative resource consumption, but it may also make sense to look at specifics resources, e.g., the number of blocks accessed or the number of blocks read from disk.
The analyze_query_workload tool focuses on slow queries, using the mean time per execution with thresholds for execution count and mean execution time.
Agents may also call get_top_queries, which accepts a parameter for mean vs. total execution time, then pass these queries analyze_query_indexes to get index recommendations.
Sophisticated index tuning systems use "workload compression" to produce a representative subset of queries that reflects the characteristics of the workload as a whole, reducing the problem for downstream algorithms. Postgres MCP Pro performs a limited form of workload compression by normalizing queries so that those generated from the same template appear as one. It weights each query equally, a simplification that works when the benefits to indexing are large.
Generate candidate indexes Once we have a list of SQL queries that we want to improve through indexing, we generate a list of indexes that we might want to add. To do this, we parse the SQL and identify any columns used in filters, joins, grouping, or sorting.
To generate all possible indexes we need to consider combinations of these columns, because Postgres supports multicolumn indexes. In the present implementation, we include only one permutation of each possible multicolumn index, which is selected at random. We make this simplification to reduce the search space because permutations often have equivalent performance. However, we hope to improve in this area.
Search for the optimal index configuration.
Our objective is to find the combination of indexes that optimally balances the performance benefits against the costs of storing and maintaining those indexes.
We estimate the performance improvement by using the "what if?" capabilities provided by the hypopg extension.
This simulates how the Postgres query optimizer will execute a query after the addition of indexes, and reports changes based on the actual Postgres cost model.
One challenge is that generating query plans generally requires knowledge of the specific parameter values used in the query. Query normalization, which is necessary to reduce the queries under consideration, removes parameter constants. Parameter values provided via bind variables are similarly not available to us.
To address this problem, we produce realistic constants that we can provide as parameters by sampling from the table statistics.
In version 16, Postgres added generic explain plan functionality, but it has limitations, for example around LIKE clauses, which our implementation does not have.
Search strategy is critical because evaluating all possible index combinations feasible only in simple situations. This is what most sets apart various indexing approaches. Adapting the approach of Microsoft's Anytime algorithm, we employ a greedy search strategy, i.e., find the best one-index solution, then find the best index to add to that to produce a two-index solution. Our search terminates when the time budget is exhausted or when a round of exploration fails to produce any gains above the minimum improvement threshold of 10%.
Cost-benefit analysis. When posed with two indexing alternatives, one which produces better performance and one which requires more space, how do we decide which to choose? Traditionally, index advisors ask for a storage budget and optimize performance with respect to that storage budget. We also take a storage budget, but perform a cost-benefit analysis throughout the optimization.
We frame this as the problem of selecting a point along the Pareto front—the set of choices for which improving one quality metric necessarily worsens another. In an ideal world, we might want to assess the cost of the storage and the benefit of improved performance in monetary terms. However, there is a simpler and more practical approach: to look at the changes in relative terms. Most people would agree that a 100x performance improvement is worth it, even if the storage cost is 2x. In our implementation, we use a configurable parameter to set this threshold. By default, we require the change in the log (base 10) of the performance improvement to be 2x the difference in the log of the space cost. This works out to allowing a maximum 10x increase in space for a 100x performance improvement.
Our implementation is most closely related to the Anytime Algorithm found in Microsoft SQL Server. Compared to Dexter, an automatic indexing tool for Postgres, we search a larger space and use different heuristics. This allows us to generate better solutions at the cost of longer runtime.
We also show the work done in each round of the search, including a comparison of the query plans before and after the addition of each index. This give the LLM additional context that it can use when responding to the indexing recommendations.
Postgres MCP Pro includes an experimental index tuning feature based on Optimization by LLM.
Instead of using heuristics to explore possible index configurations, we provide the database schema and query plans to an LLM and ask it to propose index configurations.
We then use hypopg to predict performance with the proposed indexes, then feed those results back into the LLM to produce a new set of suggestions.
We repeat this process until multiple rounds of iteration produce no further improvements.
Index optimization by LLM is has advantages when the index search space is large, or when indexes with many columns need to be considered.
Like traditional search-based approaches, it relies on the accuracy of the hypopg performance predictions.
In order to perform index optimization by LLM, you must provide an OpenAI API key by setting the OPENAI_API_KEY environment variable.
Database health checks identify tuning opportunities and maintenance needs before they lead to critical issues. In the present release, Postgres MCP Pro adapts the database health checks directly from PgHero. We are working to fully validate these checks and may extend them in the future.
Index Health. Looks for unused indexes, duplicate indexes, and indexes that are bloated. Bloated indexes make inefficient use of database pages. Postgres autovacuum cleans up index entries pointing to dead tuples, and marks the entries as reusable. However, it does not compact the index pages and, eventually, index pages may contain few live tuple references.
Buffer Cache Hit Rate. Measures the proportion of database reads that are served from the buffer cache instead of disk. A low buffer cache hit rate must be investigated as it is often not cost-optimal and leads to degraded application performance.
Connection Health. Checks the number of connections to the database and reports on their utilization. The biggest risk is running out of connections, but a high number of idle or blocked connections can also indicate issues.
Vacuum Health. Vacuum is important for many reasons. A critical one is preventing transaction id wraparound, which can cause the database to stop accepting writes. The Postgres multi-version concurrency control (MVCC) mechanism requires a unique transaction id for each transaction. However, because Postgres uses a 32-bit signed integer for transaction ids, it needs to reuse transaction ids after after a maximum of 2 billion transactions. To do this it "freezes" the transaction ids of historical transactions, setting them all to a special value that indicates distant past. When records first go to disk, they are written visibility for a range of transaction ids. Before re-using these transaction ids, Postgres must update any on-disk records, "freezing" them to remove the references to the transaction ids to be reused. This check looks for tables that require vacuuming to prevent transaction id wraparound.
Replication Health. Checks replication health by monitoring lag between primary and replicas, verifying replication status, and tracking usage of replication slots.
Constraint Health. During normal operation, Postgres rejects any transactions that would cause a constraint violation. However, invalid constraints may occur after loading data or in recovery scenarios. This check looks for any invalid constraints.
Sequence Health. Looks for sequences that are at risk of exceeding their maximum value.
Postgres MCP Pro uses psycopg3 to connect to Postgres using asynchronous I/O. Under the hood, psycopg3 uses the libpq library to connect to Postgres, providing access to the full Postgres feature set and an underlying implementation fully supported by the Postgres community.
Some other Python-based MCP servers use asyncpg, which may simplify installation by eliminating the libpq dependency.
Asyncpg is also probably faster than psycopg3, but we have not validated this ourselves.
Older benchmarks report a larger performance gap, suggesting that the newer psycopg3 has closed the gap as it matures.
Balancing these considerations, we selected psycopg3 over asyncpg.
We remain open to revising this decision in the future.
Like the Reference PostgreSQL MCP Server, Postgres MCP Pro takes Postgres connection information at startup. This is convenient for users who always connect to the same database but can be cumbersome when users switch databases.
An alternative approach, taken by PG-MCP, is provide connection details via MCP tool calls at the time of use. This is more convenient for users who switch databases, and allows a single MCP server to simultaneously support multiple end-users.
There must be a better approach than either of these. Both have security weaknesses—few MCP clients store the MCP server configuration securely (an exception is Goose), and credentials provided via MCP tools are passed through the LLM and stored in the chat history. Both also have usability issues in some scenarios.
The purpose of the schema information tool is to provide the calling AI agent with the information it needs to generate correct and performant SQL. For example, suppose a user asks, "How many flights took off from San Francisco and landed in Paris during the past year?" The AI agent needs to find the table that stores the flights, the columns that store the origin and destinations, and perhaps a table that maps between airport codes and airport locations.
Why provide schema information tools when LLMs are generally capable of generating the SQL to retrieve this information from Postgres directly?
Our experience using Claude indicates that the calling LLM is very good at generating SQL to explore the Postgres schema by querying the Postgres system catalog and the information schema (an ANSI-standardized database metadata view). However, we do not know whether other LLMs do so as reliably and capably.
Would it be better to provide schema information using MCP resources rather than MCP tools?
The Reference PostgreSQL MCP Server uses resources to expose schema information rather than tools. Navigating resources is similar to navigating a file system, so this approach is natural in many ways. However, resource support is less widespread than tool support in the MCP client ecosystem (see example clients). In addition, while the MCP standard says that resources can be accessed by either AI agents or end-user humans, some clients only support human navigation of the resource tree.
AI amplifies longstanding challenges of protecting databases from a range of threats, ranging from simple mistakes to sophisticated attacks by malicious actors. Whether the threat is accidental or malicious, a similar security framework applies, with aims that fall into three categories: confidentiality, integrity, and availability. The familiar tension between convenience and safety is also evident and pronounced.
Postgres MCP Pro's protected SQL execution mode focuses on integrity. In the context of MCP, we are most concerned with LLM-generated SQL causing damage—for example, unintended data modification or deletion, or other changes that might circumvent an organization's change management process.
The simplest way to provide integrity is to ensure that all SQL executed against the database is read-only. One way to do this is by creating a database user with read-only access permissions. While this is a good approach, many find this cumbersome in practice. Postgres does not provide a way to place a connection or session into read-only mode, so Postgres MCP Pro uses a more complex approach to ensure read-only SQL execution on top of a read-write connection.
Postgres MCP Provides a read-only transaction mode that prevents data and schema modifications. Like the Reference PostgreSQL MCP Server, we use read-only transactions to provide protected SQL execution.
To make this mechanism robust, we need to ensure that the SQL does not somehow circumvent the read-only transaction mode, say by issuing a COMMIT or ROLLBACK statement and then beginning a new transaction.
For example, the LLM can circumvent the read-only transaction mode by issuing a ROLLBACK statement and then beginning a new transaction.
For example:
ROLLBACK; DROP TABLE users;To prevent cases like this, we parse the SQL before execution using the pglast library.
We reject any SQL that contains commit or rollback statements.
Helpfully, the popular Postgres stored procedure languages, including PL/pgSQL and PL/Python, do not allow for COMMIT or ROLLBACK statements.
If you have unsafe stored procedure languages enabled on your database, then our read-only protections could be circumvented.
At present, Postgres MCP Pro provides two levels of protection for the database, one at either extreme of the convenience/safety spectrum.
"Unrestricted" provides maximum flexibility. It is suitable for development environments where speed and flexibility are paramount, and where there is no need to protect valuable or sensitive data.
"Restricted" provides a balance between flexibility and safety. It is suitable for production environments where the database is exposed to untrusted users, and where it is important to protect valuable or sensitive data.
Unrestricted mode aligns with the approach of Cursor's auto-run mode, where the AI agent operates with limited human oversight or approvals. We expect auto-run to be deployed in development environments where the consequences of mistakes are low, where databases do not contain valuable or sensitive data, and where they can be recreated or restored from backups when needed.
We designed restricted mode to be conservative, erring on the side of safety even though it may be inconvenient. Restricted mode is limited to read-only operations, and we limit query execution time to prevent long-running queries from impacting system performance. We may add measures in the future to make sure that restricted mode is safe to use with production databases.
The instructions below are for developers who want to work on Postgres MCP Pro, or users who prefer to install Postgres MCP Pro from source.
Install uv:
curl -sSL https://astral.sh/uv/install.sh | shClone the repository:
git clone https://github.com/crystaldba/postgres-mcp.git
cd postgres-mcpInstall dependencies:
uv pip install -e .
uv syncRun the server:
uv run postgres-mcp "postgres://user:password@localhost:5432/dbname"Analyzes database health. Here are the available health checks:
index - checks for invalid, duplicate, and bloated indexes
connection - checks the number of connection and their utilization
vacuum - checks vacuum health for transaction id wraparound
sequence - checks sequences at risk of exceeding their maximum value
replication - checks replication health including lag and slots
buffer - checks for buffer cache hit rates for indexes and tables
constraint - checks for invalid constraints
all - runs all checks You can optionally specify a single health check or a comma-separated list of health checks. The default is 'all' checks.
| Name | Required | Description | Default |
|---|---|---|---|
| health_type | No | Optional. Valid values are: all, buffer, connection, constraint, index, replication, sequence, vacuum. | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It describes what health checks are available but doesn't mention whether this is a read-only operation, if it requires specific permissions, what the output format looks like, whether it's resource-intensive, or if there are rate limits. For a health analysis tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose. The bulleted list efficiently presents health check options, and the final sentence adds important usage context about optional specification and default behavior. Every sentence earns its place, though the bulleted format could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a health analysis tool. It doesn't explain what the tool returns (e.g., health scores, warnings, detailed reports), how results are structured, whether it provides actionable recommendations, or what authentication/authorization is required. The parameter information is adequate, but overall context is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the single parameter with its default value and valid options. The description adds marginal value by explaining the comma-separated list option and providing more detailed explanations of what each health check does (e.g., 'checks for invalid, duplicate, and bloated indexes' for 'index'), but doesn't fundamentally enhance understanding beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as analyzing database health and lists specific health check categories (index, connection, vacuum, etc.). It distinguishes from siblings like analyze_query_indexes by focusing on overall database health rather than query-specific analysis. However, it doesn't explicitly contrast with all siblings like execute_sql or list_schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for database health monitoring but doesn't explicitly state when to use this tool versus alternatives like analyze_query_indexes or get_top_queries. It mentions the default behavior ('all' checks) but provides no guidance on prerequisites, timing, or exclusion criteria relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze a list of (up to 10) SQL queries and recommend optimal indexes
| Name | Required | Description | Default |
|---|---|---|---|
| queries | Yes | List of Query strings to analyze | |
| max_index_size_mb | No | Max index size in MB | |
| method | No | Method to use for analysis | dta |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but lacks behavioral details. It doesn't disclose whether this is a read-only analysis, if it requires database permissions, execution time, or output format. The 10-query limit is mentioned, but other constraints like rate limits or side effects are not addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero waste. It efficiently conveys the core purpose and key constraint (up to 10 queries) without unnecessary elaboration, making it highly scannable and actionable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, 100% schema coverage, and no output schema, the description is minimally complete. It states the purpose clearly but lacks behavioral context (e.g., analysis method implications, output details). Given the complexity of index recommendation, more guidance on usage and results would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents parameters. The description adds no additional meaning beyond implying 'up to 10' queries, which is already covered by the schema's array type. Baseline 3 is appropriate as the schema handles parameter semantics adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('analyze'), the resource ('SQL queries'), and the outcome ('recommend optimal indexes'). It distinguishes from siblings like 'analyze_db_health' (general health) and 'explain_query' (execution plan) by focusing on index recommendations for multiple queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through 'list of (up to 10) SQL queries,' suggesting it's for batch analysis, but doesn't explicitly state when to use this vs. alternatives like 'analyze_workload_indexes' or 'explain_query.' No guidance on prerequisites or exclusions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze frequently executed queries in the database and recommend optimal indexes
| Name | Required | Description | Default |
|---|---|---|---|
| max_index_size_mb | No | Max index size in MB | |
| method | No | Method to use for analysis | dta |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions analysis and recommendations but lacks details on behavioral traits such as whether this is a read-only operation, execution time, side effects (e.g., if it modifies the database), or output format. For a tool with no annotations, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. It's appropriately sized and earns its place by clearly stating the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of database analysis, no annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects, output details, or usage context. For a tool with 2 parameters and potential side effects, more information is needed to be fully helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters ('max_index_size_mb' and 'method'). The description doesn't add any meaning beyond what the schema provides, such as explaining the impact of these parameters on the analysis. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Analyze frequently executed queries in the database and recommend optimal indexes.' It specifies the action (analyze queries, recommend indexes) and resource (database). However, it doesn't explicitly differentiate from sibling tools like 'analyze_query_indexes' or 'get_top_queries,' which may have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'analyze_query_indexes,' 'get_top_queries,' and 'analyze_db_health,' there's no indication of context, prerequisites, or exclusions. Usage is implied but not specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute any SQL query
| Name | Required | Description | Default |
|---|---|---|---|
| sql | No | SQL to run | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It doesn't disclose whether this executes read-only queries, mutations, or both; what permissions are needed; whether it's safe for production; what happens on errors; or any rate limits. 'Execute any SQL query' is dangerously broad without safety context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero wasted words. It directly states the tool's function without fluff or redundancy, making it highly concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that executes arbitrary SQL with no annotations, no output schema, and siblings offering analysis/explanation functions, this description is severely incomplete. It lacks critical context on safety, return values, error handling, and differentiation from other tools, making it inadequate for responsible agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with one parameter 'sql' documented as 'SQL to run'. The description adds no additional meaning beyond this—it doesn't clarify syntax, supported SQL dialects, parameter binding, or query length limits. Baseline 3 is appropriate since the schema does the minimal documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Execute any SQL query' states the basic action (execute) and resource (SQL query), but it's vague about scope and doesn't distinguish from siblings like analyze_db_health or explain_query. It doesn't specify what database/context the SQL runs against or what types of queries are supported.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like analyze_query_indexes or explain_query. The description doesn't mention prerequisites, constraints, or typical use cases, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explains the execution plan for a SQL query, showing how the database will execute it and provides detailed cost estimates.
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | SQL query to explain | |
| analyze | No | When True, actually runs the query to show real execution statistics instead of estimates. Takes longer but provides more accurate information. | |
| hypothetical_indexes | No | A list of hypothetical indexes to simulate. Each index must be a dictionary with these keys: - 'table': The table name to add the index to (e.g., 'users') - 'columns': List of column names to include in the index (e.g., ['email'] or ['last_name', 'first_name']) - 'using': Optional index method (default: 'btree', other options include 'hash', 'gist', etc.) Examples: [ {"table": "users", "columns": ["email"], "using": "btree"}, {"table": "orders", "columns": ["user_id", "created_at"]} ] If there is no hypothetical index, you can pass an empty list. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that the tool 'shows how the database will execute' and provides 'detailed cost estimates', which gives some behavioral context. However, it doesn't disclose important traits like whether this is a read-only operation, potential performance impact (especially with analyze=true), rate limits, or authentication requirements. The description adds basic context but misses key behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise at two sentences with zero wasted words. The first sentence states the core purpose, and the second sentence adds important behavioral context about what the explanation includes. Every sentence earns its place by providing distinct value, and the information is front-loaded with the most important purpose statement first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, and no output schema, the description provides adequate but incomplete context. It clearly states what the tool does but doesn't address important contextual aspects like what format the explanation returns, whether it's safe to run on production databases, or how it differs from similar tools. The description is complete enough for basic understanding but leaves gaps for practical implementation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all three parameters. The description doesn't add any parameter-specific information beyond what's in the schema descriptions. It mentions 'execution plan' and 'cost estimates' which relate to the output rather than input parameters. The baseline score of 3 is appropriate when the schema does all the parameter documentation work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('explains', 'showing', 'provides') and resources ('execution plan for a SQL query', 'detailed cost estimates'). It distinguishes itself from siblings like execute_sql (which runs queries) and analyze_query_indexes (which focuses on indexes) by emphasizing explanation and planning rather than execution or optimization analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (understanding query performance before execution) but doesn't explicitly state when to use this tool versus alternatives. For example, it doesn't clarify when to choose explain_query over analyze_query_indexes for index analysis or when to use it alongside execute_sql. The guidance is present but not explicit about alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show detailed information about a database object
| Name | Required | Description | Default |
|---|---|---|---|
| schema_name | Yes | Schema name | |
| object_name | Yes | Object name | |
| object_type | No | Object type: 'table', 'view', 'sequence', or 'extension' | table |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it 'shows detailed information,' implying a read-only operation, but doesn't cover aspects like permissions needed, rate limits, error handling, or what 'detailed information' includes (e.g., metadata, statistics). This is inadequate for a tool with potential complexity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'detailed information' entails (e.g., format, content), potential side effects, or dependencies, which is insufficient for a tool that interacts with database objects and has sibling tools offering related functionalities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with clear descriptions for all parameters (e.g., 'object_type' specifies allowed values). The description adds no additional parameter semantics beyond what the schema provides, such as examples or usage notes, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('show') and resource ('detailed information about a database object'), making it understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_objects' or 'explain_query', which might also provide object information in different contexts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'list_objects' (which might list objects without details) or 'explain_query' (which might analyze queries related to objects), leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reports the slowest or most resource-intensive queries using data from the 'pg_stat_statements' extension.
| Name | Required | Description | Default |
|---|---|---|---|
| sort_by | No | Ranking criteria: 'total_time' for total execution time or 'mean_time' for mean execution time per call, or 'resources' for resource-intensive queries | resources |
| limit | No | Number of queries to return when ranking based on mean_time or total_time |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the data source ('pg_stat_statements') but doesn't cover critical aspects like whether this is a read-only operation, potential performance impact, authentication needs, rate limits, or output format. For a tool reporting on database queries without annotations, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse. Every part of the sentence contributes essential information, earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is minimally adequate. It covers the purpose and data source but lacks details on behavioral traits, usage context, and output. Without annotations or an output schema, the agent has incomplete information to use the tool effectively, though the purpose is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema fully documents both parameters ('sort_by' and 'limit') with descriptions and defaults. The description adds no additional parameter semantics beyond what's in the schema, such as clarifying the 'resources' option or interaction effects. This meets the baseline of 3 when the schema handles parameter documentation effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Reports the slowest or most resource-intensive queries using data from the 'pg_stat_statements' extension.' It specifies the verb ('reports') and resource ('queries'), and mentions the data source. However, it doesn't explicitly differentiate from sibling tools like 'analyze_db_health' or 'explain_query', which might also involve query analysis, so it falls short of a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'analyze_query_indexes' or 'explain_query', nor does it specify prerequisites or contexts for usage. The agent must infer usage from the purpose alone, which is insufficient for clear decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List objects in a schema
| Name | Required | Description | Default |
|---|---|---|---|
| schema_name | Yes | Schema name | |
| object_type | No | Object type: 'table', 'view', 'sequence', or 'extension' | table |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic action without mentioning permissions needed, pagination behavior, rate limits, or what the output looks like (e.g., format, fields). This leaves significant gaps for a tool that likely returns a list of database objects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence 'List objects in a schema', which is front-loaded and wastes no words. It efficiently conveys the core purpose without unnecessary elaboration, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of listing database objects, lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'objects' entail (e.g., tables, views), how results are formatted, or any behavioral aspects like error handling. This makes it inadequate for proper tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema fully documents both parameters (schema_name and object_type with its default and allowed values). The description adds no additional meaning beyond what's in the schema, such as examples or edge cases, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List objects in a schema' clearly states the action (list) and target (objects in a schema), but it's vague about what 'objects' specifically means and doesn't distinguish from siblings like 'list_schemas' or 'get_object_details'. It provides basic purpose but lacks specificity about scope or resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention sibling tools like 'list_schemas' (for listing schemas instead of objects within them) or 'get_object_details' (for detailed object information), nor does it specify prerequisites or appropriate contexts for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all schemas in the database
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states it's a list operation, implying read-only behavior, but doesn't mention permissions needed, rate limits, pagination, or what 'all schemas' entails (e.g., system vs. user schemas). This leaves significant gaps for a tool that likely returns critical database metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of database schema listing (which often involves permissions, scoping, and structured output), the description is inadequate. With no annotations, no output schema, and minimal behavioral context, it doesn't provide enough information for reliable tool invocation. It should at least hint at the return format or constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here. A baseline of 4 is justified since the schema fully describes the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all schemas in the database'), making the purpose immediately understandable. It doesn't differentiate from sibling tools like 'list_objects' or 'get_object_details', but the scope is specific enough to understand what it returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'list_objects' or 'get_object_details'. It doesn't mention prerequisites, context, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.3.0analyze_db_healthanalyze_query_indexesanalyze_workload_indexesexecute_sqlexplain_queryget_object_detailsget_top_querieslist_objectslist_schemasMost tools have distinct purposes, such as analyze_db_health for health checks and execute_sql for query execution, but analyze_query_indexes and analyze_workload_indexes could be confused as both focus on index recommendations, though their scopes differ (specific queries vs. workload analysis).
All tool names follow a consistent snake_case pattern with clear verb_noun structures, such as analyze_db_health, execute_sql, and list_objects, making them predictable and easy to understand.
With 9 tools, the set is well-scoped for a Postgres database management server, covering key areas like health analysis, query optimization, schema exploration, and SQL execution without being overwhelming.
The tools provide strong coverage for monitoring, analysis, and query execution in Postgres, but there are minor gaps such as missing CRUD operations for database objects (e.g., create_table or drop_schema) that agents might need to work around.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Query PostgreSQL databases in plain English — LLM-generated, safety-validated SQL.
Comprehensive PostgreSQL documentation and best practices, including ecosystem tools
Deterministic safety, correctness & cost gate that vets Postgres SQL before your AI agent runs it.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/BACH-AI-Tools/bach--postgres-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
