So erstellen Sie einen lokalen MCP-Server für Claude: Dateien, Befehle, Screenshots und App-Steuerung

Claude wird deutlich nützlicher, wenn es aufhört, nur eine Chat-Oberfläche zu sein.

Ein lokaler MCP-Server ermöglicht es Claude, mit Ihrem tatsächlichen Rechner zu interagieren: lokale Dateien, genehmigte Befehle, Screenshots und das Öffnen von Apps. Der wichtige Punkt ist nicht der rohe Zugriff. Es ist der kontrollierte Zugriff.

In dieser Anleitung bauen wir einen lokalen MCP-Server für Claude, der praktisch, eng gefasst und sicher genug für den Einsatz in echten Arbeitsabläufen ist.

Ein kurzer Hinweis, bevor wir etwas bauen

Dieser Artikel vermeidet bewusst die unverantwortliche Version der „Computersteuerung".

Wir werden Claude nicht uneingeschränkten Shell-Zugriff, vollständige Dateisystem-Berechtigungen oder die Erlaubnis geben, Ihren Rechner ohne Schutzmaßnahmen zu verändern. Der schnellste Weg, einen schlechten lokalen MCP-Server zu bauen, ist, ein riesiges run_anything()-Werkzeug freizuschalten und es Innovation zu nennen.

Das bessere Muster ist:

• zugelassene Verzeichnisse
• zugelassene Befehle
• sichere Standardeinstellungen
• für Menschen lesbare Protokolle
• explizite Antworten
• klare Trennung zwischen schreibgeschützten und aktionsausführenden Werkzeugen

Wenn Claude alles tun kann, haben Sie eine Demo gebaut.

Wenn Claude die richtigen Dinge sicher tun kann, haben Sie etwas Nutzbares gebaut.

Warum es sich lohnt, diese Architektur zu lernen

Der Wert eines lokalen MCP-Servers liegt nicht in der Neuheit. Es ist die Reduzierung von Reibung.

Ohne eine lokale Werkzeugschicht sieht Ihr Arbeitsablauf so aus:

1. Claude fragen, was zu tun ist
2. Die Antwort kopieren
3. Den Ordner selbst öffnen
4. Den Befehl selbst ausführen
5. Den Screenshot selbst machen
6. Das Ergebnis zurück in den Chat einfügen

Mit einem lokalen MCP-Server wird dieser Kreislauf deutlich enger. Claude kann den benötigten Kontext prüfen, eng gefasste Werkzeuge verwenden und eine Antwort zurückgeben, die auf dem tatsächlichen Zustand Ihres Rechners basiert.

Das ist nützlich für:

• Entwicklungs-Workflows
• Protokoll-Inspektion
• Content-Operationen
• Recherche-Pipelines
• Desktop-Automatisierung
• wiederkehrende Verwaltungsaufgaben

Und weil die Werkzeugschicht Ihnen gehört, bestimmen Sie genau, wo das Modell aufhört.

Möchten Sie KI lernen und in Ihrer Karriere vorankommen?

Ich teile:

Über 1.000 KI-Prompts

KI-Tools & Automatisierungen

Karriere- und LinkedIn-Wachstumstipps

Kuratierte Tech- & Produktivitätsressourcen

Hier abonnieren:

https://bytebuilders.beehiiv.com/subscribe

Folgen Sie mir für weitere KI-Tipps

👇

Das Design, das wir bauen

Wir werden einen lokalen Server mit fünf Werkzeugen bauen:

1. list_files — sehen, was in genehmigten Ordnern existiert
2. read_file — sichere textbasierte Dateien öffnen
3. run_command — einen kleinen Satz genehmigter lokaler Befehle ausführen
4. take_screenshot — einen Screenshot an einem bekannten Ort speichern
5. open_target — eine App, Datei, einen Ordner oder eine URL öffnen

Dieser Umfang ist bewusst gewählt.

Er reicht aus, um Claude auf einem lokalen Rechner sinnvoll nutzbar zu machen, ohne in unsichere, allgemeine Automatisierung abzugleiten.

Das mentale Modell sollte so aussehen:

