Eigenen MCP Server erstellen: Architektur und Praxisbeispiel mit Python

Ein eigener MCP Server klingt zunächst nach einem komplexen KI-Projekt. Tatsächlich lässt sich ein erster funktionierender Server mit wenigen Zeilen Python erstellen.

Interessant wird MCP allerdings nicht durch einen simplen Demo-Server. Spannend wird das Model Context Protocol, wenn eine KI über klar definierte Schnittstellen auf eigene Daten, APIs oder administrative Funktionen zugreifen darf.

Genau das bauen wir in diesem Tutorial. Wir erstellen einen kleinen MCP Server für Linux, über den ein MCP-fähiger KI-Client den Zustand ausgewählter systemd-Dienste abfragen kann. Dabei bekommt die KI ausdrücklich keine freie Shell. Stattdessen darf sie ausschließlich vorher definierte Dienste prüfen.

Das Beispiel zeigt damit gleichzeitig die wichtigsten Prinzipien einer vernünftigen MCP-Architektur:

• MCP Host, Client und Server sauber trennen
• Tools kontrolliert bereitstellen
• Resources als Kontextquelle nutzen
• Prompts definieren
• Eingaben validieren
• Berechtigungen begrenzen
• lokale und Remote-Transporte unterscheiden
• MCP Server testen
• Sicherheitsgrenzen bereits beim Design berücksichtigen

Was ist ein MCP Server?

MCP steht für Model Context Protocol. Das offene Protokoll standardisiert die Kommunikation zwischen KI-Anwendungen und externen Systemen. Die Grundlagen zu Host, Client und Server erklären wir ausführlich in MCP einfach erklärt: Was ist das Model Context Protocol? (Zum Artikel).

Ein MCP Server kann beispielsweise Zugriff auf folgende Systeme bereitstellen:

• Dateien
• Datenbanken
• REST-APIs
• Monitoring-Systeme
• Ticketsysteme
• Git-Repositories
• interne Unternehmensdienste
• Cloud-Plattformen
• Linux-Systeme
• Automatisierungswerkzeuge

Wichtig ist dabei eine häufige Fehlannahme: Der MCP Server ist nicht die KI. Er kommuniziert normalerweise auch nicht direkt mit dem Sprachmodell.

Die offizielle MCP-Architektur unterscheidet drei Komponenten:

Benutzer
↓
KI-Anwendung / MCP Host
↓
MCP Client
↓
MCP Server
├── Tool
├── Resource
└── Prompt
↓
Dateien / APIs / Linux / Datenbank / Infrastruktur

Der Host ist beispielsweise eine KI-Anwendung oder eine Entwicklungsumgebung. Innerhalb dieses Hosts befindet sich ein MCP Client. Dieser Client kommuniziert über das Model Context Protocol mit deinem MCP Server. Der Server stellt anschließend genau die Funktionen und Informationen bereit, die du ihm erlaubt hast.

Diese Trennung ist wichtig, weil sie verhindert, dass für jedes KI-System eine vollständig eigene Integration entwickelt werden muss.

Die drei wichtigsten Bausteine eines MCP Servers

Ein MCP Server stellt im Kern drei unterschiedliche Arten von Funktionen bereit:

1. Tools

Tools sind ausführbare Funktionen. Ein Tool könnte beispielsweise heißen: service_status. Die KI könnte es anschließend mit einem Parameter aufrufen: service = nginx. Der MCP Server führt die hinterlegte Python-Funktion aus und liefert das Ergebnis zurück.

Weitere typische Tools wären:

• get_server_status
• check_backup
• create_ticket
• restart_container
• query_database
• get_certificate_expiry

Tools sind besonders mächtig, weil sie Aktionen ausführen können. Damit stellen sie gleichzeitig den sicherheitskritischsten Teil vieler MCP Server dar.

2. Resources

Resources stellen Informationen bereit. Eine Resource könnte beispielsweise die Liste der erlaubten Linux-Dienste enthalten, oder die Dokumentation einer internen API.

Weitere Beispiele: config://production, documentation://backup-system, server://inventory, policy://allowed-services.

Resources eignen sich gut für Informationen, die ein KI-System lesen soll, ohne dafür eine Aktion auszuführen.

3. Prompts

Ein MCP Server kann außerdem vorbereitete Prompts bereitstellen. Ein Prompt könnte beispielsweise definieren:

