メインコンテンツへスキップ

​
はじめに

MCP サーバーを使うと、カスタムデータソースに接続して、そのデータを Cursor 内で利用できる。ブラウザ、データベース、エラーやシステムログといった場所からコンテキストが必要なときに特に便利。MCP サーバーのセットアップはシンプルで、Cursor ならすぐに完了する。 このガイドでは、Postgres 向けの MCP サーバーの作り方を解説する。目的は、Cursor が Postgres データベースに対して直接 SQL クエリを実行できるようにし、テーブルスキーマを構造化して公開すること。
このチュートリアルは、MCP サーバー構築の基礎を学ぶためのものだよ。

​
MCP サーバーとは？

MCP サーバー は Cursor と通信し、外部データやアクションへのアクセスを提供するプロセス。いくつか実装方法はあるけど、ここではいちばんシンプルな方法を使う: stdio（標準入出力ストリーム）経由でローカルマシン上で動くサーバー。これなら複雑なセキュリティ検討を避けつつ、MCP のロジック自体に集中できる。 MCP の代表的なユースケースのひとつがデータベースアクセス。ダッシュボードの構築、分析の実行、マイグレーションの作成では、データベースに対するクエリや確認がよく必要になる。ここで作る Postgres MCP サーバーはコア機能として、任意クエリの実行とテーブルスキーマの一覧取得をサポートする。 これらは素の SQL だけでもできるけど、MCP はそれらをより強力かつ汎用的にする機能を提供してくれる。Tools はクエリ実行のようなアクションを公開する手段を提供し、Resources はスキーマ情報のような標準化されたコンテキストを共有できるようにする。このガイドの後半では、より高度なワークフローを可能にする Prompts も見ていく。 内部的には、postgres の npm パッケージに依存してデータベースに対して SQL 文を実行する。MCP SDK はこれらの呼び出しのラッパーとして機能し、Postgres の機能を Cursor にシームレスに統合できるようにしてくれる。

​
MCP サーバーの構築方法

サーバー構築の最初のステップは、新規プロジェクトのセットアップ。まずは新しいフォルダを作成して、Bun プロジェクトを初期化しよう 
> mkdir postgres-mcp-server
> Bun init
ここでは Blank プロジェクトを選ぶ。ボイラープレートのセットアップが終わったら、必要な依存関係をインストールしよう。zod は MCP SDK で入出力のスキーマを定義するために必須だ。 
bun add postgres @modelcontextprotocol/sdk zod
ここからは、各ライブラリのリポジトリに移動して、それぞれの README の raw ファイルへのリンクを取得する。サーバーを作るときのコンテキストとして使う 次に、サーバーの振る舞いをどうさせたいかを定義する。そのために spec.md を作成して、上位レベルの目標を書き出す 
# 仕様

- MCP の環境変数設定で DATABASE_URL を定義できるようにする
- ツール経由で Postgres のデータをクエリできるようにする
  - 既定では読み取り専用
  - 環境変数 `DANGEROUSLY_ALLOW_WRITE_OPS=true|1` を設定すると書き込みを許可
- テーブルは `resources` としてアクセスする
- スキーマ定義には Zod を使用する
見てのとおり、これはかなり軽量な仕様だよ。必要に応じて詳細をどんどん追加してね。README のリンクと合わせて、最終的なプロンプトを組み立てるよ 
以下を読み、@spec.md に従って求めている内容を把握すること。必要な依存関係はすべてインストール済み
- @https://raw.githubusercontent.com/modelcontextprotocol/typescript-sdk/refs/heads/main/README.md
- @https://raw.githubusercontent.com/porsager/postgres/refs/heads/master/README.md
これら3つのコンポーネント（仕様、MCP SDKのドキュメント、Postgresライブラリのドキュメント）が揃ったら、Cursorでサーバー実装のスキャフォルドを作れる。Cursorが各要素をつなぎ合わせ、MCP SDKとPostgresを接続するコードを生成してくれる。 何度かプロンプトを往復させて、MCPサーバーの最初のバージョンが動くところまできた。試すには、MCP Inspector を使おう。 
npx @modelcontextprotocol/inspector bun run index.ts

​
MCPサーバーのテスト

初期実装が完了したら、MCP Inspector を使って動作確認しよう。Inspector は、サーバーが公開している内容を可視化し、ツールやリソースが期待どおりに動くかを検証できる。クエリを実行できること、スキーマ情報が正しく返ってくることを確認しておこう。 MCP Inspector interface 問題なさそうなら、サーバーを Cursor 本体に接続して実環境でテストしよう。この時点で、Cursor は Postgres MCP サーバーをネイティブ機能のように扱えるようになり、データベースに直接クエリしたり、インスペクトしたりできる。

​
次のステップ

stdio 経由でローカルに MCP サーバーを動かすのはいい出発点だけど、チームでは MCP サーバー経由で同じデータベースへの共有アクセスが必要になることが多い。そんな場合は、MCP サーバーを中央集約型の HTTP サービスとしてデプロイする必要がある。 デプロイ済みの MCP サーバーには、個別の stdio インスタンスに比べて次の利点がある:
  • 共有データベースアクセス: 複数のチームメンバーが Cursor を通じて同じデータベースインスタンスにクエリできる
  • 集中管理された設定: スキーマ更新や権限変更を 1 か所で管理できる
  • セキュリティ強化: 適切な認証、レート制限、アクセス制御を実装できる
  • 可観測性: チーム全体の利用状況やパフォーマンスメトリクスを監視できる
これを実現するには、トランスポート方式を stdio から HTTP に切り替えよう。 セットアップ全体は扱わないけど、まずは Cursor に渡せる良いプロンプトを紹介するね 
既存の MCP サーバーをベースに、HTTP プロトコルを実装する新しいファイルを作成する。

共通ロジックを mcp-core に移し、各トランスポート実装に名前を付ける（mcp-server-stdio、mcp-server-http）。

@https://raw.githubusercontent.com/modelcontextprotocol/typescript-sdk/refs/heads/main/README.md
最終結果はここで確認できるよ: pg-mcp-server
⌘I