PostgreSQL MCPの設定｜接続文字列と読み取り確認

AIアプリからPostgreSQLの中身をMCP経由で見せたいけれど、接続文字列をどこに書けばよいのか、追加したあとに何を確認すれば「動いている」と言えるのか、判断に迷うことがあります。本番のデータベースに直接繋いでよいのかも気になるところです。

この記事では、いま維持されているPostgreSQL向けのMCP Serverの選び方と、接続文字列を直書きせずに渡す方法、そして追加後に読み取り確認を1回行うところまでを順番に整理します。

MCPをはじめて1本繋ぐ手順や、使っているアプリでの設定ファイルの置き場所、JSONの書き方の直しはこの記事では扱いません。

今日の結論

• この記事で使うのは、いまも更新が続くPostgres MCP Pro（crystaldba/postgres-mcp）です。アーカイブ済みの@modelcontextprotocol/server-postgresは現行の手順として使いません。
• 接続先は開発・検証用のデータベースに限ります。接続文字列はDATABASE_URIという環境変数で渡し、値そのものを記事やリポジトリ、チャットに書き込みません。
• 追加するときは--access-mode=restrictedを選びます。公式サンプルにあるunrestrictedは書き込みも可能にする指定で、restrictedであっても本番接続はおすすめしません。
• 追加したあとは「登録されたか」「接続できたか」「list_schemasなどの読み取りが1回通ったか」を分けて確認します。
• JSONの構文、使っているアプリでの設定場所、MCPをはじめて1本繋ぐ手順、細かな権限設計はこの記事では扱いません。

維持されているServerを選び、接続先を開発用に限る

PostgreSQL向けのMCP Serverは複数の実装が出回っていますが、この記事で使うのはcrystaldba/postgres-mcp、通称Postgres MCP Proです。継続的にメンテナンスされています。

一方、以前よく案内されていたservers-archivedのpostgresは、リポジトリの説明どおりすでにアーカイブ済みです。npmに残る@modelcontextprotocol/server-postgresパッケージも同じ実装で、確認した内容では更新が止まっています。古いブログ記事の手順をそのまま試すのは避けたほうが無難です。

接続先は開発・検証用のデータベースに限定します。本番のデータベースや個人情報を含むデータベースは、例としても使いません。ロールには読み取りに必要な権限だけを与える、という考え方が基本です。権限設定そのものの解説はこの記事では扱いません。必要なときはPostgreSQLの権限概要を参照してください。

できることの中心はスキーマの一覧取得とSQL実行。ほかに診断系のツールも用意されていますが、ここでは名前を挙げるだけにとどめます。

GitHubのIssueやWeb検索、ローカルファイルを扱うMCP Serverと役割が混ざりやすいので注意してください。IssueやPRが目的ならGitHub公式Serverの設定記事、Web検索ならBrave Search MCPの設定、手元のファイルならFilesystem MCPの使い方を参照してください。権限の監査チェックリストはこの記事では扱いません。

接続文字列は環境変数で渡し、値を直書きしない

Postgres MCP Proが必須とするのはDATABASE_URIという環境変数です。URIの構文そのものはこの記事では扱いません。必要なときはPostgreSQLの接続URIの公式ドキュメントを参照してください。ホスト名やパスワードの意味を、この記事で一つずつ説明することはしません。

JSONの設定ファイルやチャットのやり取り、記事、リポジトリに実際の接続文字列を貼らないようにします。公式のサンプルには生のpostgresql://username:password@...がそのまま書かれている箇所もありますが、この記事で示す例はすべてプレースホルダです。

VS Codeなどが用意する${input:…}や${env:NAME}といった記法は、あくまでアプリ側が値を参照する仕組みで、値を暗号化するものではありません。JSONの構文はこの記事では扱いません。直し方が必要なときはMCP設定JSONの書き方を参照してください。

アーカイブ済みの@modelcontextprotocol/server-postgresには、接続文字列をargsの末尾にそのまま渡す例があります。プロセス一覧などから見えやすい書き方なので、いま使う手順では環境変数を使う、とだけ触れておきます。アーカイブ側の設定例全文はここには載せません。

秘密の値を直書きしないという型は、GitHub向けのMCP Serverの記事とも共通しています。認証の中身自体はServerごとに違うので、そこは混ぜずに読んでください。

Docker／uvxの起動形を自分のClient向けに読む

以下の設定例は構造を説明するためのものです。実際に接続できることを確認したものではなく、URIの部分もすべてプレースホルダです。

はじめて追加するときは--access-mode=restrictedを選びます。公式サンプルに出てくるunrestrictedは書き込みも可能にする指定なので、そのままコピーしないようにしてください。