Analysiere den Dienststatus und erkläre mögliche Ursachen,
ohne Änderungen am Server durchzuführen.

Dadurch lassen sich wiederkehrende Arbeitsabläufe standardisieren.

Die aktuelle offizielle Python-Dokumentation beschreibt Tools, Resources und Prompts genau als die drei zentralen Server-Primitives. Namen, Beschreibungen und Schemas können dabei direkt aus Python-Funktionen, Docstrings und Typinformationen erzeugt werden.

MCP Server lokal oder als Remote MCP Server?

Bevor wir mit Python beginnen, sollten wir noch entscheiden, wie der Server erreichbar sein soll. MCP unterstützt unterschiedliche Transportwege. Für neue Implementierungen sind vor allem zwei interessant:

Transport	Verwendung
STDIO	lokaler MCP Server
Streamable HTTP	Remote MCP Server

STDIO

STDIO eignet sich besonders für lokale MCP Server. Der MCP Host startet den Server dabei als eigenen Prozess und kommuniziert über Standard Input und Standard Output mit ihm.

Das ist ideal für: lokale Entwicklerwerkzeuge, Desktop-Anwendungen, Coding-Agenten, lokale Administrationswerkzeuge und persönliche MCP Server.

STDIO ist beim aktuellen Python SDK auch der Standardtransport.

Streamable HTTP

Soll der MCP Server über das Netzwerk erreichbar sein, kommt Streamable HTTP zum Einsatz. Beispielsweise:

KI Client
↓ HTTPS
Reverse Proxy
↓
MCP Server
├── interne API
├── Monitoring
└── Datenbank

Für neue Remote-Implementierungen sollte nicht mehr auf den alten HTTP+SSE-Transport gesetzt werden. Die aktuelle MCP-Spezifikation vom 28. Juli 2026 setzt verstärkt auf einen zustandslosen Protokollkern. Der Legacy-SSE-Transport gilt inzwischen als deprecated.

Praxisbeispiel: Eigenen MCP Server mit Python erstellen

Jetzt bauen wir unseren Server. Das Ziel lautet: Ein KI-System darf den Status einiger freigegebener Linux-Dienste über MCP abfragen. Wir erlauben nginx, ssh und docker. Nicht erlaubt sind beliebige Dienstnamen oder freie Shell-Befehle.

Damit vermeiden wir eine typische Fehlkonstruktion wie:

subprocess.run(command, shell=True)

Ein solches universelles Tool würde aus einem MCP Server praktisch eine Remote-Shell machen. Das wollen wir ausdrücklich nicht.

Schritt 1: Python-Projekt anlegen

Das aktuelle MCP Python SDK benötigt Python 3.10 oder neuer. Die offizielle Dokumentation beschreibt Version 2 als aktuelle stabile Release-Linie.

Mit uv kann das Projekt beispielsweise so erstellt werden:

uv init mcp-linux-status
cd mcp-linux-status
uv add "mcp[cli]"

Alternativ funktioniert auch pip:

python3 -m venv .venv
source .venv/bin/activate

pip install "mcp[cli]"

Danach erstellen wir: server.py

Schritt 2: MCP Server erstellen

Unser Grundgerüst sieht folgendermaßen aus:

from mcp.server import MCPServer

mcp = MCPServer("Linux Service Status")

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

Bereits damit existiert ein MCP Server. Allerdings kann er noch nichts besonders Interessantes. Deshalb ergänzen wir jetzt unser erstes Tool.

Schritt 3: Ein MCP Tool erstellen

Wir definieren zunächst eine Allowlist.

ALLOWED_SERVICES = {
    "nginx",
    "ssh",
    "docker",
}

Nur diese Dienste dürfen geprüft werden. Danach erstellen wir unser Tool:

import subprocess
from mcp.server import MCPServer

mcp = MCPServer("Linux Service Status")

ALLOWED_SERVICES = {
    "nginx",
    "ssh",
    "docker",
}

@mcp.tool()
def service_status(service: str) -> dict:
    """Liefert den systemd-Status eines freigegebenen Dienstes."""
    if service not in ALLOWED_SERVICES:
        return {
            "service": service,
            "status": "denied",
            "message": "Dieser Dienst ist nicht freigegeben.",
        }

    result = subprocess.run(
        ["systemctl", "is-active", service],
        capture_output=True,
        text=True,
        timeout=5,
        check=False,
    )

    status = result.stdout.strip()
    if not status:
        status = result.stderr.strip()

    return {
        "service": service,
        "status": status,
        "returncode": result.returncode,
    }

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

