Einen MCP-Server planen, was gehört rein

Die falsche Reihenfolge

Viele Entwickler starten so: "Ich habe eine Idee für einen MCP-Server. Lass mich npx create-mcp ausführen und loslegen."

Drei Wochen später: das Ding funktioniert technisch, aber keiner installiert es. Weil die fundamentale Frage nie beantwortet wurde.

Die fünf Fragen vor dem Code

1. Welches Problem löst der Server?

Nicht "was macht er", sondern "welches Problem macht er eine Stufe kleiner". Beispiel: "Claude hat keinen Zugriff auf mein Lexoffice" ist kein Problem. "Ich muss jeden Morgen manuell Rechnungen suchen um sie ins CRM zu übertragen" ist ein Problem.

Wenn Du die Frage nicht in einem Satz beantworten kannst, bau noch keinen Server.

2. Wer benutzt das?

Nur Du? Dann bau lokal, investier keine Zeit in Dokumentation, Distribution, Pricing. Mach es einfach.

Ein Team? Dann brauchst Du Installation-Anleitung, Config, vielleicht Multi-Tenant.

Publikum? Dann ist es ein Produkt. Mit Pricing, Marketing, Support. Viel mehr Arbeit als Du denkst.

3. Welche Tools gehören rein?

Die gemeinsame Falle: "Mein Server macht ALLES mit X." Zu breite Tool-Liste verwirrt das Modell. Es ruft das falsche Tool auf, gibt falsche Parameter.

Faustregel: 5-15 Tools. Wenn Du 40 Tools hast, split den Server in zwei.

Und: jedes Tool braucht einen klaren, unique Zweck. Nicht get_data und fetch_data und read_data die alle das gleiche tun.

4. Stdio oder HTTP?

Stdio-MCP-Server laufen lokal auf dem User-Rechner, starten automatisch wenn Claude sie braucht. Einfacher zu installieren (npm install -g), keine Hosting-Kosten.

HTTP-MCP-Server laufen remote, User gibt eine URL an, macht OAuth. Brauchen Hosting, aber erlauben zentrale Updates und User-Management.

Faustregel: Wenn der Server mit User-privaten Daten arbeitet (Files, Credentials), stdio. Wenn er eine zentrale Datenbank hat die geteilt wird, HTTP.

5. Wie monetarisierst Du?

Frag das früh. Drei Modelle heute sichtbar:

• Free + Open Source (community, Github-Stars, Pull-Requests. Führt vielleicht zu Auftraegen.)
• SaaS mit Tiers (zentrale Hosting, User bezahlen monatlich. mcp-nex macht das.)
• Desktop/Local + Pro (Server ist gratis installiert, Pro-Features unlocked durch Zahlung.)

Eine Entscheidung VOR dem Code, nicht nachher.

Was jetzt aufschreiben

Bevor Du npm init schreibst, hab diese Seite:

• Problem: Ein Satz.
• Zielgruppe: Wer, wie viele.
• Tool-Liste: Namen + ein-Satz-Zweck.
• Transport: stdio oder HTTP.
• Monetization: wenn ueberhaupt.

Wenn alle fünf Punkte klar sind, kannst Du in zwei Stunden das Skeleton bauen. Wenn nicht, wird's ein Monat.

Die Arbeit-zu-Value-Regel

MCP-Server-Code ist einfach. 200 Zeilen für einen guten 5-Tool-Server. Die Arbeit ist:

• 30% Code
• 30% Datenintegration (APIs abklopfen, Rate-Limits, Errors)
• 20% Dokumentation
• 20% Distribution (npm, GitHub, vielleicht Marketplaces)

Wenn Du glaubst Du bist in zwei Wochen fertig, plan vier.

Nächste Lektion

Wie das Skeleton aussieht. TypeScript, @modelcontextprotocol/sdk, der minimale Server in 40 Zeilen Code.