設定を書くキー名はアプリによって違います。Claude DesktopやCursor系はmcpServers、VS Code系はserversになります。設定ファイルの置き場所や反映のさせ方はこの記事では扱いません。Cursor・Claude Desktop・Claude Code・VS Codeそれぞれの設定記事を参照してください。

主な例はDockerとrestrictedの組み合わせです。

{
  "mcpServers": {
    "postgres": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-e",
        "DATABASE_URI",
        "crystaldba/postgres-mcp",
        "--access-mode=restricted"
      ],
      "env": {
        "DATABASE_URI": "postgresql://USER:PASSWORD@localhost:5432/DEV_DB"
      }
    }
  }
}

二つ目の経路としてuvxもあります。

{
  "mcpServers": {
    "postgres": {
      "command": "uvx",
      "args": ["postgres-mcp", "--access-mode=restricted"],
      "env": {
        "DATABASE_URI": "postgresql://USER:PASSWORD@localhost:5432/DEV_DB"
      }
    }
  }
}

pipxやuv runといった別の起動形も公式には用意されていますが、ここでは「ほかにもある」というところまでにとどめ、4種類を並べて比較することはしません。ビルド手順の解説も本記事の範囲外です。

SSEなどの--transport指定もありますが、こちらも「ある」というところまでです。stdioとHTTPの比較はこの記事では扱いません。比較が必要なときはstdioとSSEの違いを参照してください。

JSONの型やカンマ、引用符の直し方はこの記事では扱いません。直し方が必要なときはMCP設定JSONの書き方を参照してください。Postgres固有のcommand・args・envの読み方までが対象です。VS Code向けはキー名がserversになる点だけここで触れておきます。設定例の全文はVS CodeでのMCP設定と公式のREADMEを参照してください。

登録・接続・スキーマ確認1回を分けて確認する

追加したあとの確認は、次の3つに分けて見ていくと判断しやすくなります。

1. 登録: 使っているアプリの側でPostgresが一覧に追加されたかどうかを見ます。表示される場所や、反映のために再起動が必要かどうかはアプリごとに違います。ここでは「出ているか、出ていないか」の判定だけにとどめます。
2. 接続: URIが不足していないか、認証に失敗していないか、コンテナからホストが見えているかを疑います。エラーメッセージの具体例はこの記事では作りません。渡している変数名がDATABASE_URIになっているか、接続先が開発用のデータベースになっているかを確認します。
3. 呼び出し: list_schemasを1回呼びます。会話の中で「調べました」という返答だけでは判定材料になりません。ツールが実際に呼ばれた記録と、その結果が返ってきているかを見てください。架空のスキーマ一覧をこの記事に書くことはしません。必要であれば、件数を絞ったり個人情報を含むテーブルを避けたりしたうえで、機密性のないexecute_sqlを1回試す程度にとどめます。SELECT *は勧めません。

explain_queryやanalyze_*、get_top_queriesといった診断系のツールも用意されていますが、これらは「あります」というところまでにとどめ、初回の成功条件には含めません。詳しくは公式のREADMEを参照してください。

一覧に出ていれば登録、接続に起因するエラーが出ていなければ接続、スキーマ確認の呼び出し記録と結果があれば、この記事で扱う範囲の呼び出しは完了です。はじめて1本のServerを繋ぐところからの完了宣言はこの記事では扱いません。必要なときはMCP初回セットアップの記事を参照してください。restrictedであっても、これで本番に接続してよいという意味にはなりません。

止まったら隣の手順記事へ切り分ける

原因を一つに断定せず、症状に近い確認先から見ていくのがおすすめです。

まとめ：接続先の限定と直書き回避を先に固める

PostgreSQLをMCP経由で見せるときは、維持されているServerを選び、接続先を開発用に限り、接続文字列を直書きしないところまでが土台になります。追加後は登録・接続・スキーマ確認を分けて見れば、restrictedのままでも読み取り1回までは判断できます。

関連する手順はMCP Serverの設定ガイドにまとめています。ほかのServerを追加したいときや、権限まわりをもう少し詰めたいときの入り口としてご覧ください。

本記事の内容は執筆時点（2026-09-18）の情報に基づきます。公式ドキュメントを参照して構成していますが、掲載した手順の実機での動作は未検証です。パッケージ名・起動フラグ・ツール名・アクセスモード・接続先の条件はバージョンによって変更される可能性があります。接続の成功、データの安全性、本番利用の適否を保証するものではありません。重要な判断は公式ドキュメントで確認してください。