[MCP] CursorでMCPサーバーを試してみた(GitHub API・Notion API 編)

2025/04/11

LLM
Cursor
MCP

はじめに

最近、「MCP」という仕組みが注目されていると聞き、どんなものか試してみることにしました。

MCP(Model Context Protocol)とは、AI(大規模言語モデル)が外部のデータソース(ファイルやデータベース、Webサービスなど)にアクセス・操作する際の共通プロトコルで、個別の実装に依存せず統一された方法でやりとりできるようにするための「共通言語」のようなものです。

これにより、さまざまなシステムやツールと容易かつ安全に連携できるようになります。

私自身MCPについてあまり理解できていなかったため、まずは実際に使ってみて概略を掴もうと考えました。

そこで、AIコーディング支援環境である「Cursor」を使い、MCPサーバー経由で外部APIにアクセスする実験を行いました。

本記事ではその体験をまとめます(環境はmacOS)。

ゴールとしては以下の2点、MCPサーバーで何ができるのかどう使うのかをざっくり理解することにあります。

今回試したのは以下の二つのケースです。

  • GitHubのAPIを通じて自分のリポジトリ一覧を取得する
  • NotionのAPIを通じてページの検索を行う

環境セットアップ

まずは環境の準備です。

Cursorのインストールは公式サイトから行いました。
Cursor Proであれば追加設定なしで組み込みのモデルが使えます。

こちらの記事にも書いたように、私はすでに課金しています。

また、今回利用するMCPサーバーはNode.jsとDockerのそれぞれの環境が必要になっているので、それぞれの環境がない方はこのタイミングで準備してください。

加えて、GitHub APIを利用するには GitHubのPersonal Access Token (PAT) も用意しました。

