churn-mcp-server

Stellt die vorhandene Churn-Prediction-API von ml-production-template als MCP-Tool bereit, sodass ein MCP-fähiger Client (Claude Desktop, Claude Code oder ein beliebiger MCP-Client) predict_churn direkt aufrufen kann.

Design

Das ist ein dünner Adapter, keine Neuimplementierung des Modell-Servers. Er lädt das Modell nicht selbst – er ruft den bereits bereitgestellten /predict-Endpunkt des churn-api-Dienstes über HTTP auf. Das bedeutet:

• Die MCP-Schicht kann unabhängig vom Modell neu bereitgestellt oder skaliert werden.

• Wenn churn-api neu startet, muss dieser Adapter nicht neu starten.

• Das „echte“ ML-System (FastAPI + MLflow) bleibt unangetastet; MCP ist eine zusätzliche Schnittstelle darüber, genau so, wie man MCP tatsächlich in einen bestehenden Produktionsdienst integrieren würde, anstatt es in den Modell-Server einzubauen.

Zwei Tools werden bereitgestellt:

• predict_churn – das 19-Feld-Kundenschema der echten API, gibt churn_probability / churn_prediction / threshold_used zurück.

• check_model_health – ist ein Proxy für den /health-Endpunkt der API.

Related MCP server: MCP from API

Ein Hinweis zur Version

Das offizielle mcp-Python-SDK hat vor kurzem eine v2.0 veröffentlicht, die FastMCP in MCPServer umbenannt und die Importpfade verschoben hat. Dieses Projekt setzt mcp<2.0.0 fest und verwendet from mcp.server.fastmcp import FastMCP, da das zum Zeitpunkt des Schreibens weiterhin die stabile, gut dokumentierte Linie ist. Falls du das später liest und pip install mcp standardmäßig v2 lädt, musst du den Import übertragen (mcp.server.fastmcp.FastMCP → mcp.server.MCPServer) – schau in den Migrationsleitfaden des SDK, bevor du davon ausgehst, dass der folgende Code weiterhin unverändert funktioniert.

Lokaler Test (stdio, ohne Docker)

pip install -r requirements.txt
$env:MCP_TRANSPORT="stdio"
$env:CHURN_API_URL="http://localhost:8000"   # your local churn-api
python server.py

Trage den Server in Claude Desktops claude_desktop_config.json ein:

{
  "mcpServers": {
    "churn-predictor": {
      "command": "python",
      "args": ["C:\\path\\to\\churn-mcp-server\\server.py"],
      "env": { "CHURN_API_URL": "http://localhost:8000" }
    }
  }
}

Deployment im bestehenden kind-Cluster

Vorausgesetzt wird, dass das churn-api-Deployment und der zugehörige Service aus dem Kubernetes-Projekt bereits in deinem kind-Cluster laufen.

docker build -t churn-mcp-server:local .
kind load docker-image churn-mcp-server:local --name <your-cluster-name>
kubectl apply -f k8s/deployment.yaml
kubectl get pods -l app=churn-mcp-server

Verifizieren:

kubectl port-forward svc/churn-mcp-server 8080:80
curl http://localhost:8080/healthz

Ein echter Stolperstein, den man für das Vorstellungsgespräch kennen sollte

Ein einfaches GET /mcp mit Accept: text/event-stream? Nein: Ein bloßes GET /mcp liefert 406 Not Acceptable – der MCP-Streamable-HTTP-Transport erfordert Accept: text/event-stream, was eine normale Kubernetes-GET / httpGet-Probe nicht sendet. Das bringt eine naive Readiness-Probe, die direkt auf /mcpzeigt, zu Fall. Die Lösung hier:FastMCP.streamable_http_app()ergibt / liefert die zugrunde liegende Starlette-App, die man samt eigener/healthz-Route einhängen kann, die ein einfaches 200 zurückgibt – siehe unteres Ende von server.py`. Das ist eine legitime „Ich bin auf ein echtes Integrationsproblem gestoßen und habe verstanden warum“-Geschichte und damit eine stärkere Antwort im Vorstellungsgespräch als ein Projekt, bei dem nichts schiefging.

Was das demonstriert (präzise Formulierung für den Lebenslauf)

„Einen MCP-Server gebaut, der einen produktiv genutzten FastAPI-Modell-Serving-Endpunkt als aufrufbares Tool bereitstellt und zusammen mit dem bestehenden Dienst in Kubernetes eingesetzt wurde.“

Nicht zutreffend: „MCP“ als bloßes Skill-Tag zu beanspruchen, ohne erklären zu können, was MCP wirklich ist (ein Protokoll, um Tools für LLM-Clients bereitzustellen, kein Deployment- oder Hosting-Mechanismus).