Unser MCP Server besitzt damit das Tool service_status. Ein Client kann beispielsweise anfragen: service_status("nginx") und bekommt eine strukturierte Antwort zurück. Zum Beispiel:

{
  "service": "nginx",
  "status": "active",
  "returncode": 0
}

Warum eine Allowlist so wichtig ist

Man könnte natürlich einfach schreiben:

subprocess.run(["systemctl", "is-active", service])

und jeden beliebigen Dienstnamen akzeptieren. Noch gefährlicher wäre:

subprocess.run(user_input, shell=True)

Damit könnte ein Tool schnell zu einer universellen Befehlsausführung werden. Ein sinnvoll aufgebauter MCP Server verfolgt stattdessen ein anderes Prinzip:

KI
↓
definierte MCP Tools
↓
Validierung
↓
Allowlist
↓
begrenzte Betriebssystemfunktion

Die KI erhält damit nicht Shell-Zugriff, sondern lediglich die Fähigkeit, eine genau definierte Frage an das Betriebssystem zu stellen. Das ist ein erheblicher Unterschied.

Schritt 4: Eine MCP Resource hinzufügen

Nun wollen wir dem Client mitteilen können, welche Dienste überhaupt abgefragt werden dürfen. Dafür erstellen wir eine Resource:

@mcp.resource("service-policy://allowed")
def allowed_services() -> str:
    """Liste der über MCP freigegebenen Dienste."""
    return "\n".join(sorted(ALLOWED_SERVICES))

Damit besitzt der Server zusätzlich die Resource service-policy://allowed. Der Client kann sie lesen und bekommt beispielsweise:

docker
nginx
ssh

Resources eignen sich hervorragend für solche Metainformationen.

Schritt 5: Einen MCP Prompt ergänzen

Zusätzlich bauen wir einen kleinen Diagnose-Prompt:

@mcp.prompt()
def diagnose_service(service: str) -> str:
    """Erstellt einen sicheren Prompt zur Dienstdiagnose."""
    return (
        f"Analysiere den Status des Linux-Dienstes '{service}'. "
        "Nutze ausschließlich lesende Prüfungen. "
        "Führe keine Änderungen, Neustarts oder "
        "Konfigurationsänderungen ohne ausdrückliche Freigabe durch."
    )

Unser Server bietet jetzt alle drei grundlegenden MCP-Bausteine:

Linux Service MCP Server
├── Tool
│   └── service_status
├── Resource
│   └── service-policy://allowed
└── Prompt
    └── diagnose_service

Damit haben wir bereits einen kleinen, aber sinnvoll strukturierten MCP Server.

Der komplette MCP Server

Unsere Datei server.py sieht damit folgendermaßen aus:

import subprocess
from mcp.server import MCPServer

mcp = MCPServer("Linux Service Status")

ALLOWED_SERVICES = {
    "nginx",
    "ssh",
    "docker",
}

@mcp.tool()
def service_status(service: str) -> dict:
    """Liefert den systemd-Status eines freigegebenen Dienstes."""
    if service not in ALLOWED_SERVICES:
        return {
            "service": service,
            "status": "denied",
            "message": "Dieser Dienst ist nicht freigegeben.",
        }

    result = subprocess.run(
        ["systemctl", "is-active", service],
        capture_output=True,
        text=True,
        timeout=5,
        check=False,
    )

    status = result.stdout.strip()
    if not status:
        status = result.stderr.strip()

    return {
        "service": service,
        "status": status,
        "returncode": result.returncode,
    }

@mcp.resource("service-policy://allowed")
def allowed_services() -> str:
    """Liste der über MCP freigegebenen Dienste."""
    return "\n".join(sorted(ALLOWED_SERVICES))

@mcp.prompt()
def diagnose_service(service: str) -> str:
    """Erstellt einen sicheren Prompt zur Dienstdiagnose."""
    return (
        f"Analysiere den Status des Linux-Dienstes '{service}'. "
        "Nutze ausschließlich lesende Prüfungen. "
        "Führe keine Änderungen, Neustarts oder "
        "Konfigurationsänderungen ohne ausdrückliche Freigabe durch."
    )

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