Claude → MCP-Client → lokaler MCP-Server → enge Werkzeuge → Betriebssystem

Claude sollte niemals direkt mit Ihrem Betriebssystem sprechen. Ihr MCP-Server ist die Steuerungsebene dazwischen.

Der Technologie-Stack

Für einen lokalen Bau ist Python eine saubere Wahl, da das offizielle MCP-SDK ausgereift ist, die FastMCP-Abstraktion präzise ist und Python nach wie vor die einfachste Sprache für Dateisystem-, Subprozess- und Desktop-Scripting-Arbeiten ist 4 2.

Wir verwenden:

• Python 3.11+
• mcp[cli] für die MCP-Server-Laufzeit
• mss für plattformübergreifende Screenshots
• Standardbibliotheksmodule für Dateizugriff, Subprozess-Aufrufe und Betriebssystem-Handling

Richten Sie ein neues Projekt ein:

1mkdir local-mcp-server
2cd local-mcp-server
3uv init --python 3.11
4uv add "mcp[cli]>=1.0,<2.0" "mss>=9.0,<10.0"

Der dekoratorbasierte FastMCP-Stil hält die Protokollebene aus dem Weg, sodass Sie sich auf die Werkzeugqualität konzentrieren können, anstatt auf die Verkabelung 4 5.

Ein einfaches Projekt-Layout funktioniert gut:

1mkdir local-mcp-server
2cd local-mcp-server
3uv init --python 3.11
4uv add "mcp[cli]>=1.0,<2.0" "mss>=9.0,<10.0"

Sie brauchen keine komplexe Architektur für v1. Was Sie brauchen, ist Klarheit.

Der eigentliche Server

Erstellen Sie server.py und beginnen Sie mit einer richtliniengesteuerten Implementierung.

