Einen MCP-Server aufbauen bedeutet, einen kleinen Dienst zu schreiben, der über das Model Context Protocol Tools, Resources und Prompts an KI-Clients wie Claude bereitstellt. Sie wählen ein SDK (Python oder TypeScript), definieren mindestens ein Tool, wählen den Transport (stdio oder Streamable HTTP) und registrieren den Server im Client. Das Protokoll basiert auf JSON-RPC 2.0 und nimmt Ihnen über das SDK den gesamten Nachrichtenaustausch ab - Sie schreiben nur Ihre Fachlogik.

Drei Schnellantworten vorab:

• Für den ersten lauffähigen Server genügen ein SDK, eine Laufzeit (Python oder Node.js) und ein einziges Tool - realistisch in rund 30 Minuten machbar.
• Lokal entwickeln Sie mit dem stdio-Transport (kein Port, keine Auth); für entfernte Server nutzen Sie Streamable HTTP mit OAuth 2.1.
• MCP verbindet Agenten mit Tools und Daten. Für die Zusammenarbeit zwischen eigenständigen Agenten ist A2A zuständig, nicht MCP.

Was ein MCP-Server tatsächlich ist

Anthropic hat das Model Context Protocol am 25. November 2024 als offenen Standard eingeführt, um KI-Anwendungen mit externen Systemen zu verbinden - Dateisysteme, Datenbanken, Geschäftssysteme, Entwickler-Tools. Die Autoren sind David Soria Parra und Justin Spahr-Summers. Technisch ist MCP ein JSON-RPC-2.0-Protokoll über austauschbare Transporte. Statt für jede Tool-Anbindung ein eigenes Format zu erfinden, sprechen Client und Server dieselbe Sprache.

Ein MCP-Server stellt dem Client drei Primitive bereit:

• Tools: Funktionen, die das Modell aktiv aufrufen kann (z. B. „Wetter abfragen", „Datensatz schreiben"). Das ist der wichtigste und häufigste Baustein.
• Resources: lesbare Datenquellen, die der Client in den Kontext laden kann (Dateien, Datenbank-Inhalte, Konfigurationen).
• Prompts: vordefinierte, parametrisierbare Vorlagen, die der Nutzer im Client aufrufen kann.

Für den Einstieg konzentrieren Sie sich ausschließlich auf ein Tool. Resources und Prompts kommen später dazu.

Schritt 1: Transport wählen - stdio oder HTTP

Die erste Architektur-Entscheidung betrifft den Transport. MCP unterstützt mehrere Varianten, in der Praxis sind zwei relevant.

Empfehlung: Beginnen Sie mit stdio. Der Client startet Ihren Server als lokalen Prozess und kommuniziert über Standard-Input/Output. Es gibt keinen Port, keine TLS-Konfiguration und keine Authentifizierung zu klären. Sobald Ihr Server remote laufen, von mehreren Clients genutzt oder hinter eine Zugriffskontrolle gestellt werden soll, migrieren Sie auf Streamable HTTP. Diese Variante wurde mit der April-2025-Revision der Spezifikation eingeführt (zusammen mit OAuth-2.1-Unterstützung, JSON-RPC-Batching und Tool-Annotations) und löste das ursprüngliche reine Server-Sent-Events-Modell ab. Die November-2025-Revision ergänzte unter anderem asynchrone Operationen, Statelessness und Server-Identity.

Schritt 2: SDK wählen - Python oder TypeScript

Offizielle SDKs existieren für alle großen Programmiersprachen; die beiden meistgenutzten sind Python und TypeScript (zusammen über 97 Mio. monatliche Downloads, Stand 2026). Die Wahl folgt schlicht Ihrem bestehenden Stack:

• Python: ideal für Data-/ML-nahe Teams und schnelle Prototypen.
• TypeScript: ideal für Node.js-/Next.js-orientierte Teams und Web-Stacks.

