Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
作者提供的说明(英文原文)
Virtual keyboard, gamepad and mouse for AI agents on Linux / Steam Deck.
这三项永远不会合并成一个分数:意见、测量和人气是不同的东西。
我们还没有为它写通俗的介绍。下面是我们从注册中心读取到的事实。
选择你使用的 AI 应用,然后复制设置。
你需要
你用的是哪个应用?
在上方选择你的应用。我们会记住它,下次按钮会显示“安装到 …”。
打开 Claude Desktop → Settings → Developer → Edit Config,把下面的内容粘贴到 claude_desktop_config.json
{
"mcpServers": {
"elfdeckai": {
"command": "uvx",
"args": [
"elfdeckai"
]
}
}
}在终端中运行这条命令
claude mcp add elfdeckai -- uvx elfdeckai粘贴到项目中的 .cursor/mcp.json,或 ~/.cursor/mcp.json
{
"mcpServers": {
"elfdeckai": {
"command": "uvx",
"args": [
"elfdeckai"
]
}
}
}浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。
粘贴到项目中的 .vscode/mcp.json
{
"servers": {
"elfdeckai": {
"type": "stdio",
"command": "uvx",
"args": [
"elfdeckai"
]
}
}
}浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。
这个服务器在你的电脑上运行,而 ChatGPT 只能连接互联网上的服务器。请选择其他应用。
你的选择通过 Cookie 保存在这台设备上,无需账户。
这些设置是根据作者在注册中心的条目生成的。如果 README 的写法不同,请以 README 为准。
它在你的电脑上运行;安装后,工具列表会显示在你的 AI 应用中。
我们检查的是任何人都能看到的信息;我们没有阅读代码。不适用的检查项不计入总数。 · 检查于 2026年11月6日
注册名称已通过 GitHub 账户 Garthnesss 验证,该账户拥有此仓库
我们还没有从 GitHub 读取这个仓库
我们还没有从 GitHub 读取这个仓库
它在你的电脑上运行,没有互联网端点
在你的电脑上运行,改用本地设置
它在你的电脑上运行;我们只能读取互联网端点的工具列表
与注册中心里这个分类中所有活跃的服务器比较。只有当发布者拥有该仓库时,星标数才计入。
它在 1 项适用的基础检查中通过了 1 项。我们没有阅读代码。在添加密钥或令牌之前,请先看看这个服务器要求哪些权限,并使用只具备所需权限的密钥。
注册中心没有列出必需的密钥,不过有些服务器会在首次使用时要求你登录。
它在你的电脑上运行。你的 AI 应用会在需要时启动它,数据不会经过作者的服务器(除非它自己调用在线服务)。
GitHub 仓库最后更新于–,最新版本(1.1.3)于9天前进入注册中心。
支持 MCP 的应用,例如 Claude Desktop、Claude Code、Cursor 和 VS Code。你的电脑上还需要有 Python (uv)。
同一分类中有:Spec Driven Development, Remote Desktop Commander, Reelsaw
同一分类中其他作者的服务器,按星标数排序。
如何看卡片:★ GitHub 星标i三大支柱:评价 · 检查 · 使用情况i更新 = 最新版本发布到注册中心的时间i
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Remote Desktop Commander: use files, terminal and processes on your own computers from any AI app.
Drive a self-hosted Reelsaw: turn long videos into vertical clips, edit, re-render and export them.
按原文从作者的仓库复制。PopNx MCP 没有审查或背书其内容。HTML、图片和脚本已被移除。链接会离开本站。
Let an AI play games on your Steam Deck.
ElfDeckAI gives an AI assistant such as Claude a virtual controller, keyboard and mouse on your Steam Deck, plus the ability to see the screen. The AI looks at the game, decides what to do, and presses the buttons itself. It works in both Gaming Mode and Desktop Mode, and on other Linux machines too.
You need a Steam Deck, and a PC on the same Wi-Fi with an AI app that supports MCP, such as Claude Desktop.
1. Install on the Deck. Switch the Deck to Desktop Mode (Steam button → Power → Switch to Desktop), open Konsole, and paste:
curl -fsSL https://raw.githubusercontent.com/Garthnesss/ElfDeckAI/main/install-on-deck.sh | sh
At the end it prints the Deck's IP address. Keep it for step 3.
2. Turn on SSH on the Deck (once), so your PC can reach it. In the same Konsole window:
passwd # choose a password for the Deck, if you haven't
sudo systemctl enable --now sshd
3. Connect your PC. On the PC, paste one line. It asks for the Deck's IP address and its password (once), then sets everything up, including Claude Desktop.
irm https://raw.githubusercontent.com/Garthnesss/ElfDeckAI/main/setup-pc.ps1 | iex
curl -fsSL https://raw.githubusercontent.com/Garthnesss/ElfDeckAI/main/setup-pc.sh | sh
4. Try it. Restart Claude Desktop and ask: *"Take a screenshot of my Steam Deck."* When you see your Deck's screen, start a game and ask the AI to play.
Tips
Three small programs on the Deck create virtual input devices through the Linux kernel's /dev/uinput, so games and Steam see them as real hardware:
A fourth program, an MCP server, exposes them, together with a screenshot tool, as tools any MCP client can call. Your PC's AI app starts that server on the Deck over SSH. Nothing depends on a particular game or emulator: ElfDeckAI has played Pokémon FireRed in RetroArch on a physical Steam Deck, from the intro through the first rival battle, with the agent seeing only screenshots. See notes/driving.md for what was learned.
Everything is single-file Python using only the standard library, and the Deck install needs no sudo.
pip install elfdeckai
elfkey & elfpad & elfmouse &
echo "key x 150" > /tmp/elfkey.fifo # tap X for 150 ms echo "press a" > /tmp/elfpad.fifo # tap A echo "move 300 -100" > /tmp/elfmouse.fifo # move the pointer echo "click left" > /tmp/elfmouse.fifo # left click
grep -E "ElfKey|ElfPad|ElfMouse" /proc/bus/input/devices # confirm the devices exist
Without pip, clone the repository and run python3 elfkey.py (and so on) directly. Runtime state lives in /tmp and is cleared on reboot.
/dev/uinput is user-writable on the Steam Deck by default. On other distributions, install the udev rule first (see Installation).
elfdeckai-mcp is a Model Context Protocol server (stdio transport) that exposes 22 tools:
| Group | Tools |
|---|---|
| Keyboard | key_tap, key_down, key_up, key_release |
| Gamepad | pad_press, pad_down, pad_up, pad_stick, pad_trigger, pad_center, pad_reset |
| Mouse | mouse_click_at, mouse_move_to, mouse_move, mouse_click, mouse_down, mouse_up, mouse_scroll, mouse_hscroll, mouse_release |
| Vision | screenshot |
| Timing | wait |
screenshot captures the screen of the machine the server runs on and returns a PNG, so an agent can work in a look, act, look again loop without a separate video stream. It supports the Steam Deck in both Gaming Mode (through gamescope) and Desktop Mode (KDE Plasma), wlroots compositors and X11. Screens larger than 1280 pixels on their long side are scaled down before sending (set ELFDECKAI_SCREENSHOT_MAX to change the limit, or 0 to turn it off), and the result includes the image's size.
mouse_click_at and mouse_move_to take coordinates in the pixels of the most recent screenshot, so an agent can click exactly what it sees, whatever the screen's real resolution or the scaling applied. They assume a single display.
Running on the same machine as the daemons:
{"mcpServers": {"elfdeckai": {"command": "elfdeckai-mcp"}}}
Running on a Steam Deck from an AI client on your PC, over SSH (the setup-pc scripts in Start here write this for you):
{"mcpServers": {"elfdeckai": {
"command": "ssh", "args": ["-i", "~/.ssh/elfdeckai_ed25519", "-o", "IdentitiesOnly=yes", "-o", "BatchMode=yes", "deck@DECK-IP-ADDRESS", ".local/bin/elfdeckai-mcp"]}}}
It logs in with an SSH key, because the MCP client cannot answer a password prompt. Without pip, use "command": "python3", "args": ["/path/to/elfdeckai_mcp.py"].
Every tool call is validated against the tool's schema and the daemon's own parser before anything is written to a FIFO. If a daemon is not running, the call returns an error immediately instead of blocking.
/tmp/elfkey.fifo)| Command | Effect |
|---|---|
key [ms] | Tap a key (default 120 ms) |
down / up | Hold / release a key |
release | Release every held key |
quit | Release everything and exit |
Keys: a–z, 0–9, arrows, enter, esc, space, tab, backspace, shift, rshift, ctrl, rctrl, alt, ralt, capslock, f1–f10, home, end, pageup, pagedown, insert, delete and common punctuation. The full table is KEYS in elfkey.py.
/tmp/elfpad.fifo)| Command | Effect | |
|---|---|---|
press [ms] | Tap a button or D-pad direction (default 120 ms) | |
down / up | Hold / release | |
| `stick left\ | right [ms]` | Set an analog stick, −100 to 100 per axis; with ms, recenter afterwards |
| `trigger left\ | right <0..100> [ms]` | Set an analog trigger; with ms, release afterwards |
center | Return sticks, triggers and D-pad to neutral | |
reset | Release everything | |
quit | Release everything and exit |
Buttons: a b x y lb rb l2 r2 select start guide l3 r3, plus D-pad directions up down left right.
ElfPad identifies as an Xbox 360 controller, so SDL, Steam Input and RetroArch map it without configuration. l2 and r2 drive the analog trigger axes, as on the real controller; there are intentionally no digital trigger buttons, because declaring them shifts Select, Start and Guide off the standard button indices.
/tmp/elfmouse.fifo)| Command | Effect |
|---|---|
move [glide_ms] | Move the pointer relatively; with glide_ms, spread the move over that time |
moveto [ ] | Place the pointer at an absolute position: pixel (x, y) of a width×height frame, or device units 0–32767 across the screen when no frame is given |
click [ms] | Click left, right or middle (default 100 ms) |
down / up | Hold / release a button (for drags: down, move, up) |
scroll / hscroll | Vertical / horizontal wheel (positive is up / right) |
release | Release every held button |
quit | Release everything and exit |
move is relative: negative dy moves up. Its units are motion counts, not guaranteed screen pixels, because pointer acceleration applies. Each command is limited to ±10,000 counts and ±120 wheel ticks.
moveto uses a second virtual device, ElfMouse Absolute, which compositors treat like a virtual machine's tablet pointer, so the position is exact. Buttons are pressed on whichever device moved last.
Because the caller may be a language model, the daemons are built so that bad input cannot leave the machine in a bad state:
down/up.finally block, held inputs are tracked, and on quit, SIGTERM, SIGINT or SIGHUP every input is released before the device is removed. If the MCP client disconnects mid-hold, the server releases every held input as it exits. key_release, mouse_release and pad_reset release everything on demand.Scope: these are real OS-level input devices. They act on whichever window has focus, including terminals and browsers. ElfDeckAI keeps input bounded, validated and releasable; deciding where an agent is allowed to act is up to the operator. Only run agents you trust, in sessions you can supervise.
Manipulated callers: the hardening above covers a caller that hallucinates or sends malformed input. It does not cover a caller that is manipulated — and the agent's eyes are a screenshot, so anything on screen (a web page, a game dialog, a chat message) is untrusted input that could try to talk it into typing into a terminal. There is no key or window allowlist and no physical kill switch; the mitigations are the operator's: supervise the session, keep terminals and browsers you care about out of focus, and stop the daemons (systemctl --user stop elfkey elfpad elfmouse) when the agent is not driving. If the MCP client disconnects, the server now releases every held input on its way out — but a live, manipulated agent is an operator problem, not one this validation layer can solve.
| Approach | Limitation |
|---|---|
| Emulator APIs (PyBoy, mGBA scripting) | Only work inside a specific emulator. |
| Sending keys through Moonlight or other streaming clients | Mouse clicks are forwarded, but synthetic keyboard events are not. |
| xdotool | Cannot reach native Wayland clients. |
| ydotool, dotool | Same uinput approach for keyboard and mouse, but no gamepad, raw keycodes, and no agent-facing interface (MCP, input bounds, release commands). |
| Hardware input emulators (KVM gadgets, controller adapters) | Work, but require extra hardware. |
Requirements: 64-bit Linux with /dev/uinput and Python
只显示了开头部分;其余内容请在仓库中阅读