1from __future__ import annotations
2
3import json
4import os
5import platform
6import shlex
7import subprocess
8from pathlib import Path
9from typing import Any
10
11import mss
12from mcp.server.fastmcp import FastMCP
13
14app = FastMCP("local-computer-control", json_response=True)
15
16HOME = Path.home()
17PROJECT_ROOT = Path(__file__).parent.resolve()
18CAPTURE_DIR = PROJECT_ROOT / "captures"
19CAPTURE_DIR.mkdir(exist_ok=True)
20
21ALLOWED_ROOTS = [
22    HOME / "Documents",
23    HOME / "Desktop",
24    PROJECT_ROOT,
25]
26
27ALLOWED_COMMANDS = {
28    "pwd",
29    "ls",
30    "git status",
31    "git diff --stat",
32    "python --version",
33    "node --version",
34    "npm --version",
35}
36
37READABLE_EXTENSIONS = {
38    ".txt",
39    ".md",
40    ".json",
41    ".py",
42    ".js",
43    ".ts",
44    ".tsx",
45    ".jsx",
46    ".yaml",
47    ".yml",
48    ".toml",
49    ".csv",
50    ".log",
51}
52
53def _resolve_path(raw_path: str) -> Path:
54    path = Path(raw_path).expanduser().resolve()
55    for root in ALLOWED_ROOTS:
56        root = root.resolve()
57        if path == root or root in path.parents:
58            return path
59    raise ValueError(f"Path not allowed: {path}")
60
61def _ensure_safe_command(command: str) -> str:
62    normalized = " ".join(shlex.split(command))
63    if normalized not in ALLOWED_COMMANDS:
64        raise ValueError(
65            "Command not allowed. Add it explicitly to ALLOWED_COMMANDS if you really need it."
66        )
67    return normalized
68
69@app.tool()
70def list_files(path: str = "~") -> dict[str, Any]:
71    """List files and folders inside an approved directory."""
72    target = _resolve_path(path)
73    if not target.is_dir():
74        raise ValueError(f"Not a directory: {target}")
75
76    items = []
77    for child in sorted(target.iterdir(), key=lambda p: (not p.is_dir(), p.name.lower())):
78        items.append(
79            {
80                "name": child.name,
81                "path": str(child),
82                "type": "directory" if child.is_dir() else "file",
83            }
84        )
85
86    return {
87        "path": str(target),
88        "count": len(items),
89        "items": items,
90    }
91
92@app.tool()
93def read_file(path: str, max_chars: int = 12000) -> dict[str, Any]:
94    """Read a safe text file from an approved location."""
95    target = _resolve_path(path)
96    if not target.is_file():
97        raise ValueError(f"Not a file: {target}")
98    if target.suffix.lower() not in READABLE_EXTENSIONS:
99        raise ValueError(f"Unsupported file type: {target.suffix}")
100
101    content = target.read_text(encoding="utf-8", errors="replace")
102    truncated = len(content) > max_chars
103    content = content[:max_chars]
104
105    return {
106        "path": str(target),
107        "truncated": truncated,
108        "content": content,
109    }
110
111@app.tool()
112def run_command(command: str, cwd: str | None = None, timeout: int = 15) -> dict[str, Any]:
113    """Run one allowlisted local command."""
114    safe_command = _ensure_safe_command(command)
115    working_dir = _resolve_path(cwd) if cwd else PROJECT_ROOT
116
117    completed = subprocess.run(
118        safe_command,
119        shell=True,
120        cwd=str(working_dir),
121        capture_output=True,
122        text=True,
123        timeout=timeout,
124    )
125
126    return {
127        "command": safe_command,
128        "cwd": str(working_dir),
129        "returncode": completed.returncode,
130        "stdout": completed.stdout.strip(),
131        "stderr": completed.stderr.strip(),
132    }
133
134@app.tool()
135def take_screenshot(name: str = "latest") -> dict[str, Any]:
136    """Capture a screenshot and save it locally."""
137    output_path = CAPTURE_DIR / f"{name}.png"
138
139    with mss.mss() as sct:
140        sct.shot(output=str(output_path))
141
142    return {
143        "saved": True,
144        "path": str(output_path),
145    }
146
147@app.tool()
148def open_target(target: str) -> dict[str, Any]:
149    """Open an approved file, folder, app, or URL using the local OS."""
150    system = platform.system().lower()
151
152    if target.startswith("http://") or target.startswith("https://"):
153        resolved = target
154    else:
155        resolved = str(_resolve_path(target))
156
157    if system == "darwin":
158        subprocess.run(["open", resolved], check=True)
159    elif system == "windows":
160        os.startfile(resolved)  # type: ignore[attr-defined]
161    else:
162        subprocess.run(["xdg-open", resolved], check=True)
163
164    return {
165        "opened": True,
166        "target": resolved,
167    }
168
169if __name__ == "__main__":
170    app.run(transport="stdio")

Dies ist ein kompakter Server, aber der wichtige Punkt ist nicht seine Länge. Der wichtige Punkt ist die Form der Schnittstelle:

• jedes Werkzeug hat eine sehr klare Aufgabe
• jedes Werkzeug gibt strukturierte Daten zurück
• die Befehlsausführung ist abgeschottet
• der Dateizugriff ist verwurzelt
• Screenshots gehen in einen bekannten Ordner

Das ist genau das, was Sie in einem lokalen MCP-Server wollen.

Warum diese Werkzeuge so konzipiert sind

Hochwertige Inhalte über Agenten-Tooling sollten niemals bei „hier ist Code" stehen bleiben. Die Form des Werkzeugs ist die eigentliche Lektion.

list_files

Dieses Werkzeug gibt Claude eine sichere Erkundungsoberfläche. Es sollte in der Lage sein, Fragen zu beantworten wie:

• Was ist in diesem Projektordner?
• Welche Notizen existieren in Documents?
• Gibt es bereits eine Protokolldatei, die ich einsehen kann?

Aber es sollte kein rekursiver Platten-Crawler werden.

read_file

Dies ist oft das nützlichste lokale Werkzeug überhaupt. Ein großer Prozentsatz der echten Arbeit steckt immer noch in lokalen Markdown-Notizen, Protokollen, CSVs, Dokumenten und Projektdateien.

Die max_chars-Begrenzung ist wichtig. Große Dateien sind ein Kontext- und Latenzproblem. Den gesamten Inhalt einer riesigen Protokolldatei zurückzugeben, ist selten nützlich.

run_command

Hier werden die meisten Leute schlampig.