Beide SDKs übernehmen das JSON-RPC-Handling, die Capability-Aushandlung und die Transport-Anbindung. Sie deklarieren ein Tool mit Name, Beschreibung und Parameter-Schema und schreiben die eigentliche Funktion.

Schritt 3: Minimal-Server mit einem Tool (Pseudocode)

Das folgende Pseudocode-Beispiel zeigt einen Server mit genau einem Tool, das eine Wechselkurs-Umrechnung vornimmt. Die Logik ist bewusst trivial - es geht um die Struktur.

```

Pseudocode (an Python-SDK-Stil angelehnt)

server = MCPServer(name="fx-tools")

@server.tool(
name="convert_currency",
description="Rechnet einen Betrag von einer Währung in eine andere um. "
"Erwartet betrag (Zahl), von (ISO-Code), nach (ISO-Code).",
input_schema={
"type": "object",
"properties": {
"betrag": {"type": "number"},
"von": {"type": "string"},
"nach": {"type": "string"}
},
"required": ["betrag", "von", "nach"]
}
)
def convert_currency(betrag, von, nach):
kurs = lookup_rate(von, nach) # eigene Fachlogik
ergebnis = round(betrag * kurs, 2)
return {"ergebnis": ergebnis, "kurs": kurs}

WICHTIG: Logging NUR auf stderr, niemals stdout (zerstört JSON-RPC)

log_to_stderr("Server startet")

server.run(transport="stdio")
```

Drei Dinge sind hier entscheidend und werden häufig übersehen:

1. Die Beschreibung ist nicht Dekoration. Das Modell entscheidet allein anhand von Name und Beschreibung, ob und wie es das Tool aufruft. Vage Beschreibungen führen zu falschen oder ausbleibenden Aufrufen.
2. Das input_schema (JSON Schema) definiert die Parameter verbindlich. Ohne korrektes Schema kann der Client die Argumente nicht validieren.
3. Beim stdio-Transport ist stdout für das Protokoll reserviert. Jegliches Logging muss auf stderr gehen - sonst zerbricht der JSON-RPC-Strom.

Schritt 4: Server im Client registrieren und testen

Bei stdio registrieren Sie den Server, indem Sie dem Client den Startbefehl mitteilen. In Clients wie Claude Desktop geschieht das über eine Konfigurationsdatei, die in etwa diese Form hat:

```
{
"mcpServers": {
"fx-tools": {
"command": "python",
"args": ["pfad/zu/server.py"]
}
}
}
```

Nach einem Neustart des Clients erscheint Ihr Tool. Testen Sie es in dieser Reihenfolge:

