[kastro5]

Adds kastro5/opendeck-mcp to the Native OpenAction plugins section.

The plugin lets an AI assistant (Claude Code or any MCP client) read and change an OpenDeck setup: keys, profiles, multi and toggle actions, app switching and plugins. Changes are staged, previewed and backed up before they're applied. It runs on Windows and Linux. Notes:

• It has no actions. OpenDeck starts it as a background service that serves MCP over HTTP on 127.0.0.1:8765. The gear in the Plugins tab (HasSettingsInterface) opens a local page with the client setup command, the address to listen on and a token reset. Every request needs a bearer token.
• Applying changes restarts OpenDeck. OpenDeck caches profiles in memory, so changes beyond title, image and settings tweaks are written while it's stopped. A detached helper process stops OpenDeck, takes a backup, writes the files and starts OpenDeck again.
• It's a frozen Python binary (PyInstaller), built by GitHub Actions on each tag. One zip contains both the Windows and the Linux build (CodePathWin / CodePathLin). The Linux build is smoke-tested in CI but hasn't been run against a real deck. Applying refuses to run under Flatpak OpenDeck.
• The same server is also on PyPI and in the MCP Registry (io.github.kastro5/opendeck-mcp), for people who'd rather run it through uvx.
• It's flagged ai_assisted. It was developed with Claude Code.

I ran validate_submission.py locally against this branch (format, section, ordering, repository, release, manifest, icon), and it passed.

🤖 Generated with Claude Code

[nekename]

@kastro5 That's actually a super cool idea. Don't you think there might be a cleaner way to do this than via constant restart, though? Maybe something implemented in OpenDeck directly?

[kastro5]

Thanks! Agreed, the restart is the ugly part. Small edits (title, image, settings) already go live without one: setTitle/setImage through --process-message, and setSettings through a property-inspector socket so the plugin hears it. Only structural changes restart: adding, moving or removing keys, profiles, and app rules. That's because OpenDeck keeps profiles in memory and overwrites external edits.

A small inbound event would remove that, e.g. reloadProfile { device, profile }. It would drop the cached store (ProfileStores::remove_profile), let get_profile_store_mut re-read the file, and send willDisappear/willAppear for its instances like a profile switch does. A matching way to re-read applications.json would cover app rules. Available via --process-message, opendeck-mcp could then write the files and ask OpenDeck to pick them up, with no restart. I'd be happy to open a PR for it if you're open to the idea. Any preference on the event name or shape?

[nekename]

I'm actually playing with the idea of building MCP support into OpenDeck directly, because I really like this concept. I'm quite busy these days but I'll get back to you about this

[kastro5]

Glad to hear you liked it. Feel free to take anything from opendeck-mcp, and I'm happy to help when you get to it.