Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@office-mcp make an Excel report with October sales, totals, and frozen headers"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server that turns JSON into real files. Excel, Word, CSV — no code
generation, no broken binaries, no openpyxl in your context window.
LLMs cannot reliably emit a valid .xlsx. They can write Python that sometimes
does, without formatting, formulas, column widths or multiple sheets — and they
burn 200 lines of context doing it. This server replaces that with one tool call:
15 lines of JSON in, a proper file out.
agent → make_xlsx({path, sheets}) → report.xlsx with styled headers, number
formats, frozen panes, autofilter and a =SUM total rowuvx --from git+https://github.com/xxxsonaaaaaa-maker/office-mcp office-mcpNo npm account, no PyPI, no build step. Python 3.10+.
Related MCP server: Excel MCP Server
Any MCP client (Claude Desktop, Cursor, Windsurf, Continue, custom):
{
"mcpServers": {
"office": {
"command": "uvx",
"args": ["--from", "git+https://github.com/xxxsonaaaaaa-maker/office-mcp", "office-mcp"]
}
}
}Tool | Output | Highlights |
|
| multiple sheets, column types ( |
|
| headings, paragraphs, bullets, tables with a real Word style |
|
| custom delimiter, UTF-8 BOM so Excel opens Cyrillic correctly |
{
"path": "out/report.xlsx",
"title": "October sales",
"sheets": [{
"name": "October",
"columns": [
{"header": "Item", "width": 28},
{"header": "Qty", "type": "number"},
{"header": "Price", "type": "money"},
{"header": "Total", "type": "money"}
],
"rows": [["Nails 90mm", 120, 12, 1440], ["Screws 4x50", 500, 3, 1500]],
"totals": true
}]
}Result: out/report.xlsx, styled header row, 1440 formatted as money,
=SUM(D4:D5) in the total row.
Relative paths only; .. is rejected — the server cannot write outside
its working directory.
Extension must match the tool (.xlsx, .docx, .csv), otherwise the
call fails with a readable message instead of writing a corrupt file.
Errors are returned as isError content with a human-readable reason, so
the agent can fix the arguments and retry instead of guessing.
Zero transport coupling. office_core.py is pure dict → bytes.
The MCP layer, a CLI or an HTTP API are thin wrappers over the same core.
No storage. Files are written locally; nothing is uploaded anywhere.
No magic. The server compiles a spec. It does not invent content, call an LLM, or require a key.
v0.1 — XLSX, DOCX, CSV. PPTX and PDF are next; see PLAN.md.
MIT
Создаёт CSV с настраиваемым разделителем и BOM (для корректного открытия в Excel с кириллицей). Для простых выгрузок, когда Excel не нужен.
| Name | Required | Description | Default |
|---|---|---|---|
| bom | No | ||
| path | Yes | ||
| rows | Yes | ||
| columns | No | ||
| delimiter | No | ; |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully explains why BOM matters (correct Cyrillic display in Excel) — context the schema's bare boolean does not provide — but says nothing about overwriting existing files at `path`, encoding, or failure behavior for a tool that writes to disk.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler; the core capability is front-loaded and the routing caveat comes last. Efficient, though the parenthetical is slightly dense.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter file-writing tool with no annotations, no output schema, and zero schema descriptions, the description covers too little — no overwrite/permission semantics, no return value, and three parameters entirely unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only addresses two of five parameters conceptually (delimiter, bom via "настраиваемым разделителем и BOM") and explains neither `columns` ordering semantics, `rows` shape, nor the expected `path` format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete verb and artifact ("Создаёт CSV") plus two distinguishing capabilities: configurable delimiter and BOM. The closing clause implicitly separates it from make_xlsx ("когда Excel не нужен"), though it never names the sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Для простых выгрузок, когда Excel не нужен" gives a usable when-to-use condition and an implied when-not (if you need Excel formatting, this is the wrong tool). The gap is that make_xlsx/make_docx are never named, so the agent must infer the alternative from the sibling list alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Создаёт документ Word (.docx): заголовки, абзацы, маркированные списки, таблицы. Используй для договоров, писем, ТЗ, отчётов и любых текстовых документов.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Куда сохранить, например dogovor.docx | |
| title | No | ||
| blocks | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. For a file-writing tool it never says whether an existing file at 'path' is overwritten, what errors or permissions apply, or what the return value is, leaving the mutation profile undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action followed by usage context, with no redundancy. 'и любых текстовых документов' is slightly padded but overall the entry is tight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and partial parameter coverage, the description covers what is produced and why, but omits the block-list structure contract, overwrite behavior, and return semantics needed to call a file-generation tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (only 'path' is documented), but the description compensates partly by naming the content kinds heads/paragraphs/bullet lists/tables, which map to the block 'type' enum values. The 'title' parameter and the table columns/rows structure remain unexplained in both places.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Создаёт документ Word (.docx)') and enumerates the content it can produce. The .docx format inherently distinguishes it from the make_xlsx and make_csv siblings, so an agent can route to it without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence gives concrete use cases (contracts, letters, technical specs, reports, any text document), which is clear positive guidance. It stops short of stating when not to use it or pointing to the spreadsheet siblings as alternatives for tabular output.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Создаёт настоящий Excel-файл (.xlsx) из JSON-описания: листы, колонки с шириной и типом (text/number/money/percent/float), строки, строка «Итого» с формулами SUM. Используй, когда пользователь просит таблицу, отчёт, смету или выгрузку в Excel.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Куда сохранить, например report.xlsx | |
| title | No | Заголовок над таблицей (необязательно) | |
| sheets | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses meaningful generated behavior (real .xlsx format, SUM formulas in a total row, column typing), which is genuinely useful context. However it says nothing about overwrite behavior at 'path', permissions, error cases, or return value, leaving notable gaps for a file-writing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste: capability first, routing condition second. Well front-loaded and appropriately sized. Not quite perfect in that the feature enumeration is a dense comma list, but it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter, single-output file generator with no output schema, the description covers what is produced, what the file format is, and when to invoke it. Missing only edge-case behavior (path overwrite, failures), which is minor given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, so the schema documents part of the surface (path, title, totals). The description reinforces this by naming type values (text/number/money/percent/float), column width, rows, and the 'Итого' SUM row, adding modest value. It does not explain the row-array shape or resolution of undocumented fields, so it stays at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Создаёт') and concrete resource ('настоящий Excel-файл (.xlsx)'), and enumerates the produced artifacts (sheets, columns, rows, total row). It implicitly distinguishes itself from make_csv/make_docx by naming the .xlsx output, but never explicitly references the siblings, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit trigger list: 'Используй, когда пользователь просит таблицу, отчёт, смету или выгрузку в Excel.' That is clear positive guidance for when to pick this tool. It offers no exclusions or named alternatives (make_csv/make_docx), so it is not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0make_csvmake_docxmake_xlsxScored across 3 tools
Each tool maps to a distinct output format (xlsx, docx, csv), and the descriptions explicitly differentiate use cases (e.g., make_csv is for simple exports when Excel isn't needed). The only mild overlap is between make_xlsx and make_csv for tabular data, but the guidance resolves it well.
All three tools follow a clean, predictable verb_noun pattern (make_xlsx, make_docx, make_csv) with consistent casing and format suffixes. There is no deviation or ambiguity in naming style.
Three tools is at the low end but each is well-defined and earns its place for document generation. For a broad 'office' scope one might expect a few more (e.g., pptx), so it's slightly under-scoped rather than excessive.
The surface covers creation for three common formats but is generation-only: there is no ability to read, parse, or edit existing files, and PowerPoint is absent. These notable gaps limit the server to one-way output workflows.
Turns agent output into versioned web pages, PDFs, Word docs, spreadsheets and Markdown.
Real .docx and .xlsx files from structured data, with automatic Hebrew/Arabic RTL.
Create, review and edit Word, PowerPoint, Excel and PDF documents from any AI agent.
Automate production-ready PDF, Word, Excel and PowerPoint documents from templates and JSON data