1. Discovery prüfen: Taucht convert_currency in der Tool-Liste des Clients auf? Wenn nicht, scheitert meist der Start des Subprozesses (falscher Pfad, fehlende Abhängigkeit).
2. Aufruf provozieren: Stellen Sie eine Frage, die das Tool auslöst („Wie viel sind 500 EUR in CHF?"). Der Client sollte das Tool mit den richtigen Argumenten aufrufen.
3. Antwort prüfen: Liefert der Server ein wohlgeformtes Ergebnis zurück, das der Client in seine Antwort einbettet?

Für die Fehlersuche unabhängig vom Modell hilft der offizielle MCP Inspector - ein eigenständiges Werkzeug aus dem MCP-Projekt, mit dem Sie Tools direkt aufrufen und das JSON-RPC-Protokoll mitlesen können. Das beschleunigt das Debugging erheblich.

Konkretes Beispiel mit Zahlen

Angenommen, Sie binden eine interne Preisliste an. Der Server stellt ein Tool get_product_price bereit. Ein Mitarbeiter fragt im Client: „Was kostet Artikel A-204 in der Variante L?". Ohne MCP müsste das Modell raten oder halluzinieren. Mit dem Tool ruft das Modell get_product_price(sku="A-204", variante="L") auf, der Server liefert {"preis": 49.90, "waehrung": "EUR", "lager": 12} zurück, und das Modell antwortet faktenbasiert. Der gesamte Implementierungsaufwand für ein solches Read-only-Tool liegt bei einer Datei und wenigen Dutzend Zeilen - der Großteil der eingangs genannten 30 Minuten entfällt auf das Anbinden Ihrer bestehenden Datenquelle, nicht auf das Protokoll.

Häufige Fehler

• Logging auf stdout: Der häufigste Anfängerfehler beim stdio-Transport. Alles, was nicht JSON-RPC ist, muss auf stderr.
• Vage Tool-Beschreibungen: Das Modell ruft das Tool nicht oder falsch auf. Schreiben Sie Beschreibungen wie eine API-Doku für einen Kollegen.
• Fehlendes oder falsches JSON-Schema: Pflichtfelder nicht markiert, Typen unpräzise - der Client kann Argumente nicht validieren.
• Zu weite Berechtigungen: Ein Tool, das mehr darf als nötig, ist eine Angriffsfläche. Least-Privilege gilt von der ersten Zeile an.
• Sicherheitslücken durch Vertrauensannahmen: Dokumentiert sind 2025/2026 unter anderem indirekte Prompt-Injection über Tool-Beschreibungen, Tool-Poisoning (Invariant Labs WhatsApp-PoC, März 2025), Look-alike-Server-Squatting, CyberArks Full-Schema-Poisoning (jeder Teil eines Tool-Schemas kann Injektionspunkt sein) und der „Toxic Agent Flow" über manipulierte GitHub-Issues. Ursache ist MCPs grundsätzlich optimistisches Trust-Modell, das syntaktische Korrektheit mit semantischer Sicherheit gleichsetzt. Die Absicherung liegt beim Betreiber: Sandboxing, scope-begrenzte Tokens, OAuth 2.1 für HTTP-Transporte - und keine automatische Installation von MCP-Servern aus unvertrauenswürdigen Registries.

Hinweis Stand 2026

MCP ist 2026 der getragene Branchenstandard für Agent-zu-Tool: Am 9. Dezember 2025 hat Anthropic das Protokoll an die neu gegründete Agentic AI Foundation unter der Linux Foundation übergeben - mitgegründet von Anthropic, Block und OpenAI, mit Platinum-Support von AWS, Bloomberg, Cloudflare, Google und Microsoft. Unterstützt wird MCP unter anderem von OpenAI (seit März 2025), Google DeepMind (April 2025), Microsoft Copilot Studio, SAP Joule, Salesforce Agentforce sowie n8n und LangGraph. Claude verfügt über ein Verzeichnis mit über 75 offiziellen MCP-Connectoren. Für die Zusammenarbeit zwischen eigenständigen Agenten setzen Sie nicht auf MCP, sondern auf A2A - die Faustregel lautet: MCP für Capabilities, A2A für Collaboration.

Für Agenturen und B2B

Für DACH-Agenturen ist ein eigener MCP-Server der direkte Weg, proprietäre Fähigkeiten - eine Keyword-Research-Funktion, ein internes CMS, eine Preis-API - herstellerübergreifend nutzbar zu machen, ohne für jeden Client eine Sonderintegration zu bauen. Ein einmal sauber gebauter MCP-Server lässt sich über Produktlinien hinweg wiederverwenden. Für B2B-Entscheider gilt: Wenn Sie 2026 Agenten einsetzen, werden Sie MCP-Server konsumieren oder schreiben - geplant oder nicht. Behandeln Sie dabei jedes Tool als Berechtigungs- und Audit-relevant. Wir bei Blck Alpaca konzipieren MCP-Server entlang von Least-Privilege, sauberen Schemata und nachvollziehbaren Audit-Trails - sprechen Sie uns an, wenn Sie eine interne Datenquelle DSGVO-konform an Ihre KI-Agenten anbinden möchten.