Das sichere Muster ist nicht „Shell-Zugriff erlauben und dann das Beste hoffen". Das sichere Muster ist „einen winzigen Satz exakter, überprüfbarer Befehle erlauben". Deshalb verwendet das Beispiel eine strenge Positivliste.

take_screenshot

Ein Screenshot-Werkzeug ist wertvoll, weil es Claude ermöglicht, an Desktop-Workflows teilzunehmen. Selbst wenn Ihre erste Version das Bild nur auf die Festplatte speichert, ist das bereits nützlich für Berichte, UI-Debugging, Dokumentationserfassung und strukturierte Übergaben.

open_target

App-Steuerung muss nicht mit GUI-Automatisierung beginnen. Für viele Arbeitsabläufe reicht es, „den richtigen Ordner, die richtige Datei oder URL zu öffnen".

Das ist eine haltbarere v1, als so zu tun, als bräuchte man am ersten Tag eine vollständige Cursor-Automatisierung.

Den Server mit Claude verbinden

Lokale MCP-Server werden üblicherweise über stdio betrieben, was bedeutet, dass Claude den Prozess lokal startet und direkt über stdin/stdout mit ihm kommuniziert. Für einen lokalen Computersteuerungs-Server ist das die richtige Voreinstellung, da es unnötige Netzwerkexposition vermeidet 4 5.

Claude Desktop unterstützt lokale MCP-Server über die Konfiguration, wo es den Serverprozess für Sie startet. In der Praxis ist die Verwendung absoluter Pfade für den Interpreter und das Skript das am wenigsten fragile Setup, da lokale GUI-App-Umgebungen oft strenger sind als Ihr Terminal 2.

Eine minimale Konfiguration sieht so aus:

1{
2  "mcpServers": {
3    "local-computer-control": {
4      "command": "/absolute/path/to/python",
5      "args": [
6        "/absolute/path/to/local-mcp-server/server.py"
7      ]
8    }
9  }
10}

Wenn Sie uv bevorzugen, ist das auch in Ordnung:

1{
2  "mcpServers": {
3    "local-computer-control": {
4      "command": "/absolute/path/to/uv",
5      "args": [
6        "--directory",
7        "/absolute/path/to/local-mcp-server",
8        "run",
9        "python",
10        "server.py"
11      ]
12    }
13  }
14}

Nachdem Sie die Konfiguration gespeichert und Claude neu gestartet haben, sollten die Server-Werkzeuge in der Liste der lokalen MCP-Werkzeuge erscheinen. Das lokale MCP-Setup von Claude Desktop ist genau um dieses Modell herum aufgebaut: einen lokalen Prozess starten, über stdio verbinden und die Werkzeuge dem Modell zur Verfügung stellen 2 3.

Prompts, die tatsächlich zum Testen nützlich sind

Sobald der Server verbunden ist, beginnen Sie nicht mit komplizierter Orchestrierung. Beginnen Sie mit direkten, langweiligen Überprüfungen.

Versuchen Sie Prompts wie:

• „Liste die Dateien in meinem Desktop-Ordner auf."
• „Lies ~/Documents/todo.md und fasse die drei wichtigsten Prioritäten zusammen."
• „Führe git status in meinem lokalen Projektordner aus und erkläre, was sich geändert hat."
• „Mache einen Screenshot namens workspace-check."
• „Öffne meine Projekt-README."

Wenn diese einfachen Abläufe konsistent funktionieren, haben Sie einen Server, den es wert ist, erweitert zu werden.

Wenn nicht, werden weitere Werkzeuge nur die eigentlichen Probleme verbergen.

Wo lokale MCP-Server wirklich wertvoll werden

Der offensichtliche Anwendungsfall ist die Entwicklung, aber das ist nur eine Spur.

Entwickler-Workflow

Claude kann:

• ein Repo-Verzeichnis inspizieren
• eine Konfigurationsdatei lesen
• git status ausführen
• einen Screenshot eines Fehlerzustands machen
• das Projektverzeichnis öffnen

Das eliminiert bereits eine Menge Kontextwechsel.

Recherche-Workflow

Claude kann:

