Eu dei Excel real para agentes de IA. Eles não usaram como eu esperava - Comprovado por 90 dias de telemetria.

90 dias de telemetria de um servidor MCP de código aberto que controla o aplicativo desktop Excel real. Os números não estavam onde eu pensei que estariam.

Há seis meses, fiz uma pergunta simples: por que os agentes de IA conseguem escrever um aplicativo React do zero, mas têm dificuldades com Revenue Model v27 final final.xlsx?

A resposta acabou sendo chata e importante.

Os agentes tinham bibliotecas de planilhas. Eles não tinham Excel.

Então, eu construí um Servidor MCP Excel: um servidor MCP de código aberto que controla o aplicativo desktop Excel real através da automação COM. Não é um .xlsx parser. Não é Open XML. O aplicativo real, com seu motor de cálculo, VBA, Power Query, caches de tabela dinâmica e todas as peculiaridades que fazem uma pasta de trabalho ser uma pasta de trabalho.

O problema do "basta usar openpyxl"

Toda vez que falo sobre isso, alguém diz "por que não usar uma biblioteca de Excel baseada em arquivos?"

Para gerar um .xlsx a partir de um servidor, essas bibliotecas são ótimas. Contêineres Linux, sem instalação do Office, rápidas.

Elas não são Excel.

Elas não executam o motor de cálculo do Excel. Elas não executam VBA. Elas não atualizam o Power Query. Elas não tocam o modelo de objeto COM. Elas não podem te dizer se o relatório parece certo.

Para gerar planilhas, isso é aceitável. Para automatizar pastas de trabalho que já executam um negócio, é a diferença entre "eu editei um arquivo que o Excel pode abrir" e "eu trabalhei dentro do Excel."

O Servidor MCP Excel é para o segundo caso. A pasta de trabalho é tratada como um aplicativo, não como um zip de XML.

A arquitetura, em um diagrama

Assistente de IA
  -> Protocolo MCP
  -> Servidor MCP Excel  (MCP em processo, ou daemon CLI de pipe nomeado)
  -> Automação COM do Excel
  -> Excel.exe real com a pasta de trabalho aberta

A última linha é toda a tese. 90 dias depois, eu tenho telemetria. Os números me disseram coisas que eu não esperava.

O que eu esperava vs o que 90 dias de telemetria mostraram

90 dias, anônimos, opt-in: 2.908 usuários, 86.090 sessões, 488.548 invocações de ferramentas.

O crescimento foi mais acentuado do que eu esperava. Usuários semanais foram de 84 para 1.209. Sessões semanais de 310 para 11.769. Fevereiro: 800 usuários mensais. Março: 1.682. Abril estava a caminho de ultrapassar 2.000 antes do final do mês.

Ok. Gráficos de crescimento são legais. Aqui está a parte que realmente me surpreendeu.

Surpresa 1: os agentes se importam com como a pasta de trabalho parece

7.700+ operações de captura de tela. Além de 1.144 chamadas para organizar janelas do Excel, mais 1.875 mensagens na barra de status.

Eu construí a captura de tela como um recurso de depuração. Usuários e agentes estão usando isso como parte do processo. Eles renderizam a planilha, olham para ela e decidem o que fazer a seguir.

Se seu alvo de automação é um aplicativo visual, sua superfície de ferramenta precisa de feedback visual. Sem cabeça nem sempre é a resposta.

Surpresa 2: VBA está extremamente longe de estar morto

20.000+ operações de VBA de 500+ usuários.

Não é nostalgia. É a realidade empresarial. Existem empresas que realizam seu fechamento mensal com uma macro que um gerente financeiro escreveu em 2014. Se seu agente não pode ler, editar, importar ou executar VBA, ele não pode tocar em nada disso.

Ferramentas modernas de IA precisam encontrar a automação legada onde ela vive. Macros incluídas.

Surpresa 3: as pessoas não estão usando isso para "ler a célula A1"

O usuário mediano dispara 65 invocações de ferramentas. O percentil 95 dispara 1.000+. O 99 dispara 3.000+. O usuário anônimo mais ativo disparou 10.060.

Isso não é uma demonstração. Isso é alguém com um agente no processo de trabalho real.

