インストール
npx -y @modelcontextprotocol/server-postgres postgresql://localhost/mydbだれ向けか
モデルに PostgreSQL の表構造を見せ、読み取り専用 SQL を走らせたい人向け。根拠は次のとおり：この MCP は PostgreSQL への読み取り専用アクセスを提供し、schema の確認と読み取り専用クエリの実行に使う。
接続可能な postgresql:// URL を用意でき、モデルが表構造とクエリ結果を読むことを受け入れる必要がある。読み取り専用トランザクションは「ゼロリスク」ではない：接続し、データを読み、URL にユーザー名とパスワードを含められる。
根拠はクライアント一覧を出していない。公式ページは servers-archived ツリーにあり、根拠は保守状況を別に書いていない。現行の推奨実装だと決めつけないこと。
3 分で最初の試行
主経路は NPX。Docker を主インストールにしない。クライアントの MCP 設定では次を使う：
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-postgres",
"postgresql://localhost/mydb"
]
最後の URL を、読み取り専用でアクセス権のあるデータベースに置き換える。ユーザー名とパスワードは根拠どおり postgresql://user:password@host:port/db-name と書いてよい。本番の書き込みアカウントや完全なパスワードを会話に貼らない。
前提：このマシンに npx がある。データベースがそのプロセスからの接続を許す。初回は schema の確認か、データを変えないクエリだけ。
設定場所：クライアント MCP サーバーの command / args。第 3 引数が接続文字列。
低リスクな最初の呼び出し：まずリソース postgres://<host>/<table>/schema を読み、1 表の列名と型を見る。またはツール query を呼び、sql 文字列を渡す。根拠は READ ONLY トランザクションで実行すると保証する。INSERT/UPDATE/DELETE で「読み取り専用を検証」しない。
成功の合図：クライアント接続後に表 schema リソースを列挙できる、または query が読み取り専用結果を返す。接続失敗なら先に URL（ローカル DB、ポート、DB 名）を直す。Docker に切り替えて推測しない。Docker について根拠が補うのは：macOS でサービスがホスト上なら host.docker.internal を使う。
ユースケース
ケース 1：ある表にどの列があるかを把握する。postgres://<host>/<table>/schema を読む。根拠は、データベースメタデータから自動発見した JSON schema で、列名とデータ型を含むと書く。表名列挙 API はない。<host> と <table> は実際の接続に合わせて置き換える。見えない表を作らない。
ケース 2：存在を確認済みの表に読み取り専用クエリを走らせる。query を呼ぶ。パラメータは sql だけ。根拠は READ ONLY トランザクションでの実行を保証する。結果のページング、タイムアウト、実行可能な SQL 方言の範囲は書いていない。確認できるのは、この SQL が読み取り専用クエリとして接続済みの DB に送られること。一時表の作成や状態を変える関数呼び出しは仮定しない。
利用上の境界
読み取り専用アクセスであり、元に戻せる書き込みではない。根拠に undo はない。接続文字列にパスワードを含められ、資格情報とデータ面の露出になる。ツールは query だけ。Docker と NPX は別経路で、主経路は NPX のまま。根拠はコネクションプール、SSL、読み取り専用ロール強制を書いておらず、READ ONLY トランザクションがあらゆる副作用を防ぐとも書いていない（一部の SQL 関数には外部効果があり得るが、ページは展開していない）。ページはアーカイブ済みリポジトリツリーにあり、根拠は代替パッケージや移行説明を提供していない。