buttplug-mcp ist ein Model-Context-Protocol-Server für das Buttplug.io-Ökosystem, der es toolfähigen LLM-Programmen wie Claude Desktop ermöglicht, verbundene Genital Interface Devices abzufragen und zu steuern- Zu den Funktionen gehören die Ressourcen
/devices, /device/{id}, /device/{id}/rssi, /device/{id}/battery sowie das Tool device_vibrate; die Vibrationsstärke wird im Bereich 0.0 bis 1.0 angegeben
- Der aktuelle Status ist experimentell und instabil; das Projekt wurde am 01.04.2025 als schnelles Lernprojekt gestartet, und wegen der instabilen Verbindungsbehandlung von
go-buttplug konnten End-to-End-Tests nicht ordentlich abgeschlossen werden
- Zur Nutzung muss Intiface Central gestartet werden, um den Port des WebSocket-Servers zu prüfen; anschließend werden in der Konfiguration eines MCP-Hosts wie Claude Desktop die ausführbare Datei
buttplug-mcp und Argumente wie --ws-port 12345 eingetragen
- Bei lokaler Inferenz auf Basis von Ollama wurden Tool-Aufrufe mit
mcphost ausprobiert, doch in dieser Umgebung werden nur Tools unterstützt, keine Resources, sodass Geräteauflistung und Detailabfragen nicht möglich sind
Projektziel und unterstützter Umfang
buttplug-mcp ist ein Model Context Protocol-Server, der es LLM-Programmen ermöglicht, mit dem Buttplug.io ecosystem verbundene Geräte abzufragen und zu steuern- Für toolfähige LLM-Programme wie Claude Desktop sind Prompts wie die folgenden als Ziel vorgesehen
- Verbundene Buttplug-Geräte abfragen
- Einen bestimmten Motor eines bestimmten Geräts auf 50 % Stärke setzen
- Den Akkustand des Lovense Max 2 prüfen
- Prüfen, ob das Signal des WeWibe schwach ist
- Das README weist ausdrücklich darauf hin, dass die oben beschriebene Erfahrung der Zielzustand ist und die aktuelle Erfahrung instabil und frustrierend ist
MCP-Ressourcen und Tools
- Die unterstützten Ressourcen konzentrieren sich darauf, verbundene Geräte und Gerätezustände im JSON-Format abzufragen
/devices: Liste der verbundenen Buttplug-Geräte/device/{id}: Geräteinformationen anhand der numerischen ID aus /devices/device/{id}/rssi: RSSI-Signalpegel anhand der Geräte-ID/device/{id}/battery: Akkustand anhand der Geräte-ID
- Als unterstütztes Tool gibt es nur
device_vibrate
- Parameter sind
id, optional motor, strength
- Der Standardwert für
motor ist 0
strength ist ein Zahlenbereich, bei dem 0.0 aus und 1.0 maximale Stärke bedeutet
- Das README enthält
schema_resources.json und schema_tools.json als Beispiele für JSON Schemas der Ressourcen und Tools
Aktueller Status und Einschränkungen
- Das Projekt wurde am 01.04.2025, dem April Fool’s Day, gestartet und ist ein schnelles Lernprojekt, das nach dem am Vortag erstellten experimentellen MCP-Service
dbn-go für Finanzmarktdaten entstand
- Es funktioniert, aber die Verbindungsbehandlung der zugrunde liegenden Bibliothek
go-buttplug wird als instabil beschrieben
- Die Geräteliste konnte mit Claude abgefragt werden, aber ein bestimmtes Gerät vibrierte selbst nur mit Intiface Central nicht und wirkte wie in einem „Read-only-Modus“
- Als weitere Einschränkung wird genannt, dass virtuelle Buttplug.io-Geräte hilfreich wären, um ohne physische Geräte testen zu können
- Das README stellt klar, dass echte End-to-End-Tests noch nicht abgeschlossen wurden
- Künftig müsse man die Ursache der Verbindungsinstabilität von
go-buttplug weiter untersuchen und verstehen, wie MCP-Hosts Tools, Resources und Resource Templates derzeit unterstützen
Installation und Nutzung mit Claude Desktop
brew tap conacademy/homebrew-tap
brew install conacademy/tap/buttplug-mcp
- Zur Nutzung muss die Hub-Anwendung Intiface Central heruntergeladen werden, um Geräte zu verwalten und den Server-Port zu prüfen
- Als Standardport wird offenbar
12345 angegeben
- In Claude Desktop werden in der MCP-Server-Konfiguration die ausführbare Datei und der WebSocket-Port eingetragen
- Ein Beispielpfad für die Installation per Homebrew unter MacOS ist
/opt/homebrew/bin/buttplug-mcp
- Das Konfigurationsbeispiel verwendet
--ws-port 12345
{
"mcpServers": {
"buttplug": {
"command": "/opt/homebrew/bin/buttplug-mcp",
"args": [
"--ws-port", "12345"
]
}
}
}
- Die Einrichtung von Claude Desktop folgt dem MCP User Quickstart, wobei die obige Konfiguration als Ersatz verwendet wird
Experimente mit Ollama und mcphost
- Für lokale Inferenz kann ein MCP-Host verwendet werden, der Ollama unterstützt
- Es muss ein Ollama LLM verwendet werden, das Tools unterstützt
- In den Experimenten wurde
mcphost genutzt; dieses Projekt ist ein MCP-Host vom Entwickler der Bibliothek mcp-go
- Das Ausführungsbeispiel speichert die obige Konfiguration in
mcp.json und startet sie dann mit dem Modell llama3.3
go install github.com/mark3labs/mcphost@latest
mcphost -m ollama:llama3.3 --config mcp.json
- Laut README werden in
mcphost nur Tools unterstützt, nicht aber Resources, sodass Geräte weder aufgelistet noch im Detail abgefragt werden konnten
- Mit
phi4-mini erhielt der Aufruf des Tools device_vibrate eine erfolgreiche Antwort, doch wegen der oben beschriebenen aktuellen Statusprobleme vibrierte das physische Gerät nicht
Build, Test-Tools und CLI
- Der Build wird mit task durchgeführt; das resultierende Binary wird unter
bin/buttplug-mcp erstellt
task
- Der Build-Prozess führt nach
go mod tidy den Befehl go build -o bin/buttplug-mcp cmd/buttplug-mcp/main.go aus
- Nützliche Test-Tools sind unter anderem
task stdio-schema | jq: JSON-Schema-Ausgabenpx @modelcontextprotocol/inspector node build/index.js: MCP Inspector Web GUI
- Die CLI-Optionen unterstützen Hilfe, Logdatei, JSON-Logs, SSE-Transport, SSE-Host, ausführliche Logs und die Konfiguration des Buttplug-WebSocket-Serverports
--ws-port int: Port für die Verbindung zum Buttplug-WebSocket-Server--sse: SSE Transport statt Standard-STDIO verwenden--log-file string: Ziel für die Logdatei oder Nutzung der Umgebungsvariable MCP_LOG_FILE--log-json: JSON-Logs verwenden--verbose: ausführliche Logs verwenden
2 Kommentare
Uff … Vielleicht ist das für uns einfach noch zu früh …
Meinungen auf Hacker News
Buttplug: An open-source software suite for teledildonics (https://buttplug.io/) 5 years ago | 249 comments
Empathy for the user having sex with your software (https://docs.buttplug.io/docs/dev-guide/intro/buttplug-ethic...) 10 months ago | 127 comments
T-code – A protocol for implementing UART serial communications to an adult toy (https://stpihkal.docs.buttplug.io/protocols/tcode.html) 2 years ago | 74 comments
An open-source standards and software project for intimate hardware (maybe NSFW) (https://buttplug.io/) 7 years ago | 39 comments
Buttplug Sex Toy Control Project Implemented in Rust (https://buttplug.io/) 2 years ago | 3 comments
Deldo is a sex toy control and teledildonics mode for Emacs (github.com/qdot) (2021) https://news.ycombinator.com/item?id=29207607 | 126 comments
Warum ist dieser Markt anders? Liegt es daran, dass große Unternehmen ihn meiden und ihn deshalb noch nicht kaputtgemacht haben?
Bevor ich diesen Artikel gesehen habe, dachte ich, die E-Bike-Community sei die größte Hacker-Community für Alltags-Elektronik. In Europa gibt es ziemlich viel Hacking an E-Bike-Computern; teils geht es darum, Geschwindigkeitsbegrenzungen aufzuheben, was aber illegal ist und in dänischen Großstädten auch mit hoher Wahrscheinlichkeit auffällt
Ich habe es hauptsächlich wegen Statistiken gemacht. Mein E-Bike-Computer setzte die „aktuelle“ Fahrstrecke alle 500 km zurück und speicherte die Gesamtfahrstrecke anderswo; wenn das Rad in die Werkstatt kam, wurde auch das zurückgesetzt. Auf dem Standardbildschirm gab es nicht einmal eine Uhr, daher war mein Hauptgrund, eine Uhr aufs Display zu bekommen; inzwischen habe ich auch Backups der Fahrstrecke und ein paar Spaß-Statistiken ergänzt
Wenn ich es in die Werkstatt gebe, flashe ich es wieder auf Werkseinstellungen zurück. Ich bin überhaupt kein Geräte-Hacker, konnte aber allein durch Suchen die passenden Tools für meine Marke finden und damit machen, was ich wollte. Ich denke, die meisten Alltagsgeräte haben kaum Sicherheit. Vielleicht liegt das daran, dass Europäer, die nicht wollen, dass die NSA über Google Camera hineinschaut, eher etwas kaufen, das nicht von einem großen Tech-Unternehmen stammt; aber auch Produkte großer Marken wie Bosch sind ziemlich hackbar. Wenn man die Hardware in der Hand hat, ist am Ende nicht fast alles hackbar?
Unternehmen wie Lovense haben zwar signalisiert, dass sie bereit wären, eine API zu veröffentlichen, aber auf GitHub gibt es praktisch nur ein leeres Repository. Lovense ist eine merkwürdige Firma; alles deutet auf ungefähr ein oder zwei Personen in Taiwan hin, und sie ist ziemlich undurchsichtig
Es gab auch fragwürdige Fälle. Gegen Marken wie Hytto/Lush [0] oder We-Vibe [1] gab es Sammelklagen
[0] https://www.courthousenews.com/judge-forwards-class-action-s...
[1] https://topclassactions.com/lawsuit-settlements/lawsuit-news...
Es wird als „Intimate Haptics Control Standard and Library“ beschrieben; eine ausführlichere Erklärung findet sich unter https://buttplug-spec.docs.buttplug.io/docs/spec.
Entweder waren personenbezogene Daten geleakt worden, oder ein Gerät hatte Nutzer „eingesperrt“ und dann Lösegeld verlangt. Ich saß am Schreibtisch und musste lachen, konnte aber nicht erklären, warum, weil der Inhalt viel zu NSFW war.
Auf der ersten Seite ist es zwar schon ziemlich weit nach unten gerutscht, aber fragt mich ruhig alles.
Ich wollte in die README schreiben, dass dieser konkrete MCP-Server ziemlich nutzlos ist und definitiv nicht die Art ist, wie ich sexuelle Interaktion haben möchte. Aber irgendwo muss man anfangen, und der Good-Giving-Game-Ansatz passt zu uns, also habe ich es auf GitHub gestellt.
Ironischerweise war mein Projekt vor zwei Jahren eine Integration von Buttplug in einen Charm-basierten SSH-Chatroom und eine BubbleTea-TUI. Dabei habe ich einen Teil der digitalen Zustimmung über SSH-Schlüssel abgebildet und als anonymen Graphen modelliert, welche Entität was mit den Geräten einer anderen Entität tun darf. Ich denke, die Zukunft von agentengesteuertem MCP wird solche Elemente brauchen.
Ich bin nicht der Maintainer von Buttplug.io, habe mich aber eine Zeit lang mit ihnen auf Discord ausgetauscht. Wo ihr schon mal hinschaut: Falls unter euch Rustaceans mit Interesse sind, sucht das Projekt zusätzliche Maintainer. Dieser MCP-Server ist in Golang geschrieben, aber im Buttplug-Ökosystem wäre Rust vermutlich die bessere Wahl.
Am Anfang meiner Laufbahn habe ich in der Haptikforschung gearbeitet und habe über Immersion auch mehrere einschlägige Patente. Meine Masterarbeit bestand darin, einen 3D-Haptik-Renderer zu schreiben und Haptik in VRML zu integrieren — falls ihr euch noch daran erinnert! Ich habe auch an einem NIH-geförderten Projekt zu Diagnosegeräten für sexuelle Dysfunktion gearbeitet und selbstgebaute Spielzeuge gefertigt. Jetzt habe ich gerade ein Neurable-EEG-Headset bekommen und arbeite an Biaerolar Beats [1].
Zurück zum Thema Vibe Coding: Ja, ich habe damit einen LELO F1 vibrieren lassen, aber dieses Projekt ist wirklich von Hand gebaut. Vor ein paar Wochen habe ich versucht,
a2a4a2amit Claude und Gemini per Vibe Coding zu bauen, aber das A2A-Protokoll war so neu, dass es schwierig war, den Modellen A2A beizubringen. Ich frage mich, wie Leute im Allgemeinen mit so etwas umgehen.Insgesamt hat es Spaß gemacht, und ich habe viel über Tool-Calling-LLMs gelernt. In jener Woche habe ich drei MCP-Server gebaut: einen für Geld [2], einen für Sex [3] und einen für Drogen [4]. Dank
mark3labs/mcp-go.Beim letzten, AgentDank [4], bin ich noch nicht zur Nacharbeit gekommen, aber im Hinblick auf öffentliche Daten und echte KI-Ergebnisse ist es wahrscheinlich das coolste. Schaut euch dort das Video an. Benutzerdefinierte Daten und SQL-Endpunkte an ein Tool-Calling-LLM anzubinden, ist absurd mächtig.
[1] https://github.com/ConAcademy/biareolar-beats
[2] https://github.com/NimbleMarkets/dbn-go/blob/main/cmd/dbn-go...
[3] https://github.com/ConAcademy/buttplug-mcp
[4] https://github.com/AgentDank/dank-mcp