How Mouse Connects to Your Assistant
Mouse implements the Model Context Protocol (MCP) as a local server running inside VS Code. Your AI coding assistant (GitHub Copilot, Claude Code, Amazon Q Developer, or any other MCP-compatible client) communicates with Mouse over MCP's stdio transport. The assistant sends tool calls, Mouse executes them against your workspace files, and returns structured results.
Everything runs locally. No file content leaves your machine, no intermediary services process your edits, and no network calls are made beyond the license heartbeat. The assistant interacts with Mouse the same way it interacts with any MCP server: through tool calls defined in Mouse's tool manifest.
What the Assistant Sees
Mouse exposes 10 tools to the assistant via MCP, organized around three capabilities.
Reading. The assistant can read files at specific line ranges, jump to a target line with surrounding context, search for literal text or regex patterns, and retrieve file metadata. These tools let the assistant investigate a file's structure and content before making changes.
Editing. The assistant can insert lines at a position, delete a range of lines, replace text by literal match, edit at character-level or column-level precision, and relocate content blocks. Each operation targets exact coordinates without reading or echoing surrounding content. Single-edit and batch-edit variants are available: single edits save immediately by default, while batch edits stage changes for review.
Staging. After batch editing (or any edit with staging enabled), the assistant can inspect the staged result against the original file, refine individual operations, unstage specific edits, or discard everything. Staging tools give the assistant a self-correction loop before changes reach disk.
For the complete tool catalog, see the Edit Operations Reference.
Staged Editing and the Dialog Box
When the assistant calls batch editing, changes are staged in memory rather than written to disk. The original file remains untouched. At this point, the assistant enters what Mouse calls the Dialog Box: a state where every subsequent tool response includes reminders about the uncommitted changes and the available next steps (save, cancel, refine, or review with staged content). The name is borrowed from the front-end UX pattern of a dialog box that blocks further action until the user confirms or cancels, but there is no physical panel, modal, or notification on screen.
All operations within a batch reference the original file state. The fifth operation targets the same line numbers as the first, regardless of what other operations in the batch insert or delete. This eliminates the cascading line-drift problem that plagues sequential editing with built-in tools. If any single operation fails, the rest remain staged and the assistant can fix just the failure, then save everything together or discard the entire batch.
For full technical details on batch editing, self-correction, and the Dialog Box lifecycle, see Batch Editing and the Dialog Box.
Architectural Benefits
Traditional AI file editing depends on string replacement: find a block of text, echo it in full, and replace it with a modified version. This approach is token-expensive (the assistant must echo every line it wants to change or remove), fragile (a single whitespace mismatch causes silent failure or wrong-location matches), and irreversible (changes write directly to disk with no review step).
Mouse's coordinate-based architecture avoids these costs. Operations specify positions (line numbers, character offsets, column ranges) rather than echoing content. Edits are staged in memory for verification before being committed. Failed operations within a batch can be corrected without discarding successful ones. The result is lower token consumption, fewer broken files, and an auditable self-correction loop between the assistant and the workspace.