delivery-mcp-server

AIファーストデリバリーリーダービルドプログラムのPH.02。 delivery-copilotがインデックス化したプログラム文書（SOW、ステータスレポート、QBRノート、リスク台帳）をツール、リソース、プロンプトとして公開するMCP（Model Context Protocol）サーバー。あらゆるMCPホスト（Claude Desktop、Claude Code）が直接利用でき、アカウント単位の分離はPH.01からそのまま引き継がれています。

MCPは、ほとんどのデリバリー/PMバックグラウンドの候補者が実際に構築したことがない要素です。ほとんどの人はチャットクライアント内でMCPサーバーを使用したことがあるだけでしょう。これはゼロから構築されており、このREADMEは各構成要素の役割を説明する役割も兼ねています。

ステータス

構築・検証済み: 3つのツール、1つのリソース、1つのプロンプト。すべて実際のMCP ClientおよびClaude Codeのclaude mcp addを介してエンドツーエンドでテスト済み。

Related MCP server: Claude RAG MCP Pipeline

MCPとは何か、そしてなぜこのように構築されているのか

MCPは、ホストアプリケーション（Claude Desktop、Claude Code）がデータと機能を公開するサーバーと通信する方法を標準化します。アプリごとに個別の統合を行う代わりに、1つの統合で済みます。サーバーは3つの異なるプリミティブタイプを公開し、このビルドではそれらすべてを意図的に使用して、単に説明するのではなく実践的に区別を示しています。

• ツール — 会話の途中でモデルが自身で引数を選択して呼び出すアクション。search_delivery_docsがこのサーバーのメインツールです。

• リソース — ブラウザがページを取得するように、URIによってアプリケーションが読み込むことを選択する読み取り専用データ。モデルが単独で呼び出すものではありません。delivery://{account}/{filename}がこのサーバーのリソースです。目的のドキュメントがすでにわかっている場合に、ドキュメント全体を取得します。

• プロンプト — スラッシュコマンドのように、ユーザーが名前で呼び出すメッセージテンプレート。draft_status_updateがこのサーバーのプロンプトです。アカウントを選択すると、会話にあらかじめ作成された指示が挿入されます。

検索/生成の分割こそが実際のアーキテクチャ上の決定です。 delivery-copilot/ask.pyは、そのパイプライン内にモデルが他にないため、チャンクを取得し、Claudeを呼び出して引用付きの回答を1つのスクリプトで生成します。MCPサーバー内では、ホストの会話を実行しているモデルがすでにループ内に存在します。したがって、search_delivery_docsは取得のみを行い、マッチしたチャンクをデータとして返します。ホスト自身のモデルがそれらを読み取り、サーバーがツールのdocstring（サーバーが接地指示を残せる唯一の場所。システムプロンプトを所有していないため）に組み込まれた引用/拒否指示に導かれて、根拠のある回答を自身で作成します。言及する価値のある結果として、このサーバーはClaudeを0回呼び出します。 ANTHROPIC_API_KEYも課金リクエストもありません。ローカル埋め込みとベクトル検索のみで、まさにingest.pyがすでに行っていることです。生成コストは完全にホスト側の負担です。

分離はPH.01から変更なく引き継がれています。 すべてのツールはaccount引数を受け取り、そのアカウントのChromaコレクション（delivery_docs__<account>）のみを読み取ります。この層でも、使い捨ての2つ目のアカウントを使用して検証済みです。無関係な質問（meridian-healthだけが答えられる質問）をしても、自身の単一のメモ以外は何も返ってこず、Meridianのコンテンツは決して返されません。

リポジトリ構成 — なぜdelivery-copilotからのPythonインポートではないのか

このリポジトリは、delivery-copilotのコードではなく、chroma_db/にあるデータアーティファクトの1つのためだけに依存しています。クロスリポジトリのpip install -eも共有モジュールもありません。

• list_accounts()はclient.list_collections()を読み取り、delivery_docs__プレフィックスを削除します。data/raw/はまったく必要ありません。

• list_documents(account)は、そのコレクションのチャンクメタデータにすでに保存されている個別のsource値を読み取ります。

• delivery://リソースは、ingest.pyがすでに割り当てているsource::NチャンクIDから解析された元の順序でチャンクを連結することにより、ドキュメントを再構築します。

DELIVERY_DB_PATHを任意の構築済みChromaストア（デフォルト: ../delivery-copilot/chroma_db。両方のリポジトリが兄弟としてクローンされていることを前提）にポイントすれば、このサーバーは動作します。コード面では真に自己完結しており、独立してクローン可能で、ai-fundamentals-rigとdelivery-copilotが互いに独立しているのと同じ方法です。

保存しておく価値のある発見（環境）

mcp[cli]はpyjwt[crypto]→cryptographyをプルします。cryptographyはv46.0.4以降、x86_64 macOSのプレビルド済みホイールを提供しなくなりました（それ以降はarm64のみのリリース）。この（本物のIntel）マシンにインストールしようとするとソースからコンパイルしようとし、Rust/OpenSSLヘッダーがないために失敗しました。requirements.txtでcryptography==46.0.3に固定。これはx86_64ホイールを持つ最後のリリースで、pyjwtのcryptography>=3.4.0を快適に満たします。「pip install」がCPUアーキテクチャのホイールを暗黙のうちに前提としていることを思い出させてくれます。常にあるとは限りません。

また、MCP Python SDKの現在のメジャーバージョン（v2）は**Python 3.10+**を必要とします。このマシンのシステムPythonは3.9.6でした。公式のpython.orgインストーラを使用して、システムインタプリタと並行して、このリポジトリの.venv専用に3.13をインストールしました。

セットアップ

# needs delivery-copilot's index already built: `python ingest.py` in that repo first
python3.13 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

実行方法

手動テスト、ホスト不要 — 実際のインメモリClientを通じてすべてのツール/リソース/プロンプトを呼び出します:

python test_server.py

MCPインスペクター（インタラクティブ、ローカルWeb UIを開く）:

uv run mcp dev server.py     # or: pip install uv, then the same command

Claude Codeに登録:

claude mcp add delivery-copilot \
  -e DELIVERY_DB_PATH=/absolute/path/to/delivery-copilot/chroma_db \
  -- /absolute/path/to/delivery-mcp-server/.venv/bin/python /absolute/path/to/delivery-mcp-server/server.py

claude mcp list   # confirm it connects

その後、Claude Codeチャットで: "Using the delivery-copilot MCP server, who owns the Okta risk for meridian-health, per the docs?" — Claudeは自身でsearch_delivery_docsを呼び出し、返ってきた内容を引用します。

次は何か

PH.02は機能完了: 3つのツール、1つのリソース、1つのプロンプト。ローカルおよびClaude Codeを通じてライブでテスト済み。妨げにならない自然な拡張として、1つ目の実アカウントが存在すれば2つ目の実アカウント（ここにはmeridian-health固有のものはありません）。また、PH.03のエージェンティックなステータス/リスクエージェントは、ゼロから始めるのではなく、draft_status_updateを基に構築するのが合理的でしょう。

AIファーストデリバリーリーダービルドプログラムの一部。