| name | mcp-builder |
| description | LLMが外部サービスと対話するための適切に設計されたツールを通じて、高品質なMCP (Model Context Protocol) サーバーを作成するためのガイド。Python (FastMCP)、Node/TypeScript (MCP SDK)、Rust (Tokio)で、外部APIやサービスを統合するMCPサーバーを構築する際に使用します。 |
| license | Complete terms in LICENSE.txt |
MCPサーバー開発ガイド
概要
このスキルを使用して、LLMが外部サービスと効果的に対話できる高品質なMCP（Model Context Protocol）サーバーを作成します。MCPサーバーは、LLMが外部サービスやAPIにアクセスできるようにするツールを提供します。MCPサーバーの品質は、提供されたツールを使用してLLMが実際のタスクをどれだけうまく達成できるかによって測定されます。
プロセス
🚀 ハイレベルワークフロー
高品質なMCPサーバーの作成には、4つの主要フェーズがあります：
フェーズ1：徹底的な調査と計画
1.1 エージェント中心設計原則の理解
実装に入る前に、以下の原則を確認してAIエージェント向けのツール設計方法を理解してください：
APIエンドポイントではなくワークフローを構築する：
- 既存のAPIエンドポイントを単純にラップするのではなく、思慮深く影響力の高いワークフローツールを構築する
- 関連する操作を統合する（例：空き状況を確認してイベントを作成する
schedule_event）
- 個々のAPI呼び出しではなく、完全なタスクを可能にするツールに焦点を当てる
- エージェントが実際に達成する必要があるワークフローを検討する
限られたコンテキストに最適化する：
- エージェントのコンテキストウィンドウは制限されている - すべてのトークンを有効活用する
- 網羅的なデータダンプではなく、シグナルの高い情報を返す
- 「簡潔」対「詳細」な応答形式オプションを提供する
- 技術的なコード（ID）よりも人間が読める識別子（名前）をデフォルトにする
- エージェントのコンテキスト予算を希少なリソースとして考慮する
アクション可能なエラーメッセージを設計する：
- エラーメッセージはエージェントを正しい使用パターンに導くべき
- 具体的な次のステップを提案する：「結果を減らすには filter='active_only' を試してください」
- エラーを診断的ではなく教育的にする
- 明確なフィードバックを通じてエージェントが適切なツールの使用方法を学習できるように支援する
自然なタスク分割に従う：
- ツール名は人間がタスクについて考える方法を反映すべき
- 関連するツールには一貫した接頭辞をつけて発見しやすくする
- API構造だけでなく、自然なワークフローを中心にツールを設計する
評価駆動開発を使用する：
- 現実的な評価シナリオを早期に作成する
- エージェントのフィードバックをツール改善の原動力とする
- 素早くプロトタイプを作成し、実際のエージェントのパフォーマンスに基づいて反復する
1.3 MCPプロトコルドキュメントの学習
最新のMCPプロトコルドキュメントを取得：
WebFetchを使用してロード：https://modelcontextprotocol.io/llms-full.txt
この包括的なドキュメントには、完全なMCP仕様とガイドラインが含まれています。
1.4 フレームワークドキュメントの学習
以下のリファレンスファイルをロードして読む：
Python実装の場合は、以下も読み込む：
- Python SDKドキュメント：WebFetchを使用して
https://raw.githubusercontent.com/modelcontextprotocol/python-sdk/main/README.mdをロード
- 🐍 Python実装ガイド - Python固有のベストプラクティスと例
Node/TypeScript実装の場合は、以下も読み込む：
- TypeScript SDKドキュメント：WebFetchを使用して
https://raw.githubusercontent.com/modelcontextprotocol/typescript-sdk/main/README.mdをロード
- ⚡ TypeScript実装ガイド - Node/TypeScript固有のベストプラクティスと例
Rust実装の場合は、以下も読み込む：
1.5 APIドキュメントの徹底的な学習
サービスを統合するには、利用可能なすべてのAPIドキュメントを読み込む：
- 公式APIリファレンスドキュメント
- 認証と認可の要件
- レート制限とページネーションのパターン
- エラーレスポンスとステータスコード
- 利用可能なエンドポイントとそのパラメータ
- データモデルとスキーマ
包括的な情報を収集するには、必要に応じてWeb検索とWebFetchツールを使用します。
1.6 包括的な実装計画の作成
調査に基づいて、以下を含む詳細な計画を作成する：
ツール選択：
- 実装する最も価値のあるエンドポイント/操作をリストアップ
- 最も一般的で重要な使用例を可能にするツールを優先する
- 複雑なワークフローを可能にするために一緒に機能するツールを検討する
共有ユーティリティとヘルパー：
- 共通のAPIリクエストパターンを特定
- ページネーションヘルパーを計画
- フィルタリングとフォーマッティングユーティリティを設計
- エラー処理戦略を計画
入力/出力設計：
- 入力検証モデルを定義（PythonではPydantic、TypeScriptではZod、Rustではserde）
- 一貫したレスポンス形式（例：JSONまたはMarkdown）と設定可能な詳細レベル（例：DetailedまたはConcise）を設計
- 大規模な使用（数千のユーザー/リソース）を計画
- 文字数制限と切り捨て戦略を実装（例：25,000トークン）
エラー処理戦略：
- グレースフルな障害モードを計画
- 明確でアクション可能なLLMフレンドリーな自然言語エラーメッセージを設計し、さらなるアクションを促す
- レート制限とタイムアウトのシナリオを考慮
- 認証と認可のエラーを処理
フェーズ2：実装
包括的な計画ができたら、言語固有のベストプラクティスに従って実装を開始します。
2.1 プロジェクト構造のセットアップ
Pythonの場合：
- 単一の
.pyファイルを作成するか、複雑な場合はモジュールに整理（🐍 Pythonガイド参照）
- ツール登録にMCP Python SDKを使用
- 入力検証用のPydanticモデルを定義
Node/TypeScriptの場合：
- 適切なプロジェクト構造を作成（⚡ TypeScriptガイド参照）
package.jsonとtsconfig.jsonをセットアップ- MCP TypeScript SDKを使用
- 入力検証用のZodスキーマを定義
Rustの場合：
- Cargoプロジェクトを作成（🦀 Rustガイド参照）
Cargo.tomlに必要な依存関係を追加（tokio、serde、axum等）- 非同期ランタイムと適切なトレイト設計を使用
- 入力検証用のserdeモデルを定義
2.2 最初にコアインフラストラクチャを実装
実装を開始するには、ツールを実装する前に共有ユーティリティを作成する：
- APIリクエストヘルパー関数
- エラー処理ユーティリティ
- レスポンスフォーマット関数（JSONとMarkdown）
- ページネーションヘルパー
- 認証/トークン管理
2.3 体系的にツールを実装
計画内の各ツールについて：
入力スキーマを定義：
- 検証にPydantic（Python）、Zod（TypeScript）、またはserde（Rust）を使用
- 適切な制約を含める（最小/最大長、正規表現パターン、最小/最大値、範囲）
- 明確で説明的なフィールドの説明を提供
- フィールドの説明に多様な例を含める
包括的なDocstrings/説明を書く：
- ツールが何をするかの1行の要約
- 目的と機能の詳細な説明
- 例を含む明示的なパラメータタイプ
- 完全な戻り値タイプスキーマ
- 使用例（いつ使用するか、いつ使用しないか）
- 特定のエラーが発生した場合の進め方を説明するエラー処理ドキュメント
ツールロジックを実装：
- コード重複を避けるために共有ユーティリティを使用
- すべてのI/Oに対してasync/awaitパターンに従う
- 適切なエラー処理を実装
- 複数のレスポンス形式（JSONとMarkdown）をサポート
- ページネーションパラメータを尊重
- 文字数制限をチェックし、適切に切り捨て
ツールアノテーションを追加：
readOnlyHint: true（読み取り専用操作の場合）destructiveHint: false（非破壊的操作の場合）idempotentHint: true（繰り返し呼び出しが同じ効果を持つ場合）openWorldHint: true（外部システムと対話する場合）
2.4 言語固有のベストプラクティスに従う
この時点で、適切な言語ガイドをロード：
Pythonの場合：🐍 Python実装ガイドをロードして以下を確認：
- 適切なツール登録でMCP Python SDKを使用
model_configを持つPydantic v2モデル- 全体を通じて型ヒント
- すべてのI/O操作に対してAsync/await
- 適切なインポートの整理
- モジュールレベルの定数（CHARACTER_LIMIT、API_BASE_URL）
Node/TypeScriptの場合：⚡ TypeScript実装ガイドをロードして以下を確認：
server.registerToolを適切に使用.strict()を持つZodスキーマ- TypeScriptの厳密モードを有効化
any型なし - 適切な型を使用- 明示的なPromise戻り値型
- ビルドプロセスの設定（
npm run build）
フェーズ3：レビューと改良
初期実装後：
3.1 MCP Inspectorでのテストとデバッグ
MCP Inspectorは、MCPサーバーのテストとデバッグのための対話型開発ツールです。Web ベースのインターフェースを提供し、インストール不要で使用できます。
起動方法：
npx -y @modelcontextprotocol/inspector npx <package-name> <args>
npx @modelcontextprotocol/inspector uvx <package-name> <args>
npx @modelcontextprotocol/inspector node path/to/server/index.js args...
npx @modelcontextprotocol/inspector python path/to/server.py args...
npx @modelcontextprotocol/inspector ./target/release/server_name args...
主な機能：
- サーバー接続ペイン: トランスポート方法の設定とコマンドライン引数のカスタマイズ
- リソースタブ: 利用可能なリソースの表示とサブスクリプションテスト
- プロンプトタブ: プロンプトテンプレートの表示とカスタム入力でのテスト
- ツールタブ: ツールのスキーマ表示と実行テスト
- 通知ペイン: サーバーメッセージと受信通知のログ表示
開発ワークフロー：
- Inspector を起動して接続を確認
- 変更を反復的にテスト
- サーバーを再ビルドして再接続
- 影響を受ける機能を検証しながらメッセージを監視
3.2 コード品質レビュー
品質を確保するため、以下の点でコードをレビュー：
- DRY原則：ツール間でコードの重複なし
- 構成可能性：共有ロジックを関数に抽出
- 一貫性：類似の操作は類似の形式を返す
- エラー処理：すべての外部呼び出しにエラー処理がある
- 型安全性：完全な型カバレッジ（Python型ヒント、TypeScript型）
- ドキュメント：すべてのツールに包括的なdocstrings/説明がある
3.2 テストとビルド
重要： MCPサーバーは、stdio/stdinまたはsse/http経由でリクエストを待つ長時間実行プロセスです。メインプロセスで直接実行する（例：python server.pyやnode dist/index.js）と、プロセスが無期限にハングします。
サーバーをテストする安全な方法：
- 評価ハーネスを使用（フェーズ4参照）- 推奨アプローチ
- tmuxでサーバーを実行してメインプロセスの外に保つ
- テスト時にタイムアウトを使用：
timeout 5s python server.py
Pythonの場合：
- Python構文を検証：
python -m py_compile your_server.py
- ファイルを確認してインポートが正しく動作することを確認
- 手動でテストするには：tmuxでサーバーを実行し、メインプロセスで評価ハーネスでテスト
- または直接評価ハーネスを使用（stdioトランスポート用にサーバーを管理）
Node/TypeScriptの場合：
npm run buildを実行してエラーなしで完了することを確認- dist/index.jsが作成されたことを確認
- 手動でテストするには：tmuxでサーバーを実行し、メインプロセスで評価ハーネスでテスト
- または直接評価ハーネスを使用（stdioトランスポート用にサーバーを管理）
3.3 品質チェックリストの使用
実装品質を確認するには、言語固有のガイドから適切なチェックリストをロード：
フェーズ4：評価の作成
MCPサーバーを実装した後、その有効性をテストするための包括的な評価を作成します。
完全な評価ガイドラインについては✅ 評価ガイドをロードしてください。
4.1 評価目的の理解
評価は、LLMがあなたのMCPサーバーを効果的に使用して、現実的で複雑な質問に答えることができるかをテストします。
4.2 評価スクリプトの使用
TypeScript版評価スクリプト（Bun対応）：
評価ハーネスはscripts/ディレクトリにTypeScript版が用意されています。高速なBunランタイムを使用して実行できます。
cd scripts
bun install
bun run evaluation.ts eval.xml -t stdio -c python -a server.py
bun run dev eval.xml -t stdio -c node -a dist/index.js
詳細はscripts/README.mdを参照してください。
4.3 10個の評価質問の作成
効果的な評価を作成するには、評価ガイドで説明されているプロセスに従います：
- ツール検査：利用可能なツールをリストアップし、その機能を理解する
- コンテンツ探索：読み取り専用操作を使用して利用可能なデータを探索
- 質問生成：10個の複雑で現実的な質問を作成
- 回答検証：答えを確認するために各質問を自分で解く
4.3 評価要件
各質問は以下の条件を満たす必要があります：
- 独立性：他の質問に依存しない
- 読み取り専用：非破壊的な操作のみが必要
- 複雑性：複数のツール呼び出しと深い探索が必要
- 現実的：人間が実際に気にする実際の使用例に基づく
- 検証可能：文字列比較で検証できる単一の明確な答え
- 安定性：時間の経過とともに答えが変わらない
4.4 出力形式
この構造でXMLファイルを作成：
<evaluation>
<qa_pair>
<question>動物のコードネームを持つAIモデルの発表に関する議論を見つけてください。あるモデルには、ASL-Xという形式を使用する特定の安全指定が必要でした。斑点のある野生の猫にちなんで名付けられたモデルに対して、どの数字Xが決定されていましたか？</question>
<answer>3</answer>
</qa_pair>
</evaluation>
リファレンスファイル
📚 ドキュメントライブラリ
開発中に必要に応じてこれらのリソースをロードしてください：
コアMCPドキュメント（最初にロード）
- MCPプロトコル：
https://modelcontextprotocol.io/llms-full.txtから取得 - 完全なMCP仕様
- 📋 MCPベストプラクティス - 以下を含む普遍的なMCPガイドライン：
- サーバーとツールの命名規則
- レスポンス形式ガイドライン（JSON対Markdown）
- ページネーションのベストプラクティス
- 文字数制限と切り捨て戦略
- ツール開発ガイドライン
- セキュリティとエラー処理の標準
SDKドキュメント（フェーズ1/2でロード）
- Python SDK：
https://raw.githubusercontent.com/modelcontextprotocol/python-sdk/main/README.mdから取得
- TypeScript SDK：
https://raw.githubusercontent.com/modelcontextprotocol/typescript-sdk/main/README.mdから取得
言語固有の実装ガイド（フェーズ2でロード）
評価ガイド（フェーズ4でロード）
- ✅ 評価ガイド - 以下を含む完全な評価作成ガイド：
- 質問作成ガイドライン
- 回答検証戦略
- XML形式の仕様
- 質問と回答の例
- 提供されたスクリプトでの評価実行
