「MCP × Cursor」入門メモ：Windows で詰まったことや Function Calling との違いなど

週末に MCP を触ってみたので、その内容をまとめてみました！
僕は Cursor から接続して試しました。

## 環境

- Windows 11
- cursor 0.48
- node 22.9.0
- npm 10.8.3
- bun 1.2.8

※ のちに触れていますが、Windows を使っていると少し詰まるポイントがありました。

## 進め方

以下の記事を参考にしてキャッチアップしました。

https://zenn.dev/yamada_quantum/articles/465c4993465053  

→ 基本的にこの記事を読みながら MCP についての理解を深めました。
記事のタイトルにあるように MCP の概要からちょっと深い話までしっかり詰まっていたので、是非見てみてください。

https://zenn.dev/bamboohouse/articles/74037522a0a815  

  → チュートリアルとしてはこちらの記事は参考になりました。  
   公式チュートリアルをベースに進めていった記事のようでしたが、スクショやコマンド情報が多くて理解しやすかったです。

https://speakerdeck.com/shuntaka/introduction-to-mcp

  → 入門レベルではないくらい詳しく説明されていました。
  よく理解していない部分もあるので、触りつつ理解を深めていきたいです。

## 詰まった点

いきなりですが、詰まった点を 2 点紹介します。

### UI が違う

参考記事と比べて、Cursor 側の UI は結構変わっていました。（以前は json に書くのではなく入力形式だった模様。）  
最新の公式ドキュメントを確認したりするのがおすすめです。

https://docs.cursor.com/context/model-context-protocol

### Windows のファイルパスに注意

Windows ではファイルパスの形式に注意が必要です。  
`/c/Users/...` のような形式のパスは、Node.js で正しく解釈されないようで、**フル Windows パス（例：`C:\Users\...`）で指定する必要がありました。**

僕は最初エラーが出てハマりましたが、エラーメッセージをそのまま LLM に投げたら解決出来ましたが、よく見るとちゃんと公式ドキュメントに書いてありました……。（公式ドキュメント大事…）

## やってみた
それではやってみた内容を書いていきます。

結果としては、MCP を使って無事に動作確認できました！  

今回は記事やチュートリアルにある「天気を正確に調べる MCP サーバー」と「現時刻を表示する MCP サーバー」を試しました。

### 通常

特に何も設定していない状態だと、以下のように情報が取得できません。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2369683/935364f8-8aac-431a-9852-db6f78ed0cf3.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2369683/60272faa-747b-4632-8564-11ac3cb3ff68.png)


### MCP サーバーを設定

記事を参考にして、以下のように設定しました。


```json
{
  "mcpServers": {
    "weather": {
      "command": "node",
      "args": ["C:\\Users\\XXX\\weather\\build\\index.js"]
    },
    "display-time": {
      "command": "bun",
      "args": ["C:\\Users\\XXX\\display-time\\index.js"]
    }
  }
}

```

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2369683/77c7c965-5d2e-4acb-bdd5-427c722af658.png)


設定した状態でもう一度実行すると、今度は正確な情報が返ってきます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2369683/b2b20962-63e0-4c88-a092-a6d2230e955f.png)


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2369683/e1c5cee8-1d5d-4cba-82b6-2a935ce37c06.png)


Chat した際に MCP のツールとして「Run Tool」ボタンが出てくるのですが、Function Calling と同じように、LLM が適切なツールを自動的に選定・実行してくれているようです。

## Function Calling との違いについて

色々な記事を見ましたが、要は MCP は AI モデルに依存せず開発者が細かい処理フローを設計せずとも、外部データ活用が簡単にできる、かつセキュリティ面でも認証情報の漏洩リスクが低減されるようですね。
あと一度構築すれば複数クライアントから利用可能なのも良い点だなと思いました。

Function calling は、アプリケーション主導の設計なのでそもそも設計思想は違うようですが、MCP によって容易にできることが増えるというか、可能性が広がりそうな雰囲気ですね。。！

以下の記事がとても分かりやすかったで記載します。

https://qiita.com/7shi/items/e27866ce51c6b9a0f605

> Function Calling では、LLM は関数呼び出しのパラメータを生成するだけで、関数の実行自体はアプリケーション側で行う必要があります。  
> 結果を元に応答を生成するフローも、開発者が独自に実装しなければなりません。

> 一方で MCP では、LLM が MCP サーバーへデータを要求し、その結果を受け取って応答を生成するまでの一連の流れがプロトコルとして定義されています。  
> 開発者は MCP に準拠したシステムを用意するだけで、LLM が自動的に外部データを活用して応答を生成できます。

https://zenn.dev/yamada_quantum/articles/465c4993465053

> Function Calling は、OpenAI や Anthropic など特定のベンダーの仕様に依存しており、モデルごとにインターフェイスが異なります。  
> 一方、MCP は MCP サーバーと MCP クライアント間の共通プロトコルに基づいてやり取りするため、特定の AI モデルに依存しません。


https://quaily.com/lyric_kiji/p/function-calling-vs-mcp-developers-comparison

> MCPを使用する場合：
> ローカルプログラム（quail-cli）で認証とセッション管理を処理できます。ログイン状態はMCPサーバー（quail-cli）に自然に存在し、ログイン認証情報がLLMに漏洩することはありません。

> Function Callingを使用する場合：
> 明らかにトークンやその他のログイン認証情報をLLMに送信することはできません：セッション識別子がLLMに記憶されるリスクがあるからです。これらのLLMが密かに鍵をコピーしないとは限りません。

## 最後に

以前から MCP の噂は聞いていましたが、ようやく週末に少し触ってみることができました。  
やっぱり実際に触ると理解が進みますね。

Mac 向けの情報が多い印象なので、Windows ユーザーは少し注意が必要です。

また、僕は普段 Figma を業務でよく使っているので、今後は Figma × MCP の連携にもチャレンジして、どのようなことができるのか試してみたいと思っています！  
また何か試したら記事を書きます！