Das ist bereits ein vollständiger kleiner MCP Server.

MCP Server mit dem Inspector testen

Bevor ein MCP Server mit einer echten KI verbunden wird, sollte er isoliert getestet werden. Das offizielle Python SDK bringt dafür Unterstützung für den MCP Inspector mit.

Unser Beispiel lässt sich mit uv run mcp dev server.py starten. Der Inspector zeigt unter anderem die verfügbaren Tools, Resources, Resource Templates und Prompts. Unser Tool kann damit gezielt aufgerufen werden, beispielsweise service_status mit dem Parameter service = nginx.

Die offizielle Python-Dokumentation empfiehlt diesen Weg ausdrücklich für die Entwicklung und beschreibt den Inspector als Werkzeug zum Testen der vom Server veröffentlichten Primitives.

MCP Server über STDIO starten

Mit mcp.run() im if __name__ == "__main__":-Block verwendet das aktuelle Python SDK standardmäßig STDIO. Das eignet sich besonders für lokale Clients.

Eine Besonderheit solltest du dabei beachten: STDOUT gehört bei einem STDIO-MCP-Server zum Protokoll. Unkontrollierte print()-Ausgaben können deshalb problematisch werden. Für eigene Diagnosemeldungen sollte stattdessen ordentliches Logging verwendet werden.

Die offizielle SDK-Dokumentation weist ebenfalls darauf hin, dass beim STDIO-Transport stdin und stdout den eigentlichen Kommunikationskanal darstellen.

Aus dem lokalen Server einen Remote MCP Server machen

Unser Server kann auch über HTTP angeboten werden. Dafür ändern wir lediglich den Start:

if __name__ == "__main__":
    mcp.run(
        transport="streamable-http",
        stateless_http=True,
        json_response=True,
    )

Jetzt verwendet unser Server Streamable HTTP. Die aktuelle Dokumentation empfiehlt für skalierbare Remote-Deployments die Kombination aus Streamable HTTP, stateless HTTP und JSON-Antworten.

Damit sieht die Architektur beispielsweise so aus:

MCP Client
↓ HTTPS
Reverse Proxy
├── TLS
├── Authentifizierung
├── Rate Limiting
└── Logging
↓
MCP Server
↓
Linux-System

Für ein produktives System reicht es allerdings nicht, einfach nur einen Port ins Internet freizugeben.

Warum die MCP-Spezifikation 2026 für Remote-Server interessant ist

Die MCP-Spezifikation vom 28. Juli 2026 hat die Remote-Architektur deutlich verändert. Der Protokollkern ist für moderne Verbindungen zustandsloser geworden. Eine Anfrage soll damit nicht zwingend von derselben Serverinstanz bearbeitet werden müssen wie eine vorherige Anfrage.

Das erleichtert beispielsweise horizontale Skalierung, Loadbalancing, Reverse-Proxys, API-Gateways, Cloud-Deployments und mehrere MCP-Instanzen. Bei modernen HTTP-Anfragen können Gateways zudem MCP-spezifische Informationen über Header für Routing und Autorisierung verwenden.

Für kleine lokale MCP Server musst du dich mit diesen Details zunächst kaum beschäftigen. Sobald MCP allerdings Bestandteil einer Unternehmensinfrastruktur wird, werden sie wichtig.

Sicherheitsregeln für einen eigenen MCP Server

Ein funktionierender MCP Server ist schnell gebaut. Ein sicherer MCP Server benötigt mehr Überlegung. Eine ausführliche Vertiefung dieses Themas findest du in MCP Server sicher betreiben: Rechte, Tools und Risiken erklärt (Zum Artikel).

1. Keine universelle Shell bereitstellen

Vermeide Tools wie execute_command(command) oder run_shell(command). Solche Tools sind extrem mächtig. Besser sind eng definierte Funktionen wie get_service_status(service), get_disk_usage(), check_backup_status() oder get_certificate_expiry().

2. Eingaben validieren

Jeder Parameter sollte geprüft werden. Bei unserem Beispiel übernimmt das die Allowlist: if service not in ALLOWED_SERVICES: .... Dasselbe Prinzip gilt für Dateipfade, Datenbanktabellen, APIs, Benutzer, Hostnamen, Container, virtuelle Maschinen und Git-Repositories.

