Deployment + Distribution, von lokal zu installierbar
npm, Cloud Run, MCPize. Die drei Wege um Deinen MCP-Server rauszubringen.
Drei Deployment-Modi
1. Stdio + npm-Package (für lokale Server)
Du packst Deinen TypeScript-Server in ein npm-Paket. User installieren npm install -g mein-mcp-server und konfigurieren Claude Code. Der Server startet lokal beim User.
2. HTTP + Cloud Run / Fly / Railway (für zentrale Services) Dein Server läuft als HTTP-Service in der Cloud. User geben nur die URL an und machen OAuth. Zentrale Updates, Multi-User.
3. MCPize (der Marketplace-Weg) Service speziell für MCP-Deploys. Gleiche Code-Basis, MCPize packt, hostet, managed die HTTP-Route. Gut für schnelles Ausprobieren, weniger Kontrolle.
Stdio + npm (der häufigste Fall)
Schritt 1: TypeScript zu JavaScript kompilieren.
// package.json
{
"main": "dist/index.js",
"bin": {
"mein-mcp-server": "dist/index.js"
},
"scripts": {
"build": "tsc",
"prepublishOnly": "npm run build"
}
}
Die tsconfig.json muss "outDir": "dist" haben. Der bin-Eintrag macht das Paket ausfuehrbar.
Schritt 2: README.md mit Install-Anleitung.
# mein-mcp-server
## Install
claude mcp add mein-server -s user -- npx -y mein-mcp-server
## Config
Env-Var `MEIN_API_KEY` setzen.
Schritt 3: npm publish.
npm login # einmalig
npm publish --access public
Das war's. Jeder der npx -y mein-mcp-server aufruft, holt Dein Paket automatisch.
HTTP-Server + Cloud Run
Wenn User auf einen zentralen Service zugreifen sollen (Multi-Tenant, SaaS), brauchst Du HTTP. Das ist deutlich aufwaendiger.
Zusätzlich zum SDK brauchst Du:
- Express / Hono / Fastify für HTTP-Transport.
- OAuth-2.1-Flow wenn Multi-User (Magic-Link, Authorization-Code).
- Database für User-Storage.
- Rate-Limiting weil der Server oeffentlich ist.
- Logging + Monitoring.
Deployment dann: Dockerfile, dann push zu Google Cloud Run, Fly.io, Railway, AWS Runner. Kleine Compute-Pakete reichen meist (512 MB RAM, 1 CPU). Kostenpunkt: 5-20 EUR/Monat für kleine Services.
MCPize (der schnelle Weg)
MCPize ist ein spezialisierter MCP-Deploy-Service. Du schiebst Deinen Code, MCPize baut und hostet. Ideal für:
- Schnelles Prototypen in Produktion
- Nicht selbst hosten wollen
- Marketplace-Praesenz (User finden Deinen Server auf mcpize.run)
Limitation: weniger Kontrolle. Wenn Dein Server spezielle Build-Steps hat, muss MCPize die unterstützen (nicht alle werden).
Die Entscheidungs-Matrix
| Use-Case | Wahl | |---|---| | Persoenliches Tool, nur Du | stdio + lokal | | Team, keine User-Daten-Teilung | stdio + npm, intern per git | | Open Source für Dev-Community | stdio + npm + GitHub | | SaaS mit Login und Kunden-Daten | HTTP + Cloud Run + OAuth | | Prüfen ob jemand es will | MCPize |
Monetization wenn Du HTTP gehst
Wenn Du einen HTTP-Server mit User-Accounts hast:
- Stripe-Integration für Pro-Tiers
- Feature-Flag-Check pro Request: ist dieser User auf Pro-Tier?
- Rate-Limit unterschiedlich pro Tier (Free: 100 Calls/Tag, Pro: unlimited)
Die StudioMeyer MCP-SaaS-Server (memory, crm, geo) nutzen genau dieses Muster.
Letzte Lektion
Die letzte Lektion zeigt wie Du Deinen MCP-Server findbar machst: MCP-Marketplaces, Discovery-Standards, Community-Channels. Distribution ist nach dem Deploy noch eine halbe Woche Arbeit.