90 days of telemetry from an open-source MCP server that drives the actual Excel desktop app. The numbers were not where I thought they would be.
Half a year ago I asked a simple question: why can AI agents write a React app from scratch but choke on Revenue Model v27 final final.xlsx?
The answer turned out to be boring and important.
Agents had spreadsheet libraries. They did not have Excel.
So I built Excel MCP Server: an open-source MCP server that drives the real Excel desktop application through COM automation. Not a .xlsx parser. Not Open XML. The actual app, with its calculation engine, VBA, Power Query, pivot caches, and all the quirks that make a workbook a workbook.
The "just use openpyxl" problem
Every time I talk about this, someone says "why not use a file-based Excel library?"
For generating a .xlsx from a server, those libraries are great. Linux containers, no Office install, fast.
They are not Excel.
They do not run Excel's calculation engine. They do not execute VBA. They do not refresh Power Query. They do not touch the COM object model. They cannot tell you whether the report looks right.
For generating spreadsheets, that is fine. For automating workbooks that already run a business, it is the difference between "I edited a file Excel can open" and "I worked inside Excel."
Excel MCP Server is for the second case. The workbook is treated as an application, not a zip of XML.
The architecture, in one diagram
AI assistant
-> MCP protocol
-> Excel MCP Server (in-process MCP, or named-pipe CLI daemon)
-> Excel COM automation
-> Real Excel.exe with the workbook open
That last line is the entire thesis. 90 days later I have telemetry. The numbers told me things I did not expect.
What I expected vs what 90 days of telemetry showed
90 days, anonymous, opt-in: 2,908 users, 86,090 sessions, 488,548 tool invocations.
Growth was sharper than I expected. Weekly users went from 84 to 1,209. Weekly sessions from 310 to 11,769. February: 800 monthly users. March: 1,682. April was on track to clear 2,000 before the month closed.
Fine. Growth charts are nice. Here is the part that actually surprised me.
Surprise 1: agents care about how the workbook looks
7,700+ screenshot operations. Plus 1,144 calls to arrange Excel windows, plus 1,875 status-bar messages.
I built screenshot capture as a debugging affordance. Users and agents are using it as part of the loop. They render the sheet, look at it, and decide what to do next.
If your automation target is a visual app, your tool surface needs visual feedback. Headless is not always the answer.
Surprise 2: VBA is extremely not dead
20,000+ VBA operations from 500+ users.
Not nostalgia. Enterprise reality. There are companies running their month-end close on a macro a finance manager wrote in 2014. If your agent cannot read, edit, import, or run VBA, it cannot touch any of that.
Modern AI tooling has to meet legacy automation where it lives. Macros included.
Surprise 3: people are not using this for "read cell A1"
The median user fires 65 tool invocations. The 95th percentile fires 1,000+. The 99th fires 3,000+. The most active anonymous user fired 10,060.
That is not a demo. That is somebody with an agent in the loop on real work.
And the work itself is heavier than I assumed: 25K+ Power Query, connections, and Data Model operations. People are using this to inspect M code, refresh queries, and poke at DAX models. Excel as a local BI environment, driven by an LLM.
Surprise 4: presentation is half the job
~68K formatting and presentation operations. Number formats, column widths, merged cells, conditional formatting.
Many Excel tasks do not end at "the data is correct." They end at "the workbook is ready to send." For agents, polishing is part of the workflow, not a nice-to-have.
Bonus surprise: nobody lets old tools die
After I shipped cleaner domain-focused tools, the legacy excel_* tools still pulled 45,507 invocations from 214 users.
Once an LLM client or prompt depends on a tool name, that name is load-bearing. Renames are breaking changes. MCP tool surfaces are APIs and they age like APIs.
What the GitHub history said
I also went through the full repo: 197 issues, 417 PRs, 382 merged, 3 issues open.
I expected most of it to be "please add a wrapper for X." It was not. The recurring themes:
- 168 issues on COM stability, hangs, cleanup, Click-to-Run quirks
- 147 issues on testing, CI, regression, smoke tests
- 138 issues on MCP behavior, schemas, tool definitions
- 104 issues on the CLI, daemon, named pipes, packaging
- 91 issues on Power Query, Data Model, DAX
- 27 issues on VBA
The most-commented issue in the project's history is "create Excel Tables programmatically." That sounds boring until you realize how much agent usefulness collapses if you cannot turn a loose range into a structured table object.
The hard part of this project was never exposing Excel APIs. The hard part was surviving STA threading, modal dialogs, workbook locks, daemon startup races, schema drift, and the difference between Office Click-to-Run and MSI installs on a Tuesday.
That weird path is exactly what file-based libraries skip, and exactly where real users live.
Three things I would tell anyone building an MCP server
1. Tool names are user intent, not API mechanics. format-range, refresh, create-pivottable, capture-sheet. Each one removes a translation step the model would otherwise have to invent. A few well-named domain tools beat dozens of generic primitives.
2. State is the whole game. Workbooks have state. Excel has state. Calculation mode has state. COM has state. An MCP server for a stateful desktop app is not a stateless HTTP wrapper with fancier transport. Sessions are the product.
3. Once a tool ships, the name is permanent-ish. See the 45K invocations of "deprecated" tools above. Treat your tool surface like a public SDK from day one.
Why this matters
The interesting AI work is not only in greenfield apps. It is also in the messy, load-bearing tools businesses already trust.
Excel is full of formulas, macros, queries, layouts, and conventions that nobody wants to rewrite. Some of that lives in the file. A lot of it only comes alive when Excel opens it.
Agents can finally work inside that environment. Not next to it. Not with a copy of it. Inside it.
That is the gap Excel MCP Server is trying to close, and the telemetry says people are walking through it faster than I thought.
Open source, MIT, Windows-only because Excel:
github.com/sbroenne/mcp-server-excel
If you are building MCP servers for other desktop apps, or you have war stories about COM, modal dialogs, or "we shipped a tool rename and broke 200 prompts" — I want to hear them.
Top comments (0)