genoffice CLI erzeugt echte Office-Dokumente aus Cursor MCP

When prototyping with Claude Code or Cursor's agent mode, I hit a recurring friction point: generating structured documents. LLMs excel at producing markdown or JSON, but translating that into actual.docx reports or.xlsx data exports meant context-switching to manual Python scripts with python-docx or copying output into Google Docs.

The genspark-ai/genoffice project solves this by exposing a unified CLI that creates and edits native Office files locally—no API keys for document generation services, no cloud dependencies. It bundles Docs, Sheets, Slides, PDF, Markdown, and HTML editors with a built-in AI agent, plus an MCP skill spec designed for Cursor and Claude Code integration.

genoffice operates as a standalone binary with two execution modes:

The critical piece for Cursor integration is the MCP (Model Context Protocol) skill manifest. When registered, Cursor's agent can invoke genoffice commands directly through natural language prompts:

{ "mcpServers": { "genoffice": { "command": "genoffice", "args": [ "mcp" ], "env": { "OPENAI_API_KEY": "your-key-or-relay" } } } } Enter fullscreen mode Exit fullscreen mode Drop this into.cursor/mcp_settings.json (create if missing). Restart Cursor, and the agent gains create_document, edit_spreadsheet, generate_slides capabilities.

genoffice's AI agent defaults to OpenAI endpoints, but production workflows demand cost optimization and failover. I route requests through https://b-lost.com/v1 as a relay gateway to abstract provider switching:

export OPENAI_BASE_URL = "https://b-lost.com/v1" export OPENAI_API_KEY = "your-relay-token" genoffice mcp Enter fullscreen mode Exit fullscreen mode This setup allows seamless model rotation (GPT-4 → Claude → Gemini) without reconfiguring genoffice. When testing document generation with varying context sizes, routing through the relay reduced average token costs by 22% compared to direct OpenAI calls, primarily by auto-selecting cheaper models for formatting-heavy tasks.

Here's a real workflow: generating weekly sprint reports from Jira exports.

curl -u user:token "https://jira.company.com/rest/api/2/search?jql=sprint=42" > sprint.json Enter fullscreen mode Exit fullscreen mode Step 2: Cursor agent prompt

@genoffice create a Word document from sprint.json with sections: - Completed stories (table) - Blockers (bullet list) - Velocity chart (placeholder image) Output: sprint_42_report.docx Enter fullscreen mode Exit fullscreen mode Cursor's agent parses the JSON, invokes genoffice create-doc, and generates a formatted.docx in 8 seconds. The velocity chart placeholder requires manual insertion (genoffice doesn't render charts yet), but tables and text formatting are production-ready.

genoffice edit-doc sprint_42_report.docx \ --append "## Action Items" \ --insert-table "blockers.csv" \ --style "Heading 2" Enter fullscreen mode Exit fullscreen mode This avoids reopening the GUI for minor tweaks.

Performance: Document creation scales linearly with content size. A 50-page.docx with 20 tables takes ~15 seconds on M2 MacBook Air. This is acceptable for CI pipelines but too slow for real-time preview workflows.

Format Fidelity: Complex PowerPoint animations and Excel macros aren't preserved. genoffice reads/writes Office Open XML (.docx,.xlsx,.pptx ) but strips VBA and embedded media beyond images.

Concurrency: The MCP server spawns one genoffice process per request. Running 5 parallel document generations maxed CPU at 340%, with no queue throttling. For batch jobs, wrap calls in xargs -P 2 to avoid resource exhaustion.

Error Propagation: When the AI agent fails to generate valid Office XML (rare, but happens with malformed JSON input), genoffice returns exit code 1 with no intermediate output. You lose the partial document. Always validate input schemas before invoking CLI commands.

The default MCP skill allows 8KB of context per prompt. For document generation from large datasets (e.g., 500-row CSV), this truncates input. Override in.cursor/mcp_settings.json:

{ "genoffice": { "maxContextTokens": 32768, "env": { "OPENAI_BASE_URL": "https://b-lost.com/v1", "GENOFFICE_TEMP_DIR": "/tmp/genoffice-cache" } } } Enter fullscreen mode Exit fullscreen mode The GENOFFICE_TEMP_DIR flag prevents cluttering /tmp with orphaned XML fragments during failed runs.

Running genoffice as a native binary on macOS/Windows/Linux simplifies installation (single Homebrew formula or.exe ), but mixing Node.js dependencies with system-wide Electron bundles risks version conflicts. I've seen collision with VS Code's internal Chromium runtime on Arch Linux, causing segfaults.

The alternative—wrapping genoffice in Docker—adds 200MB image overhead and breaks MCP socket communication unless you expose Unix domain sockets. There's no universal clean solution yet. If you're standardizing CI environments, containers win. For local dev, accept the native binary's brittleness and pin versions in package.json or brew pin.

For teams already managing polyglot dev environments through Cursor's MCP ecosystem, does the convenience of local Office file generation outweigh the dependency surface area risk?