delivery-mcp-server

PH.02 des AI-Forward Delivery Leader Build Program. Ein MCP (Model Context Protocol)-Server, der die indizierten Programmdokumente von delivery-copilot – SOW, Statusberichte, QBR-Notizen, Risikoregister – als Tools, eine Ressource und einen Prompt bereitstellt, die jeder MCP-Host (Claude Desktop, Claude Code) direkt verwenden kann, mit einer pro Account isolierten Datenhaltung, die direkt aus PH.01 übernommen wurde.

MCP ist der Teil, den fast kein Kandidat mit Delivery/PM-Hintergrund tatsächlich selbst gebaut hat: Die meisten haben einen MCP-Server innerhalb eines Chat-Clients genutzt. Dieser hier wurde von Grund auf neu entwickelt, und diese README dient gleichzeitig als Erklärung, wozu die einzelnen Komponenten dienen.

Status

Erstellt und verifiziert: 3 Tools, 1 Resource, 1 Prompt, alle End-to-End getestet über einen echten MCP-Client und über claude mcp add in Claude Code.

Was MCP ist und warum es so aufgebaut ist

MCP standardisiert, wie eine Host-Anwendung (Claude Desktop, Claude Code) mit einem Server kommuniziert, der Daten und Funktionalitäten bereitstellt – eine Integration statt einer maßgeschneiderten pro App. Ein Server stellt drei verschiedene primitive Typen bereit, und dieser Build verwendet alle drei bewusst, um den Unterschied praktisch zu zeigen, anstatt ihn nur zu beschreiben:

• Tools — eine Aktion, die das Modell während eines Gesprächs selbstständig aufruft und dabei seine eigenen Argumente wählt. search_delivery_docs ist das Hauptwerkzeug dieses Servers.

• Resources — schreibgeschützte Daten, die die Anwendung per URI lädt, so wie ein Browser eine Seite abruft – nicht etwas, das das Modell von sich aus aufruft. delivery://{account}/{filename} ist die Ressource dieses Servers: Rufen Sie ein ganzes Dokument ab, wenn Sie bereits wissen, welches Sie möchten.

• Prompts — eine Nachrichtenvorlage, die eine Person namentlich aufruft, wie ein Slash-Befehl. draft_status_update ist der Prompt dieses Servers: Wählen Sie einen Account aus, und eine vorgefertigte Anweisung wird in das Gespräch eingefügt.

Die Trennung von Abruf und Generierung ist die eigentliche architektonische Entscheidung hier. delivery-copilot/ask.py ruft Chunks ab und ruft Claude auf, um eine zitierte Antwort in einem Skript zu generieren, da nichts anderes in dieser Pipeline ein Modell ist. Innerhalb eines MCP-Servers ist bereits ein Modell im Spiel – was auch immer die Host-Konversation ausführt. Daher führt search_delivery_docs nur den Abruf durch und gibt die passenden Chunks als Daten zurück; das eigene Modell des Hosts liest sie und verfasst die belegte Antwort selbst, geleitet von der Zitier-/Verweigerungsanweisung, die in den Docstring des Tools eingebettet ist (der einzige Ort, an dem ein Server Grounding-Anweisungen hinterlassen kann, da er nicht den System-Prompt besitzt). Eine erwähnenswerte Konsequenz: Dieser Server ruft Claude null Mal auf. Kein ANTHROPIC_API_KEY, keine berechnete Anfrage – es handelt sich um lokale Einbettung und Vektorsuche, genau das, was ingest.py bereits tut. Die Generierungskosten trägt vollständig der Host.

Die Isolation wird unverändert aus PH.01 übernommen. Jedes Tool nimmt ein account-Argument entgegen und liest nur die Chroma-Sammlung dieses Accounts (delivery_docs__<account>) – erneut auf dieser Ebene überprüft mit einem Wegwerf-Zweitaccount: Die Frage nach einer irrelevanten Sache (etwas, das nur meridian-health beantworten könnte) brachte nur die eigene einzelne Notiz zurück, niemals Meridian-Inhalte.

Repo-Aufbau – warum dies kein Python-Import von delivery-copilot entfernt ist

Dieses Repo hängt von delivery-copilot für genau eine Sache ab: das Datenartefakt unter chroma_db/, nicht dessen Code. Kein repoübergreifendes pip install -e, keine gemeinsamen Module:

• list_accounts() liest client.list_collections() und entfernt das Präfix delivery_docs__ – benötigt data/raw/ überhaupt nicht.

• list_documents(account) liest die eindeutigen source-Werte, die bereits in den Chunk-Metadaten dieser Sammlung gespeichert sind.

• Die delivery://-Ressource rekonstruiert ein Dokument, indem sie seine Chunks in der ursprünglichen Reihenfolge konkateniert (aus den source::N-Chunk-IDs, die ingest.py bereits vergibt).

Setzen Sie DELIVERY_DB_PATH auf einen beliebigen erstellten Chroma-Speicher (Standard: ../delivery-copilot/chroma_db, vorausgesetzt, beide Repos sind als Geschwister geklont) und dieser Server funktioniert – wirklich in sich geschlossen, unabhängig klonbar, passend dazu, wie ai-fundamentals-rig und delivery-copilot jeweils unabhängig voneinander sind.

Eine erwähnenswerte Erkenntnis (Umgebung)

mcp[cli] zieht pyjwt[crypto] → cryptography nach sich. cryptography hat ab v46.0.4 die vorgefertigten x86_64 macOS Räder eingestellt (seither nur arm64) – die Installation auf diesem (echten Intel-)Rechner versuchte, aus dem Quellcode zu kompilieren, und scheiterte ohne Rust/OpenSSL-Header. Habe cryptography==46.0.3 in requirements.txt festgeschrieben, die letzte Version mit einem x86_64 Rad, die pyjwt's cryptography>=3.4.0 bequem erfüllt. Eine Erinnerung daran, dass pip install stillschweigend annimmt, dass Ihre CPU-Architektur ein Rad hat – das ist nicht immer der Fall.

Außerdem: Die aktuelle Hauptversion des MCP Python SDK (v2) erfordert Python 3.10+; das System-Python dieses Rechners war 3.9.6. Habe 3.13 über den offiziellen python.org-Installer installiert, zusätzlich zum System-Interpreter, speziell für das .venv dieses Repos.

Einrichtung

# 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

Ausführen

Manueller Test, kein Host erforderlich – ruft jedes Tool/Resource/Prompt über einen echten In-Memory-Client auf:

python test_server.py

MCP Inspector (interaktiv, öffnet eine lokale Weboberfläche):

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

Bei Claude Code registrieren:

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

Dann, in einem Claude Code-Chat: „Wer besitzt das Okta-Risiko für meridian-health, laut den Dokumenten, unter Verwendung des delivery-copilot MCP-Servers?“ – Claude ruft search_delivery_docs selbst auf und zitiert, was zurückkommt.

Was kommt als Nächstes

PH.02 ist feature-complete: 3 Tools, 1 Resource, 1 Prompt, lokal und live durch Claude Code getestet. Naheliegende Erweiterungen, die nicht blockieren: ein zweiter echter Account, sobald einer existiert (nichts hier ist meridian-health-spezifisch), und der agentische Status-/Risiko-Agent von PH.03 könnte sinnvollerweise auf draft_status_update aufbauen, anstatt bei Null anzufangen.

Teil des AI-Forward Delivery Leader Build Program.