E o trabalho em si é mais pesado do que eu supunha: 25K+ operações de Power Query, conexões e Modelo de Dados. As pessoas estão usando isso para inspecionar o código M, atualizar consultas e explorar modelos DAX. Excel como um ambiente de BI local, impulsionado por um LLM.

Surpresa 4: apresentação é metade do trabalho

~68K operações de formatação e apresentação. Formatos numéricos, larguras de coluna, células mescladas, formatação condicional.

Muitas tarefas do Excel não terminam em "os dados estão corretos." Elas terminam em "a pasta de trabalho está pronta para ser enviada." Para os agentes, o polimento é parte do fluxo de trabalho, não um recurso desejável.

Surpresa bônus: ninguém deixa ferramentas antigas morrerem

Depois que lancei ferramentas mais limpas e focadas no domínio, as ferramentas legadas excel_* ainda geraram 45.507 invocações de 214 usuários.

Uma vez que um cliente LLM ou prompt depende de um nome de ferramenta, esse nome é essencial. Renomeações são mudanças drásticas. As superfícies de ferramentas MCP são APIs e envelhecem como APIs.

O que o histórico do GitHub disse

Eu também passei pelo repositório completo: 197 problemas, 417 PRs, 382 mesclados, 3 problemas abertos.

Eu esperava que a maioria fosse "por favor, adicione um wrapper para X." Não era. Os temas recorrentes:

• 168 problemas sobre estabilidade do COM, travamentos, limpeza, peculiaridades do Click-to-Run
• 147 problemas sobre testes, CI, regressão, testes de fumaça
• 138 problemas sobre comportamento do MCP, esquemas, definições de ferramentas
• 104 problemas sobre CLI, daemon, pipes nomeados, empacotamento
• 91 problemas sobre Power Query, Modelo de Dados, DAX
• 27 problemas sobre VBA

O problema mais comentado na história do projeto é "criar tabelas do Excel programaticamente." Isso pode parecer chato até você perceber o quanto a utilidade do agente colapsa se você não puder transformar um intervalo solto em um objeto de tabela estruturada.

A parte difícil deste projeto nunca foi expor as APIs do Excel. A parte difícil foi sobreviver ao threading STA, diálogos modais, bloqueios de pastas de trabalho, corridas de inicialização de daemon, deriva de esquema e a diferença entre instalações do Office Click-to-Run e MSI em uma terça-feira.

Esse caminho estranho é exatamente o que bibliotecas baseadas em arquivos ignoram, e exatamente onde os usuários reais vivem.

Três coisas que eu diria a qualquer um que esteja construindo um servidor MCP

1. Nomes de ferramentas são a intenção do usuário, não mecânica da API. format-range, refresh, create-pivottable, capture-sheet. Cada um remove um passo de tradução que o modelo teria que inventar. Algumas ferramentas bem nomeadas do domínio superam dezenas de primitivos genéricos.

2. O estado é o jogo todo. Pastas de trabalho têm estado. O Excel tem estado. O modo de cálculo tem estado. O COM tem estado. Um servidor MCP para um aplicativo desktop com estado não é um wrapper HTTP sem estado com transporte mais sofisticado. Sessões são o produto.

3. Uma vez que uma ferramenta é lançada, o nome é permanente-ish. Veja as 45K invocações de ferramentas "deprecadas" acima. Trate sua superfície de ferramenta como um SDK público desde o primeiro dia.

Por que isso importa

O trabalho interessante de IA não está apenas em aplicativos novos. Também está nas ferramentas bagunçadas e essenciais que os negócios já confiam.

O Excel está cheio de fórmulas, macros, consultas, layouts e convenções que ninguém quer reescrever. Parte disso vive no arquivo. Muito disso só ganha vida quando o Excel o abre.

Agentes podem finalmente trabalhar dentro desse ambiente. Não ao lado dele. Não com uma cópia dele. Dentro dele.

Essa é a lacuna que o Servidor MCP Excel está tentando fechar, e a telemetria diz que as pessoas estão atravessando-a mais rápido do que eu pensei.

Código aberto, MIT, apenas para Windows porque Excel:
github.com/sbroenne/mcp-server-excel