mcp-server-excel: driving the real Excel COM API from an AI agent

COM automation, not file parsing

The distinction the project leads with is the one that matters for adoption. ExcelMcp drives the actual Excel application through its official COM API, which is why it can refresh Power Query, recalculate formulas, evaluate DAX, run VBA and Python `=PY()`, and preserve PivotTables, charts, macros, the Data Model and workbook formatting.

A tool that parses a spreadsheet file cannot do most of that. It reads cells, and everything that is not cell content, meaning a pivot definition, a query, a macro, a chart or a data model connection, either does not exist in the file it sees or exists in a form it must reconstruct. Driving Excel means Excel does the work, so the results can be inspected live and the workbook can continue to be edited normally afterwards.

The surface area is large and the documentation counts it precisely: 63 MCP tools across 33 feature areas, with 421 operations. The feature grouping is by object type rather than by concept. Data and analytics covers Power Query, DAX, Power Pivot, Excel Tables, PivotTables and data connections. Cells and workbooks covers ranges, formulas, formatting, worksheets, files, calculation and named ranges. Charts and visuals covers charts, slicers, conditional formatting, screenshots, drawings and sparklines. Automation and advanced covers VBA, Python in Excel, Goal Seek, scenarios, data tables, windows and XML Maps.

The example requests in the documentation show the intended voice of use: importing a CSV with Power Query and loading it to the Data Model, creating a PivotTable of revenue by region and adding a column chart, using Goal Seek to find the price that produces $100,000 profit, and asking to see Excel while the work happens.

Two entry points over one set of core commands

Both interfaces expose the same Core commands and the same behaviour, so the choice between them is technical rather than functional. The README is explicit that coding agents can use either one.

The MCP Server suits any MCP-compatible client, with tool discovery and persistent sessions. The CLI, named `excelcli`, suits agents that can run terminal commands, and its stated advantage is built-in help without loading MCP tool definitions, which usually means fewer AI tokens. That is the argument to weigh when the agent's context window is the binding constraint: an agent that has to read dozens of tool schemas on every session pays for them, while a CLI can ask for the help for the one command it needs.

The internals differ in one respect that has practical consequences. The MCP Server calls the ExcelMcp service in-process. The CLI uses a background daemon, which is how workbook sessions persist across commands. If you drive a sequence of edits to the same workbook through the CLI, that session continuity is what keeps the workbook open between steps rather than being reopened and re-saved each time.

The diagram in the documentation shows the layering, from the AI assistant or script, through the MCP Server or CLI, into the ExcelMcp Core commands, and down to the real Excel COM API. The repository carries a `docs/ARCHITECTURE.md` for the details, plus FEATURES.md at the top level and a `doc-counts.json` that presumably keeps the operation count honest.

Getting it installed: extension, MCP server, CLI or plugin

The documentation routes by use case rather than by one install path. For VS Code there is a Marketplace extension, `sbroenne.excel-mcp`. For Claude Desktop or another MCP client there is an MCP Server installation guide. For coding agents where token cost matters, there is a CLI installation guide. And there is an installation overview for people who are not sure yet.

For GitHub Copilot CLI, the project points at the Awesome Copilot Excel listings, where two plugins are available:

copilot plugin install excel-mcp@awesome-copilot
# Or, for command-line Excel automation:
copilot plugin install excel-cli@awesome-copilot

One operational instruction appears immediately after the install steps and is easy to skim past. Close open Excel workbooks before starting, because ExcelMcp requires exclusive access while automating them. This is the same constraint that shows up in any COM automation work on Windows, and it is a hard one: a workbook already open in a user session will block the automation, and the failure mode looks like a hang rather than a clear permission error.

The project also ships in other shapes. The repository top level shows a `vscode-extension/` directory, an `mcpb/` directory, `npm-packages/`, a `skills/` directory, `samples/`, `examples/mcp-configs/` for client configuration snippets, `llm-tests/` for tests aimed at language models, and `build.ps1` with `global.json` and `Directory.Build.props` for the .NET build. The primary language is C#, and the badge states .NET 10.

The hard platform boundary is stated up front

