So baust du 2026 einen MCP-Server: Ein praxisnaher Leitfaden für Entwickler

Ein MCP-Server ist ein kleines Programm, das deine Tools, Daten und Prompts einem KI-Modell über das Model Context Protocol bereitstellt – den offenen Standard, den Anthropic im November 2024 eingeführt hat und der inzwischen von Claude, ChatGPT, Cursor und den meisten Agent-Frameworks unterstützt wird. Wenn du weißt, wie man einen MCP-Server baut, kannst du jede beliebige API, Datenbank oder jedes interne Skript in deutlich unter einer Stunde an einen KI-Agenten anbinden. Dieser Leitfaden geht den gesamten Weg durch: die Wahl des SDKs, das Definieren eines Tools, die Auswahl eines Transports, das lokale Testen und das Einbinden in einen echten Client – dazu die Sicherheitsfehler, die Server kompromittierbar machen.

Wir bauen TechRiseUps mit Claude Code, und genau dieser Recherchelauf erreicht DataForSEO über einen MCP-Server. Der folgende Workflow ist also der, den wir tatsächlich einsetzen, und keine Theorie am Whiteboard.

Was ist ein MCP-Server, und musst du überhaupt einen bauen?

Ein MCP-Server ist ein Prozess, der ein einheitliches JSON-RPC-Protokoll mit jedem MCP-kompatiblen Client (dem „Host“, etwa Claude Code oder Claude Desktop) spricht. Er stellt drei Arten von Fähigkeiten bereit: Tools (Funktionen, die das Modell mit Zustimmung des Nutzers aufrufen kann), Resources (schreibgeschützte Daten, die das Modell als Kontext heranziehen kann) und Prompts (wiederverwendbare Vorlagen). Der Client entdeckt diese über die Verbindung, sodass ein einziger Server über jeden Host hinweg funktioniert, ohne dass du individuellen Kleber schreiben musst.

Bevor du auch nur eine Zeile Code schreibst, prüfe, ob du überhaupt einen eigenen Server brauchst. Es gibt Tausende veröffentlichter Server für GitHub, Postgres, Slack, Dateisysteme und mehr; wenn es einen für dein System gibt, installiere ihn einfach. Bau deinen eigenen, wenn du eine private API, ein internes Tool oder maßgeschneiderte Geschäftslogik kapseln willst, die kein öffentlicher Server abdeckt. Das ist ehrlicherweise der 80-%-Fall – und genau der, auf den dieser Leitfaden abzielt.

Was du brauchst, bevor du loslegst

Die Voraussetzungen sind gering, und genau deshalb hat sich MCP so schnell verbreitet. Du brauchst eine Laufzeitumgebung für dein gewähltes SDK, einen MCP-kompatiblen Client zum Testen und das offizielle SDK-Paket. Für die lokale Entwicklung muss nichts öffentlich oder gehostet sein.

• Eine Laufzeitumgebung: Python 3.10+ (mit uv empfohlen) oder Node.js 18+ für TypeScript.
• Ein Client: Claude Desktop, Claude Code, Cursor oder der eigenständige MCP Inspector sind alle geeignet.
• Das SDK: mcp[cli] für Python oder @modelcontextprotocol/sdk für TypeScript, beide vom Protokoll-Team gepflegt.
• Eine API oder Datenquelle zum Bereitstellen. Ein lokaler stdio-Server braucht keine Domain, kein TLS und keinen offenen Port; das Hosting wird erst relevant, sobald du remote gehst (siehe unten).

Wähle dein SDK: Python (FastMCP) vs. TypeScript

Beide offiziellen SDKs bieten denselben Funktionsumfang, wähle also danach, wo deine Integration ohnehin schon lebt. Die FastMCP-Schicht von Python ist der schnellste Weg von der Idee zum laufenden Server; TypeScript ist die natürliche Wahl, wenn dein Tooling bereits in Node läuft.

	Python	TypeScript
Paket	mcp[cli] (python-sdk)	@modelcontextprotocol/sdk (typescript-sdk)
Server-Klasse	FastMCP	McpServer
Tool definieren	@mcp.tool-Decorator	server.registerTool() / server.tool()
Validierung	Type-Hints	Zod-Schema
Am besten für	Data-/ML-Stacks, schnellster Start	JS/TS-Codebasen, Web-Apps

Wenn du keinen bestehenden Stack hast, an den du dich halten musst, starte mit Python und FastMCP. Ein Tool ist einfach eine dekorierte Funktion – wenn du also eine Python-Funktion schreiben kannst, kannst du einen Server ausliefern.

Bau einen minimalen Server: definiere ein einziges Tool