• Forschungsordner auflisten
• Markdown-Notizen öffnen und zusammenfassen
• strukturierte CSVs lesen
• Screenshots von Tools oder Dashboards speichern
• Quelldateien oder Browser-Links öffnen

Content-Workflow

Claude kann:

• einen Entwurfsordner scannen
• vorhandene Beitragsideen lesen
• einen Screenshot einer Design-Referenz machen
• die richtige Schreibdatei oder URL öffnen
• einen begrenzten Befehl ausführen, der ein Build-Artefakt oder einen Entwurfsexport erzeugt

Ops-Workflow

Claude kann:

• Protokolle aus genehmigten Verzeichnissen einsehen
• einen schreibgeschützten Diagnosebefehl ausführen
• den relevanten Ordner oder Dashboard-Link öffnen
• einen Beweis-Screenshot speichern

Das ist der eigentliche Punkt der Architektur: nicht „Computersteuerung" als Gag, sondern Workflow-Kompression.

Die Sicherheitsschicht ist das Produkt

Dies ist der Abschnitt, den zu viele technische Artikel verharmlosen.

Der gefährliche Teil von lokalem MCP ist nicht das Protokoll. Es ist ein schlechtes Berechtigungsdesign.

Wenn Sie möchten, dass dieser Server über eine Demo hinaus nutzbar ist, bauen Sie das Sicherheitsmodell frühzeitig auf.

Verwenden Sie Verzeichnis-Positivlisten

Claude sollte nur Pfade sehen können, die Sie explizit genehmigt haben. Deshalb ist _resolve_path() der Kern der Dateiwerkzeuge.

Verwenden Sie Befehls-Positivlisten

Setzen Sie in einer ersten Version niemals eine beliebige Shell-Ausführung frei. Beginnen Sie mit exakten Befehlen, die Sie Zeile für Zeile prüfen können.

Trennen Sie Lese-Werkzeuge von Aktions-Werkzeugen

Schreibgeschützte Werkzeuge sollten die Voreinstellung sein. Aktions-Werkzeuge sollten bewusst eingeführt werden.

Protokollieren Sie alles

Selbst ein einfaches, nur-anhängendes JSON-Protokoll verbessert Debugging und Vertrauen dramatisch.

Fügen Sie eine Bestätigungsebene für Schreibvorgänge hinzu

Wenn Sie später write_file, move_file oder delete_file hinzufügen, stellen Sie sicher, dass diese Werkzeuge entweder ein zweites Bestätigungstoken erfordern oder standardmäßig deaktiviert bleiben.

Ziehen Sie einen Trockenlauf-Modus in Betracht

Für aktionsausführende Werkzeuge wird der Trockenlauf-Modus unterschätzt. Er ermöglicht es Claude zu erklären, was es tun würde, bevor es es tut.

Führen Sie nach Möglichkeit unter einem eingeschränkten Benutzer aus

Wenn Sie es mit lokaler Automatisierung ernst meinen, geben Sie Ihrem MCP-Server nicht mehr Betriebssystem-Berechtigungen als nötig.

Eine nützliche Faustregel:

• Stufe 1: schreibgeschützte Werkzeuge
• Stufe 2: risikoarme Aktionen wie Datei öffnen / App öffnen
• Stufe 3: bestätigte Schreibaktionen
• Stufe 4: destruktive Aktionen, die Sie wahrscheinlich nicht beiläufig freigeben sollten

Die meisten Menschen brauchen nie Stufe 4.

Was nach v1 verbessert werden sollte

Eine solide erste Version verdient das Recht, leistungsfähiger zu werden.

Sobald der grundlegende Server stabil ist, sind die nächsten sinnvollen Upgrades:

1. Zentrale Richtliniendatei

Verschieben Sie Ihre Regeln in config/policy.json, damit Änderungen deklarativ sind.

Beispiel:

1{
2  "allowed_roots": [
3    "~/Documents",
4    "~/Desktop",
5    "./"
6  ],
7  "allowed_commands": [
8    "pwd",
9    "ls",
10    "git status",
11    "git diff --stat",
12    "python --version"
13  ]
14}

1. Strukturierte Protokollierung