PATはGitHubのAPI利用時にパスワード代わりに使えるトークンで、アクセス範囲や有効期限を細かく設定できる安全な認証手段です (〖Git〗personal access tokenを使用してGitHubへアクセスする #初心者向け - Qiita)。

GitHubの設定画面から新しいトークンを発行し(リポジトリ読み取りの権限を付与)、これも安全な場所に保存しておきます。

以上をまとめると、Cursor本体の導入(+APIキー設定)、Node.jsとDockerの準備、そしてGitHub/Notion用の認証トークン取得が事前準備となりました。

MCPサーバーのセットアップ

続いて、MCPサーバー自体のセットアップを行います。MCPはクライアント・サーバー型のアーキテクチャで動作し、Cursorのようなホスト(クライアント)が各種MCPサーバーに接続することで機能を拡張します。

MCPサーバーごとに特定のデータソースやサービス(今回はGitHubやNotion)の操作機能を提供しており、それぞれツール (tools) として機能一覧が定義されています。

LLM(Cursor上のAI)はこのツール一覧を参照し、ユーザーの指示に合ったものを選んで実行する仕組みになっています。

例えば「GitHubのPR一覧を取得して」とプロンプトを出すと、GitHub MCPサーバーが提供する多数のAPIツールの中から適切なものをAIが判断して呼び出し、結果を返してくれるわけです。

それでは具体的なセットアップ手順です。今回は GitHub MCPサーバーNotion MCPサーバー の2種類をCursorに接続しました。

  1. MCPサーバーのコードを入手: まず、公式のMCPサーバー集約リポジトリである「modelcontextprotocol/servers」をGitHubからクローンしました。このリポジトリには様々なサービス向けのMCPサーバー実装が含まれており、GitHub用もその一つです。クローン後、リポジトリ内を見るとsrc/github/ディレクトリ以下にGitHub MCPサーバーのソース(TypeScript)やDockerfileなどが入っていることが確認できます。

  2. GitHub MCPサーバーのビルド: GitHub用サーバーはDockerイメージとして提供されているため、クローンしたリポジトリのルートでDockerビルドを行いました。具体的には、serversディレクトリで以下のコマンドを実行します。

    docker build -t mcp/github -f src/github/Dockerfile .
    

    このコマンドでmcp/githubという名前のローカルDockerイメージが作成されます。

  3. Notion MCPサーバーのビルド: Notion用のMCPサーバーについては、上記リポジトリには含まれていないため、コミュニティ提供の実装を使用しました。調べたところ、suekou氏によるオープンソースの「mcp-notion-server」があったので、これをクローンします。リポジトリを取得したら、その中のnotion/ディレクトリへ移動して依存関係をインストールし、ビルドを行いました。手順としては以下の通りです。

    gh repo clone suekou/mcp-notion-server
    cd mcp-notion-server/
    npm install
    npm run build
    

    上記により、mcp-notion-server内にbuildフォルダが作成され、中にindex.jsが作成されることを確認してください。

  4. CursorへのMCPサーバー登録: ビルドした各MCPサーバーをCursorから利用できるように登録します。.cursor/mcp.jsonを作成し、以下のように入力してください。

 {
      "mcpServers": {
          "github": {
              "command": "docker",
              "args": [
                  "run",
                  "-i",
                  "--rm",
                  "-e",
                  "GITHUB_PERSONAL_ACCESS_TOKEN",
                  "mcp/github"
              ],
              "env": {
                  "GITHUB_PERSONAL_ACCESS_TOKEN": "******"
              }
          },
          "notion": {
              "command": "node",
              "args": [
                  "/Users/****/mcp-notion-server/build/index.js"
              ],
              "env": {
                  "NOTION_API_TOKEN": "******"
              }
          }
      }
  }

登録が完了すると、Cursor設定のMCPサーバー一覧に2つのサーバー(GitHubとNotion)が表示されました。

それぞれの欄には利用可能なツール一覧が表示されます。

たとえばNotionサーバーではnotion_searchnotion_retrieve_pageなど多数の操作がツールとして定義されており、GitHubサーバーではリポジトリやIssue、Pull Requestにアクセスするためのツール群が並んでいます。

緑の丸が接続中を示し、その下にnotion_searchをはじめとする使用可能なAPI操作(tools)が一覧表示されています。MCPサーバーを通じてこれらの操作がLLMから呼び出されることになります。

GitHub APIアクセス: リポジトリ一覧の取得

準備が整ったところで、まずはGitHub MCPサーバーを使ってGitHubのAPI操作を試しました。

狙いは自分のGitHubアカウントにあるリポジトリ一覧の取得です。

通常これを行うには、GitHubのREST APIエンドポイント(例えば/user/repos)を自分で呼び出すか、GitHub CLIを使うなどの方法があります。

しかしCursor上では、そのような直接的なコーディングやコマンド実行を行わず、AIに自然言語で依頼するだけで済みます。

具体的には、Cursorのチャットプロンプトに例えば「自分のGitHubリポジトリ一覧を取得してください」と日本語で指示を出しました。

すると背後でCursorのLLMアシスタントが、この要求を満たす適切なツール(GitHub MCPサーバーのAPI)を自動的に選択して実行します。

MCPサーバー側には「リポジトリ一覧を取得する」ための操作が用意されており、AIはツール一覧からそれを見つけて呼び出してくれるのです。実際、プロンプト送信後にCursorのUI上では「GitHubサーバーの◯◯というツールを実行してもよいか?」という確認メッセージが現れました。これはMCP経由で外部APIを呼び出す際の安全確認です。意図しない破壊的操作を防ぐため、Cursorでは各ツール実行の際にユーザーに許可を求める仕組みになっています。

今回は読み取り系の操作なので深刻なリスクはありませんが、確認ダイアログで許可を与えると、GitHub API呼び出しが実行されました。

結果として、数秒後に自分のGitHubリポジトリ一覧がCursor上に表示されました。

私の場合、プライベートも含め十数件のリポジトリがあるので、それらの名前や説明が箇条書きのリスト形式で返ってきました。例えば以下のような出力です。

1. user-name/repo1 - Repository 1 の説明文
2. user-name/repo2 - Repository 2 の説明文
...

(実際のリポジトリ名の代わりに例示しています)

特にフォーマットを指定しなかったため、デフォルトではリポジトリ名と説明がMarkdownリストで列挙されました。

もし必要であればプロンプトで「名前だけを箇条書きで」や「JSON形式で」と指示することも可能です。LLMがAPIから取得したデータを元に、指示に合わせた形で整形してくれるため、欲しい形で結果を得ることもできます。

ここで注目すべきは、この一連の操作で一切自分でGitHubのAPIエンドポイントを調べたりHTTPリクエストを記述したりしていない点です。

CursorのAIアシスタントが「リポジトリ一覧を取得するにはGitHub APIのどのエンドポイントを使えばよいか」を理解し、裏で適切なAPI呼び出し(おそらくlist_user_reposのようなツール)を行ってくれました。

ユーザーの私に求められたのは、「リポジトリ一覧が欲しい」という目的を素直に言葉で伝えることだけです。複雑な部分はAIが肩代わりしてくれるので、開発者は高レベルな指示に集中できます。

また、MCPサーバー経由なので認証情報も自動的に付与されました。

先程Cursorに登録したPATが環境変数としてサーバーに渡されているため、API呼び出しには自分の認証トークンが適用されています。

そのおかげでプライベートリポジトリも含めて一覧取得が可能になっています(当然ながら、自分のPATでは自分のリソースしかアクセスできません)。

体験としては、ChatGPTに「○○して」とお願いしたらいつの間にか自分のGitHubからデータを取ってきてくれた、という感覚に近く、とてもスマートです。

通常ならREST APIのドキュメントを読み、適切なHTTPリクエストを作り、認証ヘッダを付けて…という工程が必要ですが、それらがMCP+Cursor環境ではすべて裏側で処理されました。

AIコーディング支援ツールが実行環境とつながり、自動でツールを選んで実行してくれることで、開発ワークフローが大きく簡略化されたと感じます。

Notion APIアクセス: ページ検索の実行

次に、Notion MCPサーバーを使ってNotionデータベース内を検索する操作を試しました。事前準備として、先述の通りNotionの内部統合(Integration)を作成しAPIトークンを取得、また検索対象とするページやデータベースにその統合を関連付けて権限を与えておきました。

CursorにNotion MCPサーバーを登録する際にこのトークンを設定済みです。

今回はシンプルに、私のNotionワークスペース内にあるドキュメント群からキーワードにマッチするページを探す、というタスクを試しました。CursorのAIチャットプロンプトに「Notionで『〇〇』という単語を含むページを検索してください」と依頼します。

GitHubの場合と同様に、CursorのAIアシスタントが要求を解析し、適切なMCPツール(Notion MCPサーバーのAPI操作)を選択します。このケースではおそらくnotion_searchというツールが該当し、内部でNotion APIの検索エンドポイントを呼び出しているはずです。

Notion MCPサーバーにはnotion_searchという検索用ツールが定義されています。

プロンプトを送信すると、やはり「Notionサーバーの検索ツールを実行しますか?」と確認が出たので許可しました。

するとNotion APIでの検索が行われ、検索結果がAI経由で返ってきました。

結果は数件のページがリストアップされた形で表示されました。

各項目にはページのタイトル(Notionのページ名)が示され、場合によっては簡単なスニペット(その単語を含む文脈)も添えられていました。

リンクをクリックすればブラウザでそのNotionページを開けるようになっており、実用的です。

例えば、「MCP」というキーワードで検索したところ、社内のナレッジベースに書かれたMCPに関するメモページがヒットし、そのタイトルが返ってきました(ページ名がそのまま結果として表示されました)。AIが自動で自分のNotionデータベースを横断検索し、関連するページを探し出してくれたわけです。

この操作においても、自分でNotion APIを叩くコードを書く必要は皆無でした。

通常、Notion APIで検索するにはHTTPリクエストに検索クエリを入れて…といった処理が必要ですが、Cursor+MCPでは単に「〜を検索して」と伝えるだけで済みました。

AIが裏でnotion_searchツールを使い、結果を受け取って読みやすい形に整形してくれています。

Notion MCPサーバーを導入したことで、他にも様々な操作が可能になります。

たとえば検索結果で見つかったページの中身を読みたい場合は「そのページの内容を表示して」と頼めばnotion_retrieve_pageツールが使われ、ページブロックの内容がテキストとして得られます。

実験では簡単な検索だけ行いましたが、時間をかければNotion上のデータ集計や更新もCursorから行えます。

もちろん、重要なデータを書き換える操作をAIに任せるのは慎重になるべきですが、少なくとも読み取り・検索に関しては大いに効率化できると感じました。

所感と今後

今回、CursorのMCP対応機能を使ってGitHubとNotionという二つのサービスのAPI操作を試してみましたが、AIアシスタントが外部サービスまでシームレスに繋がる体験は非常に強力だと実感しました。

以下、感じたポイントをまとめます。

  • 開発効率の向上: APIの使い方を逐一調べてコードを書く手間が減り、「〜したい」という要件をそのまま指示できるため、生産性が上がります。特に複数のサービスにまたがる作業(例:GitHubからデータ取得してNotionに記録する等)も、一貫したインタフェースで実現できる可能性を感じました。

  • 統一的なインタフェース: MCPによりツール追加の方法が標準化されているため、新しいサービス連携を追加する敷居が低いです。実際、GitHub用とNotion用で多少セットアップ手順は異なりましたが、Cursorへの登録手順や使用方法自体は共通した流れでした。今後もし他のMCPサーバー(例えばWeb検索用のBrave Searchや自律的に思考を深めるSequential-Thinkingツール等)を追加しても、同様に使えるでしょう。

  • AIアシスタントとの補完: Cursor自体がコーディング支援ツールであるため、MCP以外の場面でもコード補完や説明生成などで開発をサポートしてくれます。MCP機能との組み合わせにより、たとえば取得したデータに基づいた分析やドキュメント生成まで一気通貫でAIに任せる、といったことも可能になります。実験中も、AIが返したリポジトリ一覧や検索結果に対して追加の質問を投げることで、内容の要約や特定項目の抽出などを対話的に行えました。まさにAIがペアプログラマ兼アシスタントとして隣にいるような感覚です。

  • 課題・注意点: 一方で感じた課題もあります。まず、公式ドキュメントがまだ充実しておらず、情報を集めるのに手間取りました。また、APIキーやトークンの管理には細心の注意が必要ですし、MCPサーバーのコードを自分でビルドする場合はそのメンテナンスも発生します。実行時にはCursorが各ツール実行ごとに確認ダイアログを出しますが、操作を連続して行うようなケースでは何度も許可を与える必要があり煩わしさを感じる場面もありました。このあたりは安全性とのトレードオフなので致し方ない部分ですが、今後UXの向上に期待したいところです。さらに、LLMが返す内容についても過信は禁物です。今回は主にデータ取得が中心でしたが、より複雑な処理や要約・分類を任せる場合、その結果の正確性はLLMの性能に依存します。最終的な判断は人間が行うという姿勢は崩せません。

総じて、Cursor+MCPサーバーを用いた開発体験は、AIがIDEの中から外界に向けて「手」を伸ばすような新鮮さがありました。今回はGitHubとNotionという限られた範囲での検証でしたが、MCPによって実現できることの幅広さを実感できました。今後サポートされるサービスが増えたり、プロトコル自体が成熟したりすれば、開発者はますます高レベルな指示に集中し、低レベルな実装や調査はAIに任せるという形が一般化するかもしれません。私自身、今回得た知見を踏まえてさらに他のMCPツールを試したり、社内向けの自作MCPサーバーを実装してみることも検討したいと思います。AIアシスタントと開発環境のこれからの進化がとても楽しみです。

Related Posts

[生成AI] GitHub CopilotからCursorに乗り換えました

[生成AI] GitHub CopilotからCursorに乗り換えました