Die eigentliche Arbeit besteht darin, ein Tool zu registrieren: ein Name, ein Input-Schema und eine asynchrone Funktion, die etwas tut und Text zurückgibt. Hier ist ein vollständiger Python-Server, der ein einzelnes get_weather-Tool bereitstellt.

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("weather")

@mcp.tool()
async def get_weather(city: str) -> str:
    """Return the current weather for a city."""
    # call your real API here
    return f"It's 21C and clear in {city}."

if __name__ == "__main__":
    mcp.run(transport="stdio")

Die TypeScript-Variante folgt derselben Idee: ein Zod-Schema für den Input, eine McpServer-Instanz und server.registerTool(), das ein content-Array aus { type: "text", text } zurückgibt. In beiden SDKs ist es der Docstring bzw. die Beschreibung, die das Modell liest, um zu entscheiden, wann es das Tool aufruft – schreibe sie also wie einen Prompt, nicht wie einen Code-Kommentar. Vage Beschreibungen sind der Grund Nummer eins, warum ein funktionierendes Tool nie aufgerufen wird.

Wähle einen Transport: stdio vs. Streamable HTTP

MCP definiert zwei Transporte, und die Wahl entscheidet darüber, wo dein Server laufen kann. Triff sie früh richtig, denn sie prägt das Deployment.

• stdio startet den Server als lokalen Subprozess und kommuniziert über stdin/stdout. Es ist die Standardvariante, braucht kein Netzwerk und ist richtig für alles, was lokale Dateien, lokale Datenbanken oder den eigenen Rechner eines Entwicklers berührt. Jeder Schnelleinstieg nutzt es.
• Streamable HTTP (das in der Spec-Überarbeitung von 2025 den älteren HTTP+SSE-Transport ersetzt hat) betreibt den Server als Webdienst, den andere Maschinen erreichen können. Nutze es für einen geteilten Team-Server oder eine gehostete Integration. Nur in diesem Fall gelten „Hosting-Anforderungen“: eine öffentliche URL, TLS und Authentifizierung.

Faustregel: Baue und teste auf stdio und wechsle erst dann zu Streamable HTTP, wenn mehr als eine Person oder Maschine den Server braucht.

Teste mit dem MCP Inspector, bevor du einen Client anbindest

Debugge einen neuen Server nicht über ein Chatfenster. Der MCP Inspector ist ein Browser-Tool, das sich direkt mit deinem Server verbindet, seine Tools und Resources auflistet und dich jedes einzelne mit beliebigen Eingaben aufrufen lässt – so siehst du die rohe Antwort statt der Umschreibung eines Modells.

npx @modelcontextprotocol/inspector
# opens a local UI (default http://localhost:6274)

Richte ihn auf deinen Befehl aus (bei einem stdio-Server ist das der Interpreter plus dein Skript), bestätige, dass jedes Tool mit dem erwarteten Schema erscheint, und rufe es auf. Wenn ein Tool hier einen Fehler wirft, wird es das auch in Claude tun, nur mit weniger Klarheit. Diese eine Gewohnheit beseitigt den Großteil der „Mein Server funktioniert nicht“-Frustration.

Binde ihn an Claude Code, Claude Desktop oder Cursor an

Sobald der Inspector zufrieden ist, registriere den Server über eine kleine JSON-Konfiguration bei einem Client. Jeder Host liest seine eigene Datei, doch der Aufbau ist identisch: ein Befehl, seine Argumente und etwaige Geheimnisse als Umgebungsvariablen.

{
  "mcpServers": {
    "weather": {
      "command": "uv",
      "args": ["run", "python", "/full/path/to/server.py"],
      "env": { "WEATHER_API_KEY": "..." }
    }
  }
}

Claude Code liest .mcp.json in deinem Projekt (oder claude mcp add), Claude Desktop liest claude_desktop_config.json, und Cursor nutzt sein Panel „Tools & Integrations“. Starte den Host neu, und das Tool erscheint bereit zum Aufruf. Wenn dir das gesamte Modell neu ist: Unser verständlicher Leitfaden zu MCP-Servern erklärt die Konzepte, die diese Anleitung voraussetzt.

Deploye einen Remote-MCP-Server auf einem VPS

Um einen Server mit einem Team zu teilen oder ihn an einen Cloud-Agenten anzubinden, betreibe ihn als Streamable-HTTP-Dienst auf einem kleinen VPS. Der Servercode ändert sich kaum; du tauschst den stdio-Transport gegen HTTP und stellst einen Reverse-Proxy davor. Was sich ändert, ist die betriebliche Checkliste: eine Domain, ein TLS-Zertifikat, ein Prozessmanager, damit er nach einem Neustart wieder hochfährt, und – ganz entscheidend – Authentifizierung, denn ein öffentlicher MCP-Endpunkt ist ein öffentliches Tor zu allem, was er kapselt.

