WilliamSmithEdward/xlide_mcp

**An MCP server for the inside of an Office file.** Read, write, analyze and
test the VBA in Excel, Word, PowerPoint and Access, and edit the document around
it. Visual Basic 6 projects open the same way.
VBA, Power Query and OOXML worksheet edits need no Office installation and run on
Windows, macOS and Linux. Reading .xlsb and .xls cells, writing .xlsb cells,
and running macros or tests need Windows with the desktop application.
Why
An agent asked to fix a macro works from a copied snippet with no idea what else
is in the project, or asks the user to export the modules and paste them back
afterwards. Both treat the Office file as opaque. The VBA project, the form
designs and the M code are all readable and writable without opening the
application at all.
This server makes that reachable, and bounds it. A write is refused if the
module changed since it was read. An analysis error fails the change. A run
happens in an application the server created and holds a deadline over. Anything
that cannot be undone is the user's decision.
Implementations
| Directory | Language | Status |
|---|---|---|
| python/ | Python 3.10+ | Reference implementation |
Other languages go in sibling directories. Python is normative: it tracks the
upstream libraries, and ports track it. See docs/porting.md.
Install and run
Point a client at it. For Claude Desktop, Claude Code or any client that launches
a server over stdio:
For VS Code, put this in .vscode/mcp.json at the workspace root. VS Code uses
servers here; the portable .mcp.json format above uses mcpServers.
Run MCP: List Servers in VS Code to start xlide and inspect its output if it
does not register. The server prints its version and allowed roots to stderr on
startup. The VS Code configuration format and commands are described in
VS Code's MCP guide.
Or install nothing and let uv fetch it on
first run. uv is one binary and installs its own Python, so a machine with
neither can still run this:
The live extra is safe to ask for on every platform: what it pulls in is marked
sys_platform == 'win32', so off Windows it resolves to nothing and the same
configuration works everywhere. Drop the --from pair for the file layer alone.
uvx takes the newest published version unless you pin it, as xlide-mcp@1.2.4.
There is a Dockerfile for the file layer, which is the part that needs no
Office installation. Mount the folder holding the files at /workspace, because
that is the root the container is bounded to:
--root is the security boundary. Every path a tool accepts is resolved,
symlinks included, and refused unless it lands inside a root. Add --read-only
to allow reads and analysis and refuse every write.
Call xlide_doctor first from a new client: it reports the workspace roots, which
layers are installed, which Office applications this machine has, and whether
each one has the Trust Center setting that module injection needs.
What it does
**Files** - the VBA project and the document it lives in. Most file tools need no
Office installation; binary Excel grids use Excel on Windows.
*The code project*
| | |
|---|---|
| Discover | xlide_list_projects, xlide_project_info, xlide_validate_project, xlide_create_project, xlide_doctor |
| Modules | xlide_list_modules, xlide_read_module, xlide_write_module, xlide_edit_module, xlide_rename_module, xlide_delete_module, xlide_list_procedures, xlide_search_modules |
| Analysis | xlide_analyze, xlide_analyze_source, xlide_rules |
| Forms | xlide_list_forms, xlide_read_form, xlide_manage_form, xlide_edit_form |
| References and catalog | xlide_list_references, xlide_manage_reference, xlide_access_catalog, xlide_read_access_query |
| Source control | xlide_export_modules, xlide_import_modules, xlide_git_changes |
xlide_edit_module accepts preview_only=true to check a batch of line edits and
return its proposed diff without saving. The preview's content token can be used
to apply the same edits if the module has not changed.
xlide_search_modules returns tokens for matched modules, so its line numbers