The README carries an explicit callout box about requirements, and it is worth quoting the shape of it. It requires Windows, Microsoft Excel 2016 or later, and an interactive desktop, and it says directly that it is not intended for Linux, macOS, or server-side batch processing.

That is not a limitation the project apologises for. It follows from the approach. COM is a Windows automation interface tied to a running desktop Excel instance, so there is no way to run this on a Linux container or in a headless CI job without a Windows host with a desktop session and a licensed Excel. The alternative family of tools, which parse or rewrite workbook files directly, does run anywhere, and that is exactly the trade the project is asking you to make.

The desktop requirement also has a UX consequence that shows up in the feature list. One of the documented requests is to show Excel while the work happens, and the feature set includes window control and screenshots. Because the tool is driving a real application, the agent can show its work in the Excel window rather than only reporting results, which is a debugging aid that a file-rewriting tool simply cannot offer.

Everything else in the environment is Windows shaped too: the topic list includes windows, the repository uses build.ps1 and Directory.Build.targets, and the CLI daemon model depends on Windows process behaviour.

Token cost is the real reason to pick the CLI

The MCP Server and CLI comparison in the documentation is short, and the interesting cell is the CLI one. The CLI offers built-in help without loading MCP tool definitions, usually with fewer AI tokens. That is the whole argument, and it matters more than it first appears.

An MCP client discovers tools by reading their schemas, and a toolset with 63 tools across 421 operations has a lot of schema to read. With 421 operations to choose from, an agent also needs help deciding which operation applies, which is what the CLI help is for. For a long-running coding agent that opens Excel a few times a day, paying for the full schema on every session is a real cost, while an agent that needs Excel once in a while may prefer the discovery that MCP gives it.

The other side of the coin is that the MCP route gives persistent sessions and tool discovery handled for you, which is simpler to reason about when you are wiring up an unfamiliar client. If you are building a Claude Desktop configuration or embedding the server into an agent framework, that convenience is what you are paying the tokens for.

Current command details come from CLI help or the MCP tool descriptions, per the documentation, rather than from a separately maintained reference. That is worth knowing when you write an agent prompt: there is no third place to look up the operation names, and the two interfaces are the reference.

Maintenance, packaging and the licensing picture

The repository is not archived and the last push was on 2026-10-19, the day before this review. Three tagged releases landed in the week before that: v2.5.0 on 2026-10-19, v2.4.1 on 2026-10-13 and v2.4.0 on 2026-10-13. Two releases on the same day with a patch bump between them suggests a tight release loop, and the presence of a `.changeset/` directory plus a CHANGELOG.md confirms that releases are driven by changeset entries rather than by hand editing.

The package.json at the root is worth reading because it explains itself. It is marked private, its version tracks the product version at 2.5.0, and its description states that the file exists solely to host Changesets tooling for CHANGELOG.md generation, that it is never published to npm and has no runtime dependencies. Anyone auditing the repository for supply chain risk should notice that the root npm package is a release tool, not the product, and that the actual runtime dependencies are the .NET packages in Directory.Packages.props.

The licence is MIT, with the LICENSE file at the root, and the README links to a privacy page and a security page alongside contributing and changelog documentation. PRIVACY.md and SECURITY.md are both present in the tree. For a tool that opens spreadsheets on a machine and can run VBA inside them, those two files deserve reading before you point it at a business-critical workbook, particularly since the tool can execute macros and can display Excel while it works.

The author also maintains related projects with the same shape: a PowerPoint MCP Server described as the sister project, a Windows MCP Server for general Windows automation, and an MCP server for OBS Studio.

Editorial conclusion

Adopt mcp-server-excel when an agent has to work inside a live Excel workbook with PivotTables, Power Query, DAX or VBA intact, since the tool drives the actual application instead of rewriting a file, and prefer the CLI when token cost matters because it avoids loading MCP tool definitions into the context. Do not adopt it for Linux, macOS, or unattended batch work, since it requires Windows, Excel 2016 or later and an interactive desktop. Verify first that the workbook you intend to automate can be closed, because ExcelMcp needs exclusive access, and read PRIVACY.md and the docs/ARCHITECTURE.md before pointing it at a file with sensitive data.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. sbroenne/mcp-server-excel on GitHub