3. MCP Server nicht als Root betreiben

Unser Beispiel benötigt für systemctl is-active normalerweise keine Root-Rechte. Warum sollte der MCP-Prozess also Root bekommen? Grundregel: Der MCP Server sollte nur die Rechte besitzen, die seine definierten Tools tatsächlich benötigen.

4. Lese- und Schreibzugriffe trennen

Ein Tool wie service_status liest lediglich Informationen. Ein anderes Tool wie restart_service verändert dagegen den Systemzustand. Diese Funktionen sollten nicht gedankenlos in dieselbe Berechtigungsstufe gesteckt werden. Eine bessere Architektur könnte beispielsweise so aussehen:

READ ONLY
├── get_status
├── get_logs
├── get_disk_usage
└── get_backup_status

PRIVILEGED
├── restart_service
├── deploy_update
└── change_configuration

Schreibende Funktionen können zusätzlich eine explizite Freigabe verlangen.

5. Remote MCP Server authentifizieren

Ein öffentlich erreichbarer MCP Endpoint darf nicht einfach jedem Client administrative Tools bereitstellen. Je nach Architektur kommen beispielsweise OAuth, OIDC, Access Tokens, Scopes, ein Identity Provider oder eine zentrale Unternehmensauthentifizierung infrage.

MCP verwendet für geschützte Remote-Ressourcen eine auf OAuth basierende Autorisierungsarchitektur. Die Spezifikation 2026 hat diese Mechanismen weiter gehärtet, unter anderem bei Issuer-Validierung und Credential-Bindung.

6. Logs und Audit-Trails einplanen

Bei administrativen MCP Servern sollte nachvollziehbar sein, wann welches Tool mit welchen Parametern von welchem Benutzer aufgerufen wurde, welches Ergebnis es hatte und ob eine Aktion verweigert wurde. Gerade bei MCP im Unternehmensumfeld ist diese Nachvollziehbarkeit wichtig.

Ein MCP Server ist eine Sicherheitsgrenze

Genau dieser Punkt wird bei vielen MCP-Tutorials unterschätzt. Ein MCP Server ist nicht einfach ein Adapter. Er definiert eine Berechtigungsgrenze zwischen einer KI und deiner Infrastruktur.

Die eigentliche Frage lautet deshalb nicht: „Was könnte ich der KI alles ermöglichen?“ Sondern: „Was muss die KI für diese konkrete Aufgabe tatsächlich können?“

Aus „Die KI soll Linux administrieren“ sollte deshalb nicht automatisch „Die KI bekommt SSH und Root“ werden. Besser ist: „Die KI soll den Status wichtiger Dienste erkennen.“ Daraus entsteht service_status().

Soll sie zusätzlich Logmeldungen analysieren? Dann könnte ein weiteres Tool entstehen: get_service_logs(service, lines=50). Dabei wird erneut begrenzt: welche Dienste, wie viele Logzeilen, welcher Zeitraum – keine freien journalctl-Parameter, keine Shell, keine Schreibrechte.

Genau auf diese Weise wächst ein guter MCP Server kontrolliert.

So könnte ein größerer Admin-MCP-Server aussehen

Aus unserem kleinen Beispiel könnte später folgende Architektur entstehen:

MCP CLIENT
↓
MCP SERVER
├── Monitoring
│   ├── get_status
│   ├── get_load
│   └── get_alerts
├── Linux
│   ├── service_status
│   ├── get_logs
│   └── disk_usage
└── Backup
    ├── check_backup
    ├── last_backup
    └── backup_errors

Jede Funktion erfüllt einen klar abgegrenzten Zweck. Damit bleibt auch für Administratoren nachvollziehbar, welche Rechte der KI tatsächlich zur Verfügung stehen.

Typische Fehler beim Erstellen eines MCP Servers

Zu viele Funktionen in einem Tool

Ein Tool sollte möglichst eine klar definierte Aufgabe besitzen. Schlecht: manage_server(). Besser: get_service_status(), get_disk_usage(), get_service_logs().

Beliebige Shell-Kommandos zulassen

Das ist einer der gefährlichsten Designfehler. Statt einer freien Kommandozeile sollten kontrollierte Funktionen angeboten werden. Coding-Agenten wie OpenAI Codex stehen vor einer sehr ähnlichen Herausforderung, weil sie für ihre Arbeit Shell- und Dateisystemzugriff benötigen – mehr dazu in Codex sicher verwenden: Git, Sandbox, Backups und Freigaben richtig einrichten (Zum Artikel).

