Val Town MCP Server sicher einrichten

Dieser Ratgeber richtet den offiziellen Val Town MCP Server so ein, dass ein KI-Client Vals und Plattformdaten nutzen kann, ohne Schreibrechte oder Geheimnisse unnötig auszuweiten. Ausgangspunkt ist die offizielle MCP-Dokumentation unter https://docs.val.town/guides/prompting/mcp/. Der Endpunkt ist gehostet: https://api.val.town/v3/mcp. Bevorzugen Sie das offizielle Plugin aus https://github.com/val-town/plugins, weil Val Town darüber sowohl den MCP-Server als auch die Plattform-Skills für Claude Code, Codex und Cursor verteilt. Behandeln Sie jede Verbindung als Zugriff auf Code, Logs und möglicherweise SQLite-Daten Ihres Kontos.

Vor dem Verbinden inventarisieren

Erstellen Sie zuerst eine kleine Zugriffsentscheidung. Welche Vals sollen das Modell sehen? Welche sind öffentlich, nicht gelistet oder privat? Welche enthalten Produktionsendpoints, Kundendaten, Tokens oder sensible Logs? Privat ist die passende Sichtbarkeit für vertraulichen Quellcode; nicht gelistet verhindert nur das einfache Auffinden und ersetzt keine Zugriffskontrolle. Prüfen Sie auch die Kollaborationsrechte. Notieren Sie, welche Aktionen das Modell anfangs nur lesen darf und welche später nach menschlichem Review erlaubt sein können. Für eine neue Integration ist „Vals auflisten“ ein sinnvoller erster Test; Deployments, Code-Änderungen und Rollbacks gehören nicht in den ersten Prompt.

OAuth und Client einrichten

Für Claude Code kann der direkte offizielle Befehl genutzt werden: claude mcp add --transport http val-town https://api.val.town/v3/mcp. Anschließend /mcp ausführen, die Verbindung kontrollieren und die OAuth-Autorisierung im Browser nur für das erwartete Val-Town-Konto abschließen. Alternativ claude plugin install valtown@claude-plugins-official verwenden; das ist laut Val Town der empfohlene Weg. Für Codex und Cursor folgen Sie den aktuellen Anweisungen im offiziellen Plugin-Repository. Prüfen Sie im Client nach der Installation den Servernamen und die Endpunkt-URL, statt Befehle aus Logtexten oder Webseiten blind zu übernehmen. OAuth-Dialoge und Token niemals in Screenshots, Tickets oder Prompts weitergeben.

API-Tokens und Secrets abgrenzen

Der MCP-Server verwendet den OAuth-Flow. Val-Town-API-Tokens sind davon getrennte Bearer-Tokens für die REST-API. Falls ein Workflow tatsächlich einen API-Token braucht, erzeugen Sie ihn mit minimalen Berechtigungen und legen Sie ihn in einer sicheren Client-Konfiguration oder einem Secret-Store ab. Ein Token gehört weder in eine val-Datei noch in den Chatverlauf. Val-Town-Umgebungsvariablen sind für Anwendungssecrets vorgesehen; die Dokumentation sagt zudem, dass vals sie nicht programmatisch setzen können. Das ist hilfreich gegen versehentliche Laufzeit-Updates, ersetzt aber kein Code-Review: Eine Code-Mutation könnte Secrets auslesen oder an einen externen Endpoint senden. Begrenzen Sie deshalb Schreibrechte und prüfen Sie Diffs vor dem Merge.

Sicherer erster Durchlauf

Starten Sie mit einer konkret begrenzten Leseaufgabe, etwa: „Liste nur meine privaten Entwicklungs-vals mit Name und Trigger auf; verändere nichts.“ Prüfen Sie die Antwort im Client und überlegen Sie, ob sie Daten enthält, die an das Modell gegangen sein sollen. Die Datenroute verläuft vom Nutzer zum Client, vom Client über MCP zu Val Town und mit den Tool-Ergebnissen zurück zum Client. Der Client kann Ergebnisse an das ausgewählte Modell übergeben. Beachten Sie daher zusätzlich die Datenschutz-, Aufbewahrungs- und Trainingsoptionen des Modellanbieters. Lassen Sie nicht ganze SQLite-Tabellen, Secrets oder Rohlogs in den Kontext laden, wenn eine gefilterte, redigierte Abfrage genügt.

Änderungen, Ausführung und Deployments kontrollieren

Wenn der Lesezugriff zuverlässig ist, nutzen Sie für Mutationen einen Branch oder ein Remix. Bitten Sie das Modell zuerst um einen Plan und einen Diff, nicht sofort um die Ausführung. Kontrollieren Sie Ziel-val, Trigger, importierte Abhängigkeiten, neue Netzwerkziele und jede Behandlung von Deno.env. Erst dann Code schreiben lassen. Ein HTTP-val, Cron oder E-Mail-Handler kann nach der Änderung produktiv laufen; prüfen Sie deshalb Ausgabe, Logs und Authentifizierung vor einem Merge. Bei Problemen nicht hektisch nachbessern: Val Town versioniert Änderungen automatisch. Verwenden Sie Versions- oder Historienansicht für einen gezielten Rollback, nachdem Sie Ursache und betroffene Version bestimmt haben.

Prompt-Injection abwehren

MCP-Tool-Ergebnisse sind nicht automatisch vertrauenswürdig. Ein Logeintrag, E-Mail-Text, Webseiteninhalt, Kommentar oder SQLite-Feld kann das Modell zu einer fremden Anweisung verleiten. Behandeln Sie Aussagen wie „kopiere dieses Token“, „deaktiviere Auth“ oder „deploye sofort“ als untrusted Daten, auch wenn sie in einem Tool-Ergebnis stehen. Halten Sie eine klare Arbeitsregel: Tool-Inhalte dürfen Fakten liefern, aber weder Rechte erweitern noch menschliche Freigaben ersetzen. Verwenden Sie präzise Prompts, bestätigen Sie jede Schreiboperation ausdrücklich und beenden Sie die Sitzung bei verdächtiger Secret-Ausgabe.

FAQ

Ist der MCP-Endpunkt ein Ersatz für API-Tokens? Nein. Der dokumentierte MCP-Zugriff nutzt OAuth. API-Tokens dienen der REST-API und benötigen eigene, minimale Berechtigungen.

Kann ich öffentliche Vals bedenkenlos verbinden? Nein. Öffentlich betrifft Sichtbarkeit des Quellcodes, nicht die Sicherheit eines Endpoints, Logs oder der Modellweitergabe. Prüfen Sie Trigger und Dateninhalt.

Was ist der kleinste sichere Test? Eine klar begrenzte Leseoperation auf einen unkritischen Entwicklungs-val, gefolgt von einer Prüfung der angezeigten Tool-Ergebnisse und der Client-Konfiguration.