snact has an MCP server (snact mcp) that exposes snap, read, click, fill, eval, etc. as JSON-RPC tools. But the scope has drifted as the CLI has grown.
Current state
- MCP exposes core commands (snap, read, click, fill, type, select, scroll, eval, wait, screenshot, session, browser)
- Record/replay is CLI-only — not exposed via MCP
- New CLI features (idle-timeout, etc.) aren't reflected in MCP tool schemas
- Schema introspection (
snact schema) and MCP tool definitions are maintained separately — easy to get out of sync
Questions to resolve
- Who uses MCP? Claude Desktop and other MCP-only clients. Claude Code and scripted agents call the CLI directly — MCP adds nothing for them.
- Should record/replay be in MCP? Recording is cross-invocation state that doesn't map cleanly to MCP's request/response model.
- Is maintaining two surfaces (CLI + MCP) worth the cost? Every new feature needs CLI args, schema output, AND MCP tool definitions. That's three places to update.
- Alternative: keep MCP as a thin stable subset (snap/read/act) and let power features live in CLI only.
Not blocking anything — just needs a decision before adding more MCP tools.
snact has an MCP server (
snact mcp) that exposes snap, read, click, fill, eval, etc. as JSON-RPC tools. But the scope has drifted as the CLI has grown.Current state
snact schema) and MCP tool definitions are maintained separately — easy to get out of syncQuestions to resolve
Not blocking anything — just needs a decision before adding more MCP tools.