Secrets direkt im Code speichern

Passwörter, API-Keys und Tokens gehören nicht in server.py. Verwende stattdessen beispielsweise Environment Variables, Secret Stores, Vault-Systeme, Container Secrets oder Kubernetes Secrets.

Remote MCP ohne Authentifizierung betreiben

Ein Netzwerkport alleine ist keine Sicherheitsarchitektur. Besonders bei Tools mit Zugriff auf interne Systeme ist eine saubere Identitäts- und Berechtigungsprüfung notwendig.

Tool-Ergebnisse ungefiltert zurückgeben

Auch Rückgabedaten können sensibel sein, beispielsweise Passwörter, Tokens, interne IP-Adressen, personenbezogene Daten, vollständige Logdateien, Konfigurationsdateien oder Datenbankinhalte. Der MCP Server sollte deshalb nicht nur kontrollieren, was hineingeht, sondern auch, was herausgegeben wird.

MCP Server mit Python: Warum das SDK viel Arbeit abnimmt

Das Interessante an unserem Beispiel ist, was wir nicht programmieren mussten. Wir haben keine eigene Implementierung geschrieben für tools/list, resources/read, prompts/get, Protokoll-Negotiation, Schema-Erzeugung oder MCP-Nachrichten. Das übernimmt das SDK.

Aus @mcp.tool() def service_status(service: str) -> dict: kann das SDK unter anderem die Beschreibung und das benötigte Eingabeschema ableiten. Genau darin liegt einer der größten Vorteile eines offiziellen MCP SDKs.

Welche Programmiersprachen unterstützt MCP?

Du musst einen MCP Server nicht zwingend in Python schreiben. Für MCP stehen offizielle SDKs für mehrere Sprachen zur Verfügung. Aktuell gehören unter anderem dazu: TypeScript, Python, C#, Go, Rust und Java.

Python, TypeScript, C#, Go und seit August 2026 auch Rust werden in der aktuellen offiziellen SDK-Übersicht als Tier-1-SDKs geführt. Welche Sprache sinnvoll ist, hängt deshalb vor allem von deiner vorhandenen Infrastruktur ab. Für Linux-Administration und schnelle interne Werkzeuge ist Python allerdings besonders angenehm.

Wann lohnt sich ein eigener MCP Server?

Ein eigener MCP Server lohnt sich vor allem dann, wenn deine KI regelmäßig auf eigene Systeme zugreifen soll. Beispiele:

Systemadministration: Serverstatus prüfen, Logs abrufen, Backups kontrollieren, Zertifikate prüfen.

Monitoring: Alerts abrufen, Messwerte lesen, Systemzustände erklären.

DevOps: Deploymentstatus, CI/CD-Pipelines, Containerstatus, Kubernetes-Informationen, Git-Repositories.

Unternehmen: interne Wissensdatenbanken, CRM, Ticketsystem, Dokumentenmanagement, eigene REST-APIs.

Entwicklung: Build-Systeme, Testumgebungen, Repositories, Issue Tracker, Dokumentation.

Der Vorteil besteht darin, dass die eigentliche Integration auf der MCP-Seite standardisiert wird.

Checkliste: Eigenen MCP Server erstellen

Bevor dein Server produktiv eingesetzt wird, solltest du mindestens folgende Punkte prüfen:

• Aufgabe des MCP Servers eindeutig definiert
• Tools möglichst klein und eindeutig
• Inputs validiert
• Allowlist statt universeller Eingaben
• keine freie Shell
• kein unnötiger Root-Zugriff
• Lese- und Schreibfunktionen getrennt
• Secrets außerhalb des Sourcecodes
• sensible Ausgaben gefiltert
• Fehlerbehandlung vorhanden
• Timeouts gesetzt
• Logging eingerichtet
• Auditierung bedacht
• MCP Inspector verwendet
• Remote-Zugriffe authentifiziert
• HTTPS für Remote MCP
• Tools einzeln getestet
• Berechtigungen dokumentiert

FAQ: Eigenen MCP Server erstellen

Was brauche ich, um einen MCP Server selbst zu erstellen?

