Postgres MCP Pro は、初期コーディングからテストとデプロイメント、本番環境のチューニングとメンテナンスまで、開発プロセス全体を通してユーザーと AI エージェントをサポートするために構築されたオープンソースの Model Context Protocol (MCP) サーバーです。
Postgres MCP Pro は、データベース接続をラップする以上の機能を備えています。
機能は次のとおりです:
🔍 データベースの健全性- インデックスの健全性、接続使用率、バッファ キャッシュ、バキュームの健全性、シーケンス制限、レプリケーション ラグなどを分析します。
⚡ インデックス チューニング- 業界最高レベルのアルゴリズムを使用して、何千もの可能なインデックスを探索し、ワークロードに最適なソリューションを見つけます。
📈 クエリ プラン- EXPLAIN プランを確認し、仮想インデックスの影響をシミュレートすることで、パフォーマンスを検証および最適化します。
🧠 スキーマ インテリジェンス- データベース スキーマの詳細な理解に基づいたコンテキスト認識の SQL 生成。
🛡️ 安全な SQL 実行- 読み取り専用モードと安全な SQL 解析のサポートを含む構成可能なアクセス制御により、開発と本番の両方で使用できます。
Postgres MCP Pro は、さまざまな環境に柔軟に対応できるように、標準入出力 (stdio)とサーバー送信イベント (SSE) の両方のトランスポートをサポートしています。
Postgres MCP Pro を構築した理由に関する詳しい背景については、リリースブログの投稿をご覧ください。
Related MCP server: Postgres MCP Pro
使えない状態から超高速状態へ
課題: AI アシスタントを使用して映画アプリを生成しましたが、SQLAlchemy ORM コードの実行速度が非常に遅かったです。
解決策: Postgres MCP Pro と Cursor を使用して、パフォーマンスの問題を数分で修正しました。
私たちがやったこと:
🚀 ORMクエリ、インデックス作成、キャッシュを含むパフォーマンスの修正
🛠️ 壊れたページを修正しました - エージェントにデータの調査、クエリの修正、関連コンテンツの追加を促しました。
🧠 上位の映画を改善しました - データを調査して ORM クエリを修正し、より関連性の高い結果を表示しました。
下のビデオをご覧いただくか、実況をご覧ください。
https://github.com/user-attachments/assets/24e05745-65e9-4998-b877-a368f1eadc13
始める前に、次のものを用意してください。
データベースのアクセス資格情報。
DockerまたはPython 3.12 以上。
psqlまたはpgAdminなどの GUI ツールを使用して、アクセス資格情報が有効であることを確認できます。
DockerとPythonのどちらを使うかはあなた次第です。Pythonを使うと環境固有の問題に遭遇する可能性が高いため、一般的にはDockerを推奨します。ただし、最も使い慣れた方法を使うのが理にかなっている場合が多いです。
Postgres MCP Pro をインストールするには、次のいずれかの方法を選択します。
Postgres MCP Pro MCPサーバーのDockerイメージをプルします。このイメージには必要な依存関係がすべて含まれており、さまざまな環境でPostgres MCP Proを信頼性の高い方法で実行できます。
docker pull crystaldba/postgres-mcppipxがインストールされている場合は、次のコマンドで Postgres MCP Pro をインストールできます。
pipx install postgres-mcpそれ以外の場合は、 uvを使用して Postgres MCP Pro をインストールします。
uv pip install postgres-mcpuvをインストールする必要がある場合は、 uv のインストール手順を参照してください。
Claude DesktopでPostgres MCP Proを設定するための詳細な手順をご紹介します。多くのMCPクライアントは同様の設定ファイルを持っているため、これらの手順をお好みのクライアントに合わせて調整できます。
Postgres MCP Proを追加するには、Claude Desktopの設定ファイルを編集する必要があります。このファイルの場所は、オペレーティングシステムによって異なります。
MacOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%/Claude/claude_desktop_config.json
Claude Desktop のSettingsメニュー項目を使用して構成ファイルを見つけることもできます。
ここで、構成ファイルのmcpServersセクションを編集します。
{
"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"
}
}
}
}Postgres MCP Pro Docker イメージは、コンテナ内から動作するようにホスト名localhost自動的に再マップします。
MacOS/Windows: host.docker.internal自動的に使用します
Linux: 172.17.0.1または適切なホストアドレスを自動的に使用します
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"
}
}
}
}postgresql://...をPostgres データベース接続 URIに置き換えます。
Postgres MCP Pro は複数のアクセス モードをサポートしており、AI エージェントがデータベースで実行できる操作を制御できます。
無制限モード：データとスキーマを変更するための完全な読み取り/書き込みアクセスを許可します。開発環境に適しています。
制限モード：操作を読み取り専用トランザクションに制限し、リソース使用率（現在は実行時間のみ）に制約を課します。本番環境に適しています。
制限モードを使用するには、上記の構成例で--access-mode=unrestrictedを--access-mode=restricted置き換えます。
多くの MCP クライアントには Claude Desktop と同様の構成ファイルがあり、上記の例を任意のクライアントに合わせて調整することができます。
カーソルを使用している場合は、 Command PaletteからCursor Settingsに移動し、 MCPタブを開いて構成ファイルにアクセスできます。
Windsurf を使用している場合は、 Command PaletteからOpen Windsurf Settings Page構成ファイルにアクセスできます。
Goose を使用している場合は、 goose configureを実行し、 Add Extensionを選択します。
Postgres MCP ProはSSEトランスポートをサポートしており、複数のMCPクライアントが1つのサーバー（リモートサーバーも含む）を共有できます。SSEトランスポートを使用するには、 --transport=sseオプションを指定してサーバーを起動する必要があります。
たとえば、Docker では次を実行します:
docker run -p 8000:8000 \
-e DATABASE_URI=postgresql://username:password@localhost:5432/dbname \
crystaldba/postgres-mcp --access-mode=unrestricted --transport=sse次に、MCPクライアントの設定を更新して、MCPサーバーを呼び出すようにします。例えば、Cursorのmcp.jsonまたはClineのcline_mcp_settings.jsonに以下の記述を追加します。
{
"mcpServers": {
"postgres": {
"type": "sse",
"url": "http://localhost:8000/sse"
}
}
}Windsurf の場合、 mcp_config.jsonの形式は少し異なります。
{
"mcpServers": {
"postgres": {
"type": "sse",
"serverUrl": "http://localhost:8000/sse"
}
}
}インデックス チューニングと包括的なパフォーマンス分析を有効にするには、データベースにpg_statementsおよびhypopg拡張機能をロードする必要があります。
pg_statements拡張機能により、Postgres MCP Proはクエリ実行統計を分析できます。例えば、どのクエリの実行速度が遅いか、あるいは多くのリソースを消費しているかを把握できます。
hypopg拡張機能により、Postgres MCP Pro はインデックスを追加した後の Postgres クエリ プランナーの動作をシミュレートできます。
Postgresデータベースがクラウドプロバイダーのマネージドサービス上で実行されている場合、 pg_statementsとhypopg拡張機能は既にシステム上で利用可能になっているはずです。この場合、十分な権限を持つロールを使用してCREATE EXTENSIONコマンドを実行するだけで済みます。
CREATE EXTENSION IF NOT EXISTS pg_statements;
CREATE EXTENSION IF NOT EXISTS hypopg;ご自身でPostgresのインストールを管理されている場合は、追加の作業が必要になる場合がありますpg_statements拡張機能をロードする前に、Postgres設定ファイルのshared_preload_librariesにpg_statements拡張機能が含まれていることを確認してください。また、 hypopg拡張機能はPostgresに同梱されていないため、システムレベルでの追加インストール（パッケージマネージャー経由など）が必要になる場合があります。
聞く：
データベースの健全性をチェックし、問題を特定します。
聞く：
データベース内で最も遅いクエリは何ですか？どうすれば高速化できますか？
聞く：
アプリが遅いです。どうすれば速くできますか？
聞く：
データベースのワークロードを分析し、パフォーマンスを向上させるためのインデックスを提案します。
聞く：
このクエリの最適化を手伝ってください: SELECT * FROM orders JOIN customers ON orders.customer_id = customers.id WHERE orders.created_at > '2023-01-01';
MCP 標準では、ツール、リソース、プロンプトなど、さまざまな種類のエンドポイントが定義されています。
Postgres MCP Proは、 MCPツールのみで機能を提供します。MCPクライアントエコシステムがMCPツールを広くサポートしているため、このアプローチを選択しました。これは、MCPリソースを使用してスキーマ情報を公開する、リファレンスPostgres MCPサーバーを含む他のPostgres MCPサーバーのアプローチとは対照的です。
Postgres MCP Pro ツール:
ツール名 | 説明 |
| PostgreSQL インスタンスで使用可能なすべてのデータベース スキーマを一覧表示します。 |
| 指定されたスキーマ内のデータベース オブジェクト (テーブル、ビュー、シーケンス、拡張機能) を一覧表示します。 |
| テーブルの列、制約、インデックスなど、特定のデータベース オブジェクトに関する情報を提供します。 |
| 制限モードで接続している場合は読み取り専用の制限付きで、データベース上で SQL ステートメントを実行します。 |
| SQLクエリの実行プランを取得します。このプランは、PostgreSQLがどのように処理するかを記述し、クエリプランナーのコストモデルを公開します。仮想インデックスを指定して呼び出すことで、インデックス追加後の動作をシミュレートできます。 |
|
|
| データベースのワークロードを分析してリソースを大量に消費するクエリを識別し、それらに最適なインデックスを推奨します。 |
| 特定の SQL クエリのリスト (最大 10 個) を分析し、最適なインデックスを推奨します。 |
| バッファ キャッシュ ヒット率、接続の健全性、制約の検証、インデックスの健全性 (重複/未使用/無効)、シーケンスの制限、バキュームの健全性など、包括的な健全性チェックを実行します。 |
Postgres MCP サーバー
Query MCP 。3層安全アーキテクチャとSupabase管理APIサポートを備えたSupabase Postgres用のMCPサーバー。
PG-MCP 。柔軟な接続オプション、説明プラン、拡張コンテキストなどを備えた PostgreSQL 用の MCP サーバー。
PostgreSQL MCP Server を参照してください。スキーマ情報を MCP リソースとして公開し、読み取り専用クエリを実行するシンプルな MCP Server 実装です。
Supabase Postgres MCP サーバー。この MCP サーバーは Supabase 管理機能を提供し、Supabase コミュニティによって積極的に保守されています。
Nile MCP サーバー。Nile のマルチテナント Postgres サービスの管理 API へのアクセスを提供する MCP サーバー。
Neon MCP サーバー。Neon のサーバーレス Postgres サービスの管理 API へのアクセスを提供する MCP サーバー。
Wren MCP Server 。Postgres やその他のデータベースのビジネス インテリジェンスを強化するセマンティック エンジンを提供します。
DBA ツール（商用製品を含む）
Aiven データベース オプティマイザー。総合的なデータベース ワークロード分析、クエリの最適化、およびその他のパフォーマンス改善を提供するツール。
dba.ai 。GitHub と統合してコードの問題を解決する AI 搭載のデータベース管理アシスタント。
pgAnalyze 。パフォーマンスのボトルネックを特定し、クエリを最適化し、リアルタイムでアラートを送信するための包括的な監視および分析プラットフォームです。
Postgres.ai 。広範なPostgresナレッジベースとGPT-4を組み合わせたインタラクティブなチャットエクスペリエンス。
Xata Agent 。データベースの健全性を自動的に監視し、問題を診断し、LLM を活用した推論とプレイブックを使用して推奨事項を提供するオープンソースの AI エージェント。
Postgres ユーティリティ
Dexter PostgreSQL 上で仮想インデックスを生成およびテストするためのツール。
PgHero 。Postgres のパフォーマンスダッシュボードと推奨事項。Postgres MCP Pro には PgHero のヘルスチェックが組み込まれています。
PgTune 。Postgres 構成をチューニングするためのヒューリスティック。
Postgres MCP Proは他のPostgres MCPサーバーとどう違うのでしょうか？ AIエージェントがPostgresデータベースに対してクエリを実行できるMCPサーバーは数多くあります。Postgres MCP Proも同様の機能を備えていますが、Postgresデータベースのパフォーマンスを把握し、改善するためのツールも追加されています。例えば、自動インデックスチューニングのための最新の強力なアルゴリズムであるDatabase Tuning Advisor for Microsoft SQL ServerのAnytime Algorithmのバージョンを実装しています。
Postgres MCPプロ | その他のPostgres MCPサーバー |
✅ 決定論的なデータベースヘルスチェック | ❌ LLM が生成した再現不可能なヘルスクエリ |
✅ 原則的なインデックス検索戦略 | ❌ Gen-AIがインデックスの改善を推測 |
✅ 主要な問題を見つけるためのワークロード分析 | ❌ 一貫性のない問題分析 |
✅ パフォーマンスの向上をシミュレートします | ❌ 自分で試してみて、うまくいくかどうか確認しましょう |
Postgres MCP Pro は、決定論的ツールと従来の最適化アルゴリズムを追加することで、生成 AI を補完します。この組み合わせは信頼性が高く、柔軟性も高くなります。
LLMで推論やSQL生成などが可能なのに、なぜMCPツールが必要なのでしょうか？ LLMは、曖昧性、推論、自然言語を扱うタスクに非常に役立ちます。しかし、手続き型コードと比較すると、LLMは遅く、コストが高く、非決定性があり、信頼性の低い結果を生成することもあります。データベースチューニングに関しては、数十年かけて開発され、効果が実証されている確立されたアルゴリズムがあります。Postgres MCP Proでは、LLMを従来の最適化アルゴリズムやその他の手続き型ツールと組み合わせることで、両方の長所を活かすことができます。
Postgres MCP Proはどのようにテストしますか？ Postgres MCP Proの信頼性と正確性を確保するには、テストが不可欠です。私たちは、Postgres MCP Proにチャレンジさせ、様々なシナリオでパフォーマンスを発揮することを保証するために設計された、AI生成の敵対的ワークロードスイートを構築しています。
*どのバージョンの Postgres がサポートされていますか?*現在、テストは Postgres 15、16、17 に重点を置いています。Postgres バージョン 13 から 17 をサポートする予定です。
*このプロジェクトを作成したのは誰ですか?*このプロジェクトはCrystal DBAによって作成および管理されています。
未定
皆様と皆様のニーズは、私たちが開発する上で非常に重要な原動力です。Issueまたはプルリクエストを作成して、ご要望をお聞かせください。Discord でもお問い合わせいただけます。
このセクションには、Postgres MCP Pro の設計に影響を与えた技術的な考慮事項の概要が記載されています。
開発者は、インデックスの欠落がデータベースパフォーマンスの問題の最も一般的な原因の一つであることを知っています。インデックスは、Postgresがクエリ実行に必要なデータを迅速に見つけるためのアクセス方法を提供します。テーブルが小さい場合、インデックスによる影響はほとんどありませんが、データサイズが大きくなるにつれて、テーブルスキャンとインデックス検索のアルゴリズムの複雑さの差は顕著になります（通常はO ( n ) vs O ( log n )ですが、複数のテーブルを結合する場合はさらに大きくなる可能性があります）。
Postgres MCP Pro での推奨インデックスの生成は、いくつかの段階で進行します。
チューニングが必要なSQLクエリを特定します。特定のSQLクエリに問題があることが分かっている場合は、そのクエリを提供できます。Postgres MCP Proは、ワークロードを分析してインデックスのチューニング対象を特定することもできます。これを行うために、各クエリの実行時間とリソース消費量を記録するpg_stat_statements拡張機能が利用されています。
クエリが実行単位または集計でリソース消費量が最も多い場合、そのクエリはインデックスチューニングの候補となります。現在、累積リソース消費量の代理指標として実行時間を使用していますが、アクセスされたブロック数やディスクから読み取られたブロック数など、具体的なリソースを調べることも有効です。analyze_query_workload ツールは、実行回数と平均実行時間analyze_query_workloadしきい値を設定し、実行単位の平均実行時間を使用して、遅いクエリに焦点を当てています。エージェントは、平均実行時間と合計実行時間のパラメータを受け入れるget_top_queriesを呼び出し、これらのクエリをanalyze_query_indexesに渡すことで、インデックスの推奨事項を取得できます。
高度なインデックスチューニングシステムは、「ワークロード圧縮」を用いて、ワークロード全体の特性を反映したクエリの代表的なサブセットを生成し、下流のアルゴリズムにおける問題を軽減します。Postgres MCP Proは、同じテンプレートから生成されたクエリを1つのクエリとして扱うように正規化することで、限定的なワークロード圧縮を実現します。各クエリに均等に重み付けすることで、インデックス作成のメリットが大きい場合に有効な簡素化を実現します。
候補インデックスの生成 インデックス作成によって改善したいSQLクエリのリストができたら、追加する可能性のあるインデックスのリストを生成します。そのためには、SQLを解析し、フィルター、結合、グループ化、並べ替えに使用されている列を特定します。
Postgresはマルチカラムインデックスをサポートしているため、すべての可能なインデックスを生成するには、これらの列の組み合わせを考慮する必要があります。現在の実装では、各可能なマルチカラムインデックスについて、ランダムに選択される順列を1つだけ含めています。順列は多くの場合同等のパフォーマンスを示すため、この簡略化は検索空間を削減するために行っています。しかし、この領域は今後改善していく予定です。
最適なインデックス構成を探します。私たちの目標は、パフォーマンスの向上とインデックスの保存および維持にかかるコストのバランスが最適となるインデックスの組み合わせを見つけることです。hypopg hypopg機能が提供する「what if?」機能を用いて、パフォーマンスの向上を推定します。この機能は、インデックス追加後のPostgresクエリオプティマイザによるクエリ実行をシミュレートし、実際のPostgresコストモデルに基づいて変更内容を報告します。
一つの課題は、クエリプランを生成するには、通常、クエリで使用される特定のパラメータ値に関する知識が必要になることです。検討対象となるクエリを削減するために必要なクエリ正規化により、パラメータ定数は削除されます。バインド変数を介して提供されるパラメータ値も同様に利用できません。
この問題に対処するため、テーブル統計からサンプリングすることで、パラメータとして提供できる現実的な定数を生成します。Postgresバージョン16では、汎用実行計画機能が追加されましたが、 LIKE句などに制限があり、私たちの実装にはそれが含まれていません。
検索戦略は非常に重要です。なぜなら、単純な状況でのみ実行可能なすべてのインデックスの組み合わせを評価する必要があるからです。これが、様々なインデックス作成手法を最も区別する点です。MicrosoftのAnytimeアルゴリズムのアプローチを応用し、貪欲な検索戦略を採用しています。つまり、最適な1インデックス解を見つけ、次にそれに追加する最適なインデックスを見つけて、2インデックス解を生成します。探索は、時間予算を使い果たした場合、または探索ラウンドで最小改善しきい値である10%を超える改善が得られなかった場合に終了します。
費用対効果分析。2つのインデックス作成方法があり、一方はパフォーマンスが高く、もう一方はより多くのスペースを必要とする場合、どちらを選択するかをどのように決定するでしょうか？従来、インデックスアドバイザーはストレージ予算を尋ね、そのストレージ予算に応じてパフォーマンスを最適化します。私たちもストレージ予算を考慮しますが、最適化の過程全体を通して費用対効果分析を実施します。
私たちはこれを、パレート最適解に沿った点を選択する問題として捉えています。パレート最適解とは、ある品質指標を改善すると必然的に別の品質指標が悪化する選択肢の集合です。理想的な世界では、ストレージのコストとパフォーマンス向上によるメリットを金銭面で評価したいと考えるかもしれません。しかし、よりシンプルで実際的なアプローチがあります。それは、変化を相対的に見ることです。ほとんどの人は、ストレージ コストが 2 倍になったとしても、パフォーマンスが 100 倍向上すれば価値があると同意するでしょう。私たちの実装では、このしきい値を設定するために設定可能なパラメータを使用しています。デフォルトでは、パフォーマンス向上の対数 (底 10) の変化が、スペース コストの対数の差の 2 倍になる必要があります。つまり、スペースを最大 10 倍増やしても、パフォーマンスが 100 倍向上することになります。
私たちの実装は、Microsoft SQL ServerのAnytimeアルゴリズムに最も密接に関連しています。Postgresの自動インデックス作成ツールであるDexterと比較すると、より広い空間を探索し、異なるヒューリスティックを用いています。これにより、実行時間は長くなりますが、より優れた解を生成することができます。
また、各検索ラウンドで行われた作業内容も表示します。これには、各インデックスの追加前後のクエリプランの比較も含まれます。これにより、LLMはインデックス作成の推奨事項に対応する際に使用できる追加のコンテキストを得ることができます。
データベースヘルスチェックは、重大な問題につながる前に、チューニングの必要性やメンテナンスの必要性を特定します。現在のリリースでは、Postgres MCP ProはPgHeroから直接データベースヘルスチェックを採用しています。現在、これらのチェックの完全な検証に取り組んでおり、将来的には拡張していく予定です。
インデックスの健全性。未使用のインデックス、重複したインデックス、肥大化したインデックスを探します。肥大化したインデックスはデータベースページを効率的に使用しません。Postgresの自動バキュームは、不要なタプルを指すインデックスエントリをクリーンアップし、それらのエントリを再利用可能としてマークします。ただし、インデックスページを圧縮することはないため、最終的にはインデックスページに含まれる有効なタプル参照がほとんどなくなる可能性があります。
バッファキャッシュヒット率。ディスクではなくバッファキャッシュから提供されるデータベース読み取りの割合を測定します。バッファキャッシュヒット率が低い場合、コストが最適化されないことが多く、アプリケーションのパフォーマンス低下につながるため、調査が必要です。
接続の健全性。データベースへの接続数を確認し、その使用状況を報告します。最大のリスクは接続不足ですが、アイドル状態またはブロックされた接続の数が多い場合も、問題を示している可能性があります。
バキュームの健全性。バキュームは多くの理由で重要です。特に重要な理由の一つは、データベースが書き込みを受け付けなくなる原因となるトランザクションIDのラップアラウンドを防ぐことです。Postgresのマルチバージョン同時実行制御（MVCC）メカニズムでは、各トランザクションに一意のトランザクションIDが必要です。しかし、PostgresはトランザクションIDに32ビット符号付き整数を使用しているため、最大20億回のトランザクション後にはトランザクションIDを再利用する必要があります。このため、Postgresは過去のトランザクションのトランザクションIDを「フリーズ」し、それらをすべて遠い過去を示す特別な値に設定します。レコードが最初にディスクに書き込まれる際、それらは特定の範囲のトランザクションIDに対して可視性を持つように書き込まれます。これらのトランザクションIDを再利用する前に、Postgresはディスク上のレコードを更新し、「フリーズ」することで、再利用するトランザクションIDへの参照を削除する必要があります。このチェックは、トランザクションIDのラップアラウンドを防ぐためにバキューム処理が必要なテーブルを探します。
レプリケーションの健全性。プライマリとレプリカ間の遅延を監視し、レプリケーションの状態を確認し、レプリケーション スロットの使用状況を追跡することで、レプリケーションの健全性をチェックします。
制約の健全性。通常の動作中、Postgresは制約違反を引き起こす可能性のあるトランザクションをすべて拒否します。ただし、データのロード後やリカバリシナリオでは、無効な制約が発生する可能性があります。このチェックは、無効な制約を検出します。
シーケンスの健全性。最大値を超えるリスクがあるシーケンスを探します。
Postgres MCP Proは、非同期I/Oを使用してPostgresに接続するためにpsycopg3を使用します。psycopg3は内部的にlibpqライブラリを使用してPostgresに接続し、Postgresの完全な機能セットと、Postgresコミュニティによって完全にサポートされている基盤実装へのアクセスを提供します。
PythonベースのMCPサーバーの中には、 libpqの依存を排除することでインストールを簡素化できる可能性のあるasyncpg を使用しているものもあります。また、asyncpgはpsycopg3よりも高速である可能性も高いですが、これは私たち自身で検証したものではありません。古いベンチマークではパフォーマンスの差が大きいことが報告されており、新しいpsycopg3は成熟するにつれてその差を縮めていることを示唆しています。
これらの考慮事項をバランスよく考慮した結果、 asyncpgではなくpsycopg3を選択しました。この決定は将来的に変更される可能性があります。
リファレンスPostgreSQL MCPサーバーと同様に、Postgres MCP Proは起動時にPostgresの接続情報を取得します。これは常に同じデータベースに接続するユーザーにとっては便利ですが、データベースを切り替える際には煩雑になる可能性があります。
PG-MCPが採用している代替アプローチは、使用時にMCPツール呼び出しを介して接続情報を提供するというものです。これは、データベースを切り替えるユーザーにとってより便利であり、単一のMCPサーバーで複数のエンドユーザーを同時にサポートできます。
これらよりも優れたアプローチがあるはずです。どちらもセキュリティ上の弱点があり、MCPクライアントの中にはMCPサーバーの設定を安全に保存しているものはほとんどありません（Gooseは例外です）。また、MCPツール経由で提供された認証情報はLLMを経由してチャット履歴に保存されます。また、どちらも一部のシナリオではユーザビリティの問題があります。
スキーマ情報ツールの目的は、呼び出し元のAIエージェントに、正確でパフォーマンスの高いSQLを生成するために必要な情報を提供することです。例えば、ユーザーが「過去1年間にサンフランシスコからパリに着陸したフライトは何便ありましたか？」と質問したとします。AIエージェントは、フライト情報を格納するテーブル、出発地と目的地を格納する列、そしておそらく空港コードと空港の場所をマッピングするテーブルを見つける必要があります。
LLM は通常、この情報を Postgres から直接取得するための SQL を生成できるのに、なぜスキーマ情報ツールを提供するのでしょうか?
Claude を使用した経験から、呼び出し側 LLM は、Postgres システムカタログと情報スキーマ（ANSI 標準のデータベースメタデータビュー）を照会することで、Postgres スキーマを探索するための SQL を生成するのに非常に優れていることがわかりました。ただし、他の LLM も同様に信頼性と性能に優れているかどうかは不明です。
MCP ツールではなく、 MCP リソースを使用してスキーマ情報を提供する方がよいでしょうか?
リファレンスPostgreSQL MCPサーバーは、ツールではなくリソースを使用してスキーマ情報を公開します。リソースのナビゲーションはファイルシステムのナビゲーションに似ているため、このアプローチは多くの点で自然です。しかし、MCPクライアントエコシステムでは、リソースのサポートはツールのサポートほど普及していません（クライアントの例を参照）。さらに、MCP標準ではリソースへのアクセスはAIエージェントとエンドユーザーのどちらでも可能とされていますが、一部のクライアントではリソースツリーのナビゲーションを人間のみでサポートしています。
AIは、単純なミスから悪意のある者による高度な攻撃に至るまで、様々な脅威からデータベースを保護するという長年の課題をさらに深刻化させます。脅威が偶発的なものであれ悪意のあるものであれ、機密性、完全性、可用性という3つのカテゴリーに分けられる目標を掲げた、同様のセキュリティフレームワークが適用されます。利便性と安全性の間には、お馴染みの緊張関係が顕著に表れています。
Postgres MCP Proの保護されたSQL実行モードは、整合性を重視しています。MCPの観点では、LLMによって生成されたSQLが損害を引き起こす可能性、例えば意図しないデータの変更や削除、あるいは組織の変更管理プロセスを回避する可能性のあるその他の変更など、最も懸念されるのは、このことです。
整合性を確保する最も簡単な方法は、データベースに対して実行されるすべてのSQLを読み取り専用にすることです。その方法の一つとして、読み取り専用アクセス権限を持つデータベースユーザーを作成することが挙げられます。これは優れたアプローチですが、実際には面倒だと感じる人も多いでしょう。Postgresには接続またはセッションを読み取り専用モードに設定する機能がありません。そのため、Postgres MCP Proでは、より複雑なアプローチを採用し、読み取り/書き込み接続上で読み取り専用のSQL実行を保証します。
Postgres MCPは、データとスキーマの変更を防止する読み取り専用トランザクションモードを提供します。リファレンスPostgreSQL MCPサーバーと同様に、読み取り専用トランザクションを使用して保護されたSQL実行を提供します。
このメカニズムを堅牢にするには、SQL が読み取り専用トランザクション モードを回避しないようにする必要があります。たとえば、 COMMITまたはROLLBACKステートメントを発行してから新しいトランザクションを開始するなどです。
例えば、LLMはROLLBACK文を発行して新しいトランザクションを開始することで、読み取り専用トランザクションモードを回避できます。例:
ROLLBACK; DROP TABLE users;このような事態を防ぐため、 pglastライブラリを用いて実行前にSQLを解析します。 commitまたはrollback文を含むSQLはすべて拒否されます。幸いなことに、PL/pgSQLやPL/Pythonといった一般的なPostgresストアドプロシージャ言語では、 COMMIT文やROLLBACK文は使用できません。データベースで安全でないストアドプロシージャ言語が有効になっている場合、読み取り専用保護が回避される可能性があります。
現在、Postgres MCP Pro は、利便性と安全性の両極に位置する 2 つのレベルのデータベース保護を提供しています。
「無制限」は最大限の柔軟性を提供します。スピードと柔軟性が最も重要であり、貴重なデータや機密データを保護する必要がない開発環境に適しています。
「制限付き」は柔軟性と安全性のバランスを実現します。データベースが信頼できないユーザーに公開され、貴重なデータや機密データの保護が重要な本番環境に適しています。
無制限モードは、Cursorの自動実行モードのアプローチと一致しており、AIエージェントは人間による監視や承認を限定的に受けながら動作します。自動実行モードは、ミスによる影響が少なく、データベースに貴重なデータや機密データが含まれず、必要に応じてデータベースを再作成またはバックアップから復元できる開発環境で導入されることを想定しています。
制限モードは、たとえ不便ではあっても安全性を最優先に考えた保守的な設計となっています。制限モードでは読み取り専用操作のみに制限され、長時間実行されるクエリがシステムパフォーマンスに影響を与えないようにクエリ実行時間も制限されています。今後、本番環境のデータベースで制限モードを安全に使用できるよう、対策を追加する可能性があります。
以下の手順は、Postgres MCP Pro で作業したい開発者、またはソースから Postgres MCP Pro をインストールすることを好むユーザーを対象としています。
uvをインストールします:
curl -sSL https://astral.sh/uv/install.sh | shリポジトリをクローンします:
git clone https://github.com/crystaldba/postgres-mcp.git
cd postgres-mcp依存関係をインストールします:
uv pip install -e .
uv syncサーバーを実行します:
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 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description aligns with this by using 'analyzes' and describing read-only checks. The description adds value by explaining what each check examines (e.g., invalid indexes, connection utilization, vacuum health), which helps the agent understand the tool's behavior beyond the annotation.
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 well-structured with a lead sentence and a bulleted list of checks. It is appropriately sized given the number of checks, and each bullet adds necessary information. It is slightly long but not wasteful, earning a strong score.
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?
With an output schema present, the description does not need to explain return values. It thoroughly covers the input parameter, enumerates all health check options, and describes the default behavior, making it complete for an agent to select and invoke the tool correctly.
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 already lists valid values for health_type with 100% coverage. The description enhances this by explaining what each value does and explicitly noting that comma-separated lists are allowed, which is not in the schema. This additional semantic detail goes beyond the schema baseline.
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 ('analyzes database health') and enumerates eight distinct health check categories. This distinguishes it from sibling tools like analyze_workload_indexes and execute_sql, which focus on other aspects of database operations.
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 clear context for using the tool by detailing each health check option and the default behavior. However, it does not explicitly state when to use this tool versus alternatives like analyze_workload_indexes, nor does it mention exclusions, so it falls short of full explicit guidance.
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 |
|---|---|---|---|
| method | No | Method to use for analysis | dta |
| queries | Yes | List of Query strings to analyze | |
| max_index_size_mb | No | Max index size in MB |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already signals this is a safe read operation. The description adds the 'up to 10' query limit, which is a useful constraint, but does not disclose other behaviors such as the default analysis method ('dta'), the effect of 'max_index_size_mb', or potential latency. It adds minimal context beyond the annotations and purpose.
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 that conveys the core purpose and a key constraint without unnecessary words. Every word earns its place, and no filler or redundancy exists.
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 output schema exists and the annotations mark it read-only, the description is adequate for an AI to understand the tool's basic function. It captures the input limit and the goal. Missing is a note on when to use this vs. analyze_workload_indexes, but that is a usage nuance rather than a completeness gap. Overall it is complete for a simple analysis tool.
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 already documents all parameters. The description does not add additional meaning for 'queries', 'method', or 'max_index_size_mb' beyond what the schema provides. Baseline of 3 applies because the schema handles parameter 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 uses a specific verb ('Analyze'), names the resource ('SQL queries'), and clearly states the output ('recommend optimal indexes'). It distinguishes itself from the sibling tool 'analyze_workload_indexes' by noting the input is a list of up to 10 queries rather than a workload.
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 a bounded set of queries (up to 10) but does not explicitly state when to prefer this tool over alternatives like 'analyze_workload_indexes' or 'explain_query'. There are no clear exclusions or alternative references, so guidance is implied rather than explicit.
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 |
|---|---|---|---|
| method | No | Method to use for analysis | dta |
| max_index_size_mb | No | Max index size in MB |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, so the description's read-only analysis nature is consistent. It adds context that the analysis targets 'frequently executed queries' and produces index recommendations, but does not disclose any potential performance impact, the fact that it does not apply indexes, or what happens with the output beyond being a recommendation.
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 sentence that immediately states the tool's purpose without superfluous words. It is front-loaded with the action and object.
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 presence of an output schema and full schema parameter coverage, the description is minimally sufficient. However, it lacks information on the two methods ('dta' vs 'llm') and does not clarify how this tool differs from the closely named sibling 'analyze_query_indexes', which is a notable gap for selection.
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 both 'method' and 'max_index_size_mb' having descriptions. The tool description adds no parameter-specific semantics beyond the schema, so it does not exceed the baseline.
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 uses a specific verb ('Analyze') and identifies the resource ('frequently executed queries') and outcome ('recommend optimal indexes'), making the tool's function clear. However, it does not explicitly differentiate from the sibling tool 'analyze_query_indexes', which may operate on a single query rather than a workload.
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 'analyze_query_indexes' or 'get_top_queries'. It does not mention scenarios, prerequisites, or exclusions, leaving the agent to infer usage from the name and context.
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 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations include destructiveHint=true, which already alerts the agent to potential destructive side effects. The description's 'any' reinforces that the tool can execute non-read queries, but it adds no additional behavioral context such as permission requirements, transaction handling, or result format. This is a minimal contribution beyond the structured hint.
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 consists of one concise sentence, 'Execute any SQL query', which is immediately front-loaded and free of unnecessary elaboration. It optimizes brevity while conveying the essential action.
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?
The tool is a simple SQL executor with a single parameter and an output schema, and the annotation provides a destructive warning. However, the description gives no context about when to use it (e.g., for arbitrary reads/writes) versus the specialized sibling tools, and it omits any caveats about side effects beyond the bare annotation. Given the tool's low complexity, this is adequate but not enriched, so it falls short of being fully contextual.
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 provides a single `sql` parameter with a description ('SQL to run') and a default, achieving 100% coverage. The tool description 'Execute any SQL query' adds no further meaning about the parameter's syntax, allowed statements, or formatting. Since the schema already documents the parameter, no compensating explanation is needed.
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' clearly states the tool's verb (execute) and resource (SQL query), making its core function unambiguous. However, it does not explicitly differentiate from sibling tools like explain_query or analyze_query_indexes, leaving the reader to infer its role as a general-purpose executor. This is clear but lacks explicit sibling differentiation.
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 that this is for arbitrary SQL execution while siblings handle query analysis, schema listing, or index insights, nor does it state any restrictions or prerequisites. This leaves the agent without direction for tool selection.
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. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so the tool is known to be a safe read operation. However, the description does not disclose that the 'analyze' parameter actually executes the query, which is an important behavioral nuance. No contradiction with annotations, but little added context beyond purpose.
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?
A single, clear sentence that immediately states what the tool does. No unnecessary words or repetition.
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 rich schema (100% param coverage) and existing output schema, the description is mostly sufficient. However, it could mention the optional analyze and hypothetical_indexes capabilities in the main description for quicker agent awareness, though these are covered in the schema.
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 detailed parameter descriptions including examples for hypothetical_indexes. The description itself adds no parameter-level information, so baseline 3 applies.
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?
Description clearly states the tool explains the execution plan for a SQL query, with specific verb 'explains' and resource 'execution plan'. It also mentions cost estimates, distinguishing it from execute_sql and analyze_query_indexes.
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?
Usage context is implied ('explains the execution plan') but no explicit guidance on when to use this tool versus alternatives like analyze_query_indexes or execute_sql. No exclusions or prerequisites are mentioned.
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 |
|---|---|---|---|
| object_name | Yes | Object name | |
| object_type | No | Object type: 'table', 'view', 'sequence', or 'extension' | table |
| schema_name | Yes | Schema name |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint: true, which already indicates a safe read operation, and the description aligns with this by saying 'Show detailed information'. However, the description adds no extra behavioral context beyond the annotation, such as what constitutes 'detailed' or how missing objects are handled. With annotations present, the bar is lower, and the description meets the minimum without adding value.
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, concise sentence that front-loads the action and resource. It contains no filler or redundant wording, earning full marks for conciseness.
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 simplicity, an output schema (mentioned in context signals), and the fully described input schema, the description is largely adequate. However, it lacks explicit guidance on when to use this tool over siblings, which would improve completeness. The missing usage context is the main gap.
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 each parameter (schema_name, object_name, object_type) having a clear description. The tool description itself adds no parameter-specific meaning beyond the schema, so the baseline of 3 applies. object_type's default value and allowed values are already in the schema.
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 'Show detailed information about a database object' uses a specific verb ('Show') and resource ('database object'), making the core purpose clear. It distinguishes itself from sibling tools like 'list_objects' (which likely enumerates objects) by focusing on details of a single object, but it does not explicitly state this differentiation.
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 that this tool is for inspecting a specific object as opposed to listing all objects, nor does it describe any prerequisites or exclusions. The user must infer usage from the tool name and sibling context.
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 |
|---|---|---|---|
| limit | No | Number of queries to return when ranking based on mean_time or total_time | |
| 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 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint: true, so the safe nature is already known. The description adds useful context about the data source (pg_stat_statements) but does not disclose prerequisites like extension availability or any limitations on the reported data.
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?
A single, clear sentence that front-loads the purpose and names the data source. No wasted words or redundant information.
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?
The description is simple and self-contained, naming the data source and purpose. Output schema and parameter schema cover the remaining details. A minor gap is not mentioning that the pg_stat_statements extension must be installed for the tool to work.
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 provides 100% coverage for both parameters, including explanations for valid sort_by values. The tool description adds no extra parameter-level detail, so the baseline score of 3 is appropriate.
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 action ('Reports') and the resource ('slowest or most resource-intensive queries') with a specific data source ('pg_stat_statements'). This distinguishes it from siblings like explain_query and analyze_query_indexes, which focus on different aspects.
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?
There is no explicit guidance on when to use this tool versus the sibling analysis tools. No mention of prerequisites, appropriate contexts, or exclusions; the intended use is only implied by the name and description.
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 |
|---|---|---|---|
| object_type | No | Object type: 'table', 'view', 'sequence', or 'extension' | table |
| schema_name | Yes | Schema name |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the readOnlyHint annotation; it simply restates the tool's purpose in a generic way. It does not mention pagination, default object_type behavior, or scope limitations, and because annotations already declare read-only, the description provides no additional 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 concise (a single sentence) and free of fluff, but it is also under-specified and essentially repeats the title. It lacks any structured detail (e.g., parameter mentions, usage context) that would make the sentence earn its place beyond the obvious.
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 simplicity, the input schema, readOnlyHint annotation, and presence of an output schema provide sufficient context for an agent to use it correctly. The description, while minimal, correctly states the high-level function, which is adequate for a straightforward list operation.
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 fully documents both parameters (schema_name required, object_type with allowed values), giving 100% schema description coverage. The description adds no parameter-level meaning, but the schema already handles the semantics, so the baseline of 3 applies.
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 identifies the action (list) and resource (objects in a schema), which is a specific verb+resource combination. However, it does not mention the object types or differentiate from sibling tools like get_object_details, so it lacks the scope and differentiation needed for a 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 such as list_schemas or get_object_details. There is no context about prerequisites, exclusions, or typical use cases, so the agent receives no decision-support information.
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 | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, which covers safety. The description adds the scope 'all schemas' but does not disclose other behavioral traits like ordering, pagination, or return format. With annotations present, a neutral score is appropriate.
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 concise sentence, 'List all schemas in the database', with no wasted words. It front-loads the action and object clearly.
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 simple read-only tool with no parameters and an output schema, the description fully covers the necessary context. It is complete without over-explaining, and annotations cover the safety profile.
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 tool has zero parameters, so the baseline is 4. The description adds no param info, but none is needed; the empty schema is self-explanatory.
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 uses a specific verb 'List' with a clear resource 'schemas' and scope 'in the database'. It distinguishes from siblings like list_objects and get_object_details by explicitly focusing on 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 clearly implies when to use the tool (when needing all schemas), but it does not explicitly state alternatives or exclusions. The presence of siblings like list_objects suggests a need for more differentiation, but none is provided.
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.
v0.1.1analyze_db_healthanalyze_query_indexesanalyze_workload_indexesexecute_sqlexplain_queryget_object_detailsget_top_querieslist_objectslist_schemasv0.3.0analyze_db_healthanalyze_query_indexesanalyze_workload_indexesexecute_sqlexplain_queryget_object_detailsget_top_querieslist_objectslist_schemasv1.0.0analyze_db_healthanalyze_query_indexesanalyze_workload_indexesexecute_sqlexplain_queryget_object_detailsget_top_querieslist_objectslist_schemasScored across 9 tools
Each tool targets a distinct aspect of database interaction: health checks, index analysis, query execution, explain plans, object details, top queries, and listing schemas/objects. There is no overlap; the two index analysis tools are differentiated by input (specific queries vs. workload).
All tool names follow a consistent verb_noun pattern in snake_case (analyze_, execute_, explain_, get_, list_). Verbs like 'analyze', 'execute', 'explain', 'get', and 'list' are used uniformly, making the naming predictable.
With 9 tools, the set is well-scoped for a Postgres MCP server covering health analysis, index optimization, query execution, and schema exploration. It neither feels sparse nor overwhelming, earning its place.
The tool set covers analysis and ad-hoc queries comprehensively via execute_sql, but lacks explicit tools for creating, altering, or dropping database objects. However, execute_sql enables these operations indirectly, making the gap minor.
MCP server for building and testing AI agents with multi-model experimentation and insights.
Analytical memory for AI agents: a real Postgres queried in plain English over MCP. One command.
Xata MCP server lets AI agents interact with your Xata projects, and Postgres database branches.
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