Protokollieren Sie Werkzeugaufrufe, Zeitstempel, Argumente und Ergebnisse in logs/server.log oder einer JSONL-Datei.

1. Sicherere Befehlsausführung

Teilen Sie anstelle eines einzigen generischen Befehlswerkzeugs die Befehle in engere Werkzeuge auf, wie zum Beispiel:

• git_status
• show_current_directory
• list_project_files

Das macht die Werkzeugauswahl für Claude einfacher und die Sicherheit für Sie einfacher.

1. Bessere Screenshot-Verarbeitung

Sie können von „Screenshot auf Festplatte speichern" weiterentwickeln zu:

• zeitgestempelten Aufnahmen
• Aufnahme des aktiven Fensters
• Bereichsaufnahme
• Dateiaufbewahrungsregeln

1. Betriebssystemspezifische Automatisierungsadapter

Auf macOS können Sie später AppleScript oder Shortcuts hinzufügen. Unter Windows PowerShell oder UI-Automation. Unter Linux desktopspezifische Starter und Fensterwerkzeuge.

Aber das sollte kommen, nachdem der langweilige lokale Kern zuverlässig ist.

Häufige Fehler, die Menschen bei lokalen MCP-Servern machen

Die Fehler sind vorhersehbar.

Fehler 1: Zu viel Macht, zu früh

Die Leute lieben die Idee der totalen Computersteuerung. Sie hassen es, sie zu debuggen. Fangen Sie kleiner an.

Fehler 2: Vage Werkzeugnamen

Wenn Ihre Werkzeugnamen mehrdeutig sind, wird Claude sie schlecht verwenden. Seien Sie explizit.

Schlecht:

• system_action
• computer_control

Besser:

• list_files
• read_file
• run_command
• take_screenshot
• open_target

Fehler 3: Unstrukturierte Ausgaben

Ein Batzen gemischten Textes ist für Claude schwieriger zu verarbeiten als ein sauberes JSON-Objekt.

Fehler 4: Keine Protokollierung

Wenn ein Werkzeug fehlschlägt und Sie nicht sehen können, warum, wird das System zum Ratespiel.

Fehler 5: Das Modell wie die Steuerungsebene behandeln

Claude ist die Argumentationsebene. Ihr Server muss immer noch die Durchsetzungsebene sein.

Diese Unterscheidung ist nicht verhandelbar.

Was diese Architektur besser kann als einfache Automatisierung

Traditionelle Desktop-Automatisierung ist normalerweise eines von zwei Dingen:

• sprödes GUI-Scripting
• isolierte Skripte, die erfordern, dass ein Mensch genau weiß, wann er sie ausführen muss

Ein lokaler MCP-Server ändert das, weil Claude basierend auf der Anfrage des Benutzers und dem verfügbaren Kontext entscheiden kann, welches Werkzeug verwendet werden soll.

Das bedeutet, dass Sie nicht nur einen Befehl automatisieren. Sie bauen eine lokale Fähigkeitsebene auf, über die das Modell nachdenken kann.

Deshalb fühlt sich MCP wichtig an. Es ist nicht nur ein weiteres Integrationsmuster. Es ist ein saubererer Weg, dem Modell die Werkzeugnutzung zugänglich zu machen, ohne jeden möglichen Arbeitsablauf in der Anwendungsebene fest zu codieren.

Die Grenzen, die Sie respektieren sollten

Selbst ein guter lokaler MCP-Server hat echte Einschränkungen.

• Desktop-Automatisierung kann betriebssystemübergreifend unzuverlässig sein.
• Screenshots sind nützlich, aber nicht magisch.
• App-Starts sind einfach; zuverlässige UI-Manipulation ist schwieriger.
• Generischer Shell-Zugriff ist gefährlich.
• Kontextaufblähung ist real, wenn die Werkzeugausgaben zu groß sind.
• Menschliche Zustimmung ist für alles Folgenreiche immer noch wertvoll.

Mit anderen Worten: Verwechseln Sie nicht „Modell kann Aktionen ausführen" mit „Modell sollte ohne Aufsicht handeln".

Das wertvollere Muster ist die kollaborative Steuerung, nicht die blinde Autonomie.