Für einen einfachen Python-MCP-Server reichen Python 3.10 oder neuer, das offizielle MCP SDK und wenige Zeilen Code. Für produktive Remote-Server kommen zusätzlich Themen wie Authentifizierung, TLS, Logging und Berechtigungsmanagement hinzu.

Ist ein MCP Server eine KI?

Nein. Ein MCP Server stellt Daten und Funktionen über das Model Context Protocol bereit. Das eigentliche KI-Modell befindet sich normalerweise in einer anderen Anwendung.

Welche Sprache eignet sich für einen MCP Server?

Python und TypeScript sind besonders verbreitet. Es existieren aber auch offizielle SDKs für weitere Programmiersprachen wie C#, Go, Rust und Java.

Was ist der Unterschied zwischen MCP Tool und Resource?

Ein Tool führt eine Funktion aus. Eine Resource stellt Informationen beziehungsweise Inhalte bereit. Ein Prompt liefert dagegen eine vorbereitete Prompt-Struktur für einen bestimmten Anwendungsfall.

Kann ein MCP Server Shell-Befehle ausführen?

Technisch ist das möglich. Eine universelle Shell über MCP ist jedoch ein erhebliches Sicherheitsrisiko. Besser sind eng begrenzte Tools mit fest definierten Aktionen und validierten Parametern.

Kann ich einen MCP Server über das Internet betreiben?

Ja. Für Remote MCP Server steht Streamable HTTP zur Verfügung. Ein produktiver Remote-Server sollte jedoch mit HTTPS, Authentifizierung, Autorisierung, Logging und möglichst restriktiven Berechtigungen betrieben werden.

Braucht ein MCP Server Root-Rechte?

Normalerweise nicht. Ein MCP Server sollte immer mit den geringstmöglichen benötigten Rechten betrieben werden.

Wie teste ich einen MCP Server?

Das offizielle MCP SDK stellt Entwicklungswerkzeuge bereit. Ein Python-Server kann beispielsweise mit dem MCP Inspector getestet werden, bevor er mit einem produktiven KI-Client verbunden wird.

Fazit: Einen eigenen MCP Server zu bauen ist einfacher als gedacht

Einen MCP Server selbst zu erstellen ist technisch überraschend einfach. Mit Python und dem offiziellen MCP SDK reichen bereits wenige Funktionen, um eigene Tools, Resources und Prompts bereitzustellen.

Die eigentliche Herausforderung beginnt nicht beim Code. Sie beginnt bei der Frage: Welche Fähigkeiten soll eine KI tatsächlich bekommen?

Unser Praxisbeispiel hätte ohne Weiteres eine komplette Shell bereitstellen können. Stattdessen haben wir genau eine klar definierte Fähigkeit implementiert: Status freigegebener Linux-Dienste prüfen.

Diese Denkweise ist entscheidend für produktive MCP-Systeme. Ein guter MCP Server ist deshalb nicht der Server mit den meisten Tools und den weitreichendsten Rechten. Ein guter MCP Server stellt genau die Funktionen bereit, die für einen bestimmten Anwendungsfall benötigt werden – und keinen unnötigen Zugriff darüber hinaus.

Wer dieses Prinzip berücksichtigt, kann mit MCP sehr leistungsfähige Integrationen für Linux, DevOps, Monitoring, interne APIs, Unternehmensanwendungen und KI-Agenten entwickeln.

Quellen und weiterführende Dokumentation

Für die technischen Angaben dieses Artikels wurden insbesondere die aktuelle MCP-Spezifikation vom 28. Juli 2026, die offizielle SDK-Übersicht sowie die Dokumentation des offiziellen MCP Python SDK berücksichtigt. Das aktuelle SDK unterstützt unter anderem STDIO und Streamable HTTP, wobei für neue Remote-Implementierungen Streamable HTTP vorgesehen ist.

Stand der technischen Prüfung: 9. September 2026.

Weiterführende Themen und Quellen

MCP Server sicher betreiben: Rechte, Tools und Risiken erklärt (Zum Artikel)

MCP einfach erklärt: Was ist das Model Context Protocol? (Zum Artikel)

Codex sicher verwenden: Git, Sandbox, Backups und Freigaben richtig einrichten (Zum Artikel)

KI-Skills, Plugins, Apps und MCP: Was ist eigentlich der Unterschied? (Zum Artikel)