はじめに: モデル コンテキスト プロトコルを使用する理由
Il モデルコンテキストプロトコル (MCP) Anthropic によって開発された、以下を定義するオープン スタンダードです。 AI アプリケーションが外部ツールとどのように通信するか。 MCP は根本的な問題を解決します: に与える 言語モデルの能力 現実世界で行動するテキストを生成するだけではありません。
MCP が登場する前は、AI と外部ツール間のすべての統合にはカスタム実装が必要でした。 独自のプロトコルと脆弱な統合。 MCP はこのコミュニケーションを標準化し、エコシステムを構築します USB-C と同様に、互換性のある AI からあらゆるツールにアクセスできるようになります。 統合されたハードウェア コネクタ。
このシリーズでは、 14件の記事、MCP の基礎から実装までを見ていきます。 高度な、オープンソース プロジェクトを詳細に分析する テックMCP、モノレポ 31 台の MCP サーバー、85 以上のツール、6 つの共有パッケージを備えた TypeScript。
このシリーズで学ぶこと
- MCP プロトコルとそのホスト/クライアント/サーバー アーキテクチャの基礎
- 3 つのプリミティブ: ツール、リソース、Zod 検証を伴うプロンプト
- TypeScript で MCP サーバーとクライアントを最初から作成する方法
- アーキテクチャ パターン: モノリポジトリ、EventBus、共有パッケージ
- 生産性、DevOps、データベース、プロジェクト管理用の 31 台の実際の MCP サーバー
- 型付きイベントとクロスサーバー呼び出しによるサーバー間コラボレーション
- 本番環境でのテスト、ベスト プラクティス、および展開
MCP が解決する問題
大規模言語モデル (LLM) は推論とテキスト生成において強力ですが、 実際の有用性を制限する基本的な制限:
- リアルタイムデータにアクセスできない：トレーニングには締め切り日があるため、AIは最近のイベントや更新されたデータを知りません
- 彼らはアクションを実行できません: ファイルの作成、API の呼び出し、データベースとの対話、デプロイメントの管理は、外部統合なしでは不可能な操作です
- ローカルコンテキストを持たない: AI はプロジェクト、タスク、コードベースの構造、開発環境を知りません。
MCP は、次の機能を提供することでこのギャップを埋めます。 双方向通信プロトコル AIとの間で これにより、言語モデルが真の運用アシスタントになることが可能になります。
統合の N x M 問題
規格なしで接続する N AI アプリケーション M 外部ツールに必要なもの N×M カスタム統合。それぞれの組み合わせには独自のプロトコル、独自の認証があり、 そのデータ形式。このアプローチは拡張性がありません。
MCP は複雑さを軽減し、 N+M: 各 AI アプリケーションは MCP クライアントを実装します。 各ツールは MCP サーバーを実装しており、すべて同じ標準プロトコルを介して通信します。
類似: AI 用の USB-C としての MCP
USB-C が登場する前は、各デバイスには独自のコネクタがありました。今日、USB-C はすべてを統合します。 充電、データ、ビデオ。 MCP は AI に対しても同様のことを行います。つまり、相互接続する単一の標準プロトコルです。 あらゆる言語モデルをあらゆる外部ツールに接続できるため、カスタム統合が不要になります。
MCP アーキテクチャ: ホスト、クライアント、サーバー
MCP アーキテクチャは、連携して機能する 3 つのコア コンポーネントに基づいています。 AI と外部ツールの間の相互作用:
1. ホスト
L'ホスト ユーザーが直接使用するAIアプリケーション。ユーザーセッションを管理します。 MCP サーバーに接続し、ツール呼び出しを調整します。ホストの例は次のとおりです。
- クロードデスクトップ: Anthropic のデスクトップ アプリケーション
- カーソルIDE: AI を統合した IDE
- VSコード MCP 拡張機能を使用した場合
- カスタムアプリケーション MCP SDKを使用するもの
2. クライアント
Il クライアント もう 1 つは、MCP プロトコルのクライアント側を実装するホスト内のソフトウェア コンポーネントです。 接続を維持します 1:1 MCP サーバーを使用して以下を管理します。
- La 能力のネゴシエーション 初期化中
- Il メッセージルーティング ホストとサーバー間の JSON-RPC
- La ライフサイクル管理 接続の
3. サーバー
Il サーバ そして AI に機能を公開するコンポーネント。 MCP サーバーが提供できるもの 3 種類のプリミティブ:
3 つの MCP プリミティブ
| 原生的 | 説明 | チェック | Esempio |
|---|---|---|---|
| ツール | AIが呼び出せる機能 | AIがいつ電話をかけるかを決定します | create-sprint, analyze-diff |
| リソース | アプリケーションが読み取れるデータ | アプリケーションがアクセスを制御する | ファイル、データベース、API レスポンス |
| プロンプト | 再利用可能な事前定義テンプレート | どちらを使用するかはユーザーが選択します | 「このコードにバグがないか分析してください」 |
トランスポート: クライアントとサーバーの通信方法
Il 輸送 クライアントとサーバー間の通信の物理メカニズム。 MCP サポート 2 つの主要なモード:
STDIO (標準入力/出力)
ローカルサーバーの最も一般的なトランスポート。クライアントとサーバーは次の方法で通信します。 stdin e
stdout プロセスの。各メッセージは改行で区切られた JSON-RPC オブジェクトです。
運河 stderr ログに引き続き使用できます。
- プロ: 簡単なセットアップ、ネットワーク構成不要、安全 (ローカル)
- に対して: ローカルのみ、接続ごとに 1 つのプロセス
HTTP + SSE (ストリーミング可能な HTTP)
リモートサーバーの場合、または複数の接続が必要な場合。クライアントは HTTP POST リクエストを送信します。 サーバーが応答します サーバー送信イベント ストリーミング用。セッションIDをサポート リクエスト間の状態を維持するため。
- プロ: リモートサポート、複数接続、スケーラブル
- に対して: 設定がより複雑で、HTTP サーバーが必要です
ツール呼び出しの仕組み
MCP がどのように機能するかを具体的に理解するために、ツール呼び出しのフローを段階的に追ってみましょう。
Utente: "Crea uno sprint chiamato Sprint-15"
|
v
[1] L'AI ragiona e decide di chiamare il tool "create-sprint"
|
v
[2] Il Client MCP serializza la richiesta in JSON-RPC:
{ "method": "tools/call",
"params": { "name": "create-sprint",
"arguments": { "name": "Sprint-15" } } }
|
v
[3] Il Server MCP riceve, esegue la logica, ritorna il risultato:
{ "content": [{ "type": "text", "text": "Sprint creato con id 42" }] }
|
v
[4] L'AI riceve il risultato e lo presenta all'utente:
"Ho creato lo sprint Sprint-15 (ID: 42)"
詳細なプロトコル フロー
- 発見: 起動時に、クライアントはサーバーに利用可能なツールのリストを要求します (
tools/list) - スキーム: 各ツールは、検証可能な JSON/Zod スキーマを使用してパラメーターを宣言します。
- 呼び出し: AI が会話のコンテキストに基づいて、いつどのツールを呼び出すかを自律的に決定します
- 実行: サーバーはビジネス ロジックを実行し、結果を返します。
- 構成: AI は複数のツール呼び出しを組み合わせて複雑なタスクを完了できます
MCP 対 REST API 対 AI プラグイン
MCP はツールを AI と統合する唯一の方法ではありませんが、それよりも大きな利点があります 従来の代替品へ:
統合アプローチ間の比較
| 特性 | REST API | AIプラグイン | MCP |
|---|---|---|---|
| 標準化された | はい (HTTP) | いいえ (ベンダー固有) | はい (オープンプロトコル) |
| 自動検出 | No | 部分的 | Si |
| パラメータの入力 | オープンAPI | それは異なります | Zod / JSON スキーマ |
| 双方向 | No | No | Si |
| ネイティブストリーミング | No | それは異なります | はい (SSE) |
| ベンダーロックイン | No | Si | No |
| 構成可能性 | マニュアル | 限定 | ネイティブ |
MCP が開発者にとって重要な理由
MCP は、開発者と AI の間の対話におけるパラダイム シフトを表します。利点は次のとおりです それを基本にする主なもの:
- 相互運用性: MCP サーバーは、Claude Desktop、Cursor、VS Code および 他の互換性のあるクライアント 修正なしで。一度書けば、どこでも作業できます。
-
構成可能性: AI は、さまざまなサーバーのツールを 1 つのワークフローに結合できます。
例: コードを分析します (
code-review)、テストを生成します (test-generator）、 そして時間を記録します（time-tracking) - すべてを 1 つの会話で。 - 安全性: プロトコルはサーバーができることを明確に定義します。ユーザー 機密性の高いアクションの承認を常に管理します。
- オープンエコシステム: 誰でも MCP サーバーを作成できます。許可は必要ありません ベンダーも依存する市場もありません。
- 永続的なコンテキスト: ステートレス API とは異なり、MCP は次のセッションをサポートします。 状態を維持することで、サーバーが後続の呼び出しの間のコンテキストを維持できるようになります。
Tech-MCP プロジェクト: 完全なスイート
MCP のパワーと柔軟性を実証するために、私は次のものを開発しました。 テックMCP、 を実装するオープンソース プロジェクト 31 MCP サーバー TypeScript モノリポジトリに編成されています。 これらのサーバーは、ソフトウェア開発ライフサイクル全体をカバーします。
数字で見るTech-MCP
| メトリック | 価値 |
|---|---|
| MCPサーバー | 31 |
| 利用可能なツール | 85+ |
| 共有パッケージ | 6 |
| 代表的なイベント | 29 |
| 言語 | タイプスクリプト 5.7 |
| ランタイム | Node.js 20+ |
| ビルドシステム | ターボレポ + pnpm |
サーバーのカテゴリ
31 台のサーバーは、開発のあらゆる側面をカバーする機能カテゴリに分類されています。
- 生産性 (3): コードレビュー、依存関係マネージャー、プロジェクトスキャフォールディング
- DevOps (3): docker-compose、log-analyzer、cicd-monitor
- データベース (2): db-schema-explorer、data-mock-generator
- ドキュメント (2): API ドキュメント、コードベースの知識
- テスト (2): テストジェネレーター、パフォーマンスプロファイラー
- 公共事業 (3): 正規表現ビルダー、httpクライアント、スニペットマネージャー
- プロジェクト管理 (5): スクラムボード、アジャイルメトリクス、時間追跡、プロジェクト経済学、レトロスペクティブマネージャー
- コミュニケーション (2): スタンドアップノート、環境マネージャー
- 高度な (9): インシデント マネージャー、意思決定ログ、アクセス ポリシー、クオリティ ゲート、ワークフロー オーケストレーター、インサイト エンジン、mcp レジストリ、ダッシュボード API
開発環境のセットアップ
このシリーズに従って MCP サーバーの開発を開始するには、以下がインストールされていることを確認してください。
前提条件
- Node.js 20+: JavaScript/TypeScript ランタイム (
node --version) - pnpm 9+: モノリポジトリのパッケージ マネージャー (
npm install -g pnpm) - TypeScript 5.7+: 型付き言語 (
npx tsc --version) - クロードデスクトップ: MCP サーバーをテストします (からダウンロード
claude.ai) - Git: Tech-MCP リポジトリのクローンを作成します。
Tech-MCP のクローンを作成して実行する
プロジェクト全体を探索するには、リポジトリのクローンを作成し、依存関係をインストールします。
# Clona il repository
git clone https://github.com/fedcal/Tech-MCP.git
cd Tech-MCP
# Installa le dipendenze con pnpm
pnpm install
# Compila tutti i pacchetti e server
pnpm build
# Verifica che tutto funzioni
pnpm test
クロードデスクトップの構成
Claude Desktop を使用して MCP サーバーをテストするには、構成ファイルを編集します。
// macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
// Windows: %APPDATA%\Claude\claude_desktop_config.json
// Linux: ~/.config/Claude/claude_desktop_config.json
{
"mcpServers": {
"scrum-board": {
"command": "node",
"args": ["path/to/Tech-MCP/servers/scrum-board/dist/index.js"],
"env": {}
}
}
}
シリーズの構成
この 14 の記事シリーズは、理論的基礎から進歩的な道をたどります。 高度な実装まで:
記事のロードマップ
| # | 主題 | レベル |
|---|---|---|
| 01 | モデル コンテキスト プロトコルの概要 | 初心者 |
| 02 | プリミティブ MCP: ツール、リソース、プロンプト | 初心者 |
| 03 | Monorepo アーキテクチャとプロジェクト パターン | 中級 |
| 04 | TypeScript で最初の MCP サーバーを作成する | 中級 |
| 05 | MCP クライアントの作成と HTTP のトランスポート | 中級 |
| 06 | 共有パッケージ: コア、EventBus、およびデータベース | 中級 |
| 07-11 | カテゴリ別サーバー (生産性、DevOps、DB、PM、アドバンスト) | 中級・上級 |
| 12 | サーバー間および EventBus のコラボレーション | 高度な |
| 13 | テスト、ベストプラクティス、本番環境 | 高度な |
| 14 | Tech-MCP: オープンソース プロジェクトの完全な概要 | 高度な |
結論
モデル コンテキスト プロトコルは、AI とツールの統合における質的な飛躍を表します。 開発の。これは API 呼び出しの単純なラッパーではなく、 構造化されたプロトコル これにより、自動検出、強力な型指定が可能になり、 双方向通信とネイティブな構成可能性。
次の記事では、それらについてさらに詳しく掘り下げていきます 3 つの MCP プリミティブ (ツール、リソース、プロンプト)、 それらを定義し、Zod で検証し、ライフサイクルを管理する方法を詳細に分析します。 コードの作成を開始し、ツール ハンドラーの構造とその形式を調べます。 回答のうち。
すべての例を含む完全なコードはリポジトリで入手できます。 GitHub 上の Tech-MCP.