Eine Instanz für 4–5 €/Monat reicht für die meisten internen Server locker aus; wir betreiben unsere eigene Infrastruktur bei WaseerHost für genau diese Art von dauerhaft laufendem Nebendienst. Die Mechanik von Server, Firewall und TLS ist dieselbe wie bei jedem kleinen Deployment, und unser Leitfaden zur sicheren ersten Stunde eines VPS führt genau diesen Teil von Anfang bis Ende durch. Setze einen Remote-Server niemals ohne eine vorgeschaltete Auth-Schicht ins Netz.

Sicherheit: die Fehler, die MCP-Server kompromittierbar machen

MCP gibt einem Sprachmodell die Fähigkeit, deinen Code auszuführen – behandle daher jedes Tool als Angriffsfläche. Die Schwachstellen wiederholen sich langweilig konsequent:

• Keine Eingabevalidierung. Zod-Schemas und Python-Type-Hints sind keine Deko. Ein Tool, das Modell-Output direkt in einen Shell-Befehl oder einen SQL-String durchreicht, ist eine Prompt-Injection-zu-RCE-Pipeline.
• Zu weit gefasste Tools. Ein einzelnes run_command-Tool ist bequem und gefährlich. Stelle enge, spezifische Fähigkeiten bereit, keine generelle Hintertür.
• Geheimnisse in der Konfiguration. Halte API-Schlüssel in Umgebungsvariablen, niemals fest im Code, und beschränke sie auf das Minimum, das das Tool braucht.
• Nicht authentifizierte Remote-Server. Ein öffentlicher Streamable-HTTP-Endpunkt ohne Auth ist eine offene Tür; verlange ein Token und begrenze die Rate.

Prompt Injection macht das brisanter als eine normale API: Der „Nutzer“, der dein Tool aufruft, kann ein Modell sein, das durch nicht vertrauenswürdige Inhalte manipuliert wurde. Diese Bedrohung haben wir ausführlich in KI-Agenten-Sicherheit und die Prompt-Injection-Krise behandelt. Geh davon aus, dass Tool-Eingaben feindselig sind, und du vermeidest das Schlimmste.

Häufig gestellte Fragen

Kann ich meinen eigenen MCP-Server bauen?

Ja, und es ist bewusst einfach gehalten. Mit dem offiziellen Python- oder TypeScript-SDK ist ein funktionierender Server, der ein einziges Tool bereitstellt, ein paar Dutzend Zeilen lang und läuft lokal ohne Hosting. Bau einen, wann immer du eine private API oder ein internes Tool bereitstellen musst, das kein öffentlicher Server bereits abdeckt.

Was sind die Anforderungen für das Hosting eines MCP-Servers?

Für die lokale Nutzung (stdio-Transport) gibt es außer der Laufzeitumgebung keine; der Server verlässt deine Maschine nie. Hosting wird nur bei einem Remote-Streamable-HTTP-Server relevant, der eine öffentliche URL, ein TLS-Zertifikat, einen Prozessmanager und Authentifizierung braucht. Ein kleiner VPS bewältigt das mühelos.

Welcher MCP-Server-Typ ist am beliebtesten?

Lokale stdio-Server dominieren den täglichen Entwickleralltag, weil sie die Standardvariante sind und keine Infrastruktur brauchen. Tools sind mit Abstand die am häufigsten genutzte Fähigkeit, noch vor Resources und Prompts, denn dem Modell das Handeln zu ermöglichen ist der Hauptreiz.

Wie lange dauert es, einen zu bauen?

Ein minimaler Server mit einem einzigen Tool ist mit beiden SDKs eine Sache von 15–30 Minuten. Die meiste echte Zeit fließt in die zugrunde liegende Integration (die API oder Datenbank, die du kapselst) und in das Schreiben klarer Tool-Beschreibungen, nicht in MCP selbst.

Sources

• Model Context Protocol — Build an MCP server (offizielles Tutorial): Kernkonzepte, der Schnelleinstieg mit dem Wetter-Server und Transport-Optionen.
• modelcontextprotocol/python-sdk (GitHub): das offizielle Python-SDK und die FastMCP-API.
• modelcontextprotocol/typescript-sdk (GitHub): das offizielle TypeScript-SDK, McpServer und die Tool-Registrierung.
• freeCodeCamp — How to build a custom MCP server with TypeScript: eine vollständige TypeScript-Anleitung mit Zod-Validierung und Client-Konfiguration.
• The Pragmatic Engineer — Building MCP servers in the real world: praktische Lektionen und Kompromisse aus der produktiven MCP-Arbeit.
• MCP Inspector (GitHub): das browserbasierte Tool zum Testen von Servern, bevor du einen Client anbindest.