AI-native CLI + MCP server for creating, reading, editing, rendering and validating real Office documents (.docx/.xlsx/.pptx). Installs a single self-contained native binary downloaded and SHA256-verified from the GitHub release.
AIOffice demonstrates strong schema completeness and detailed parameter documentation across 19 tools. Tool names follow verb_noun conventions (office_create, office_read, office_edit). Descriptions are comprehensive (100-400+ chars), exceeding the 10-1024 baseline. Input schemas are fully specified with types, enums, and constraints. However, output schemas are not explicitly documented in the visible code, responses are inferred from descriptions. Error handling guidance is minimal; most tools lack recovery hints. Tool composition is excellent (single responsibility, chainable IDs), but descriptions could be more LLM-optimized by stating WHEN to use each tool vs. alternatives.
List, restore, or manage file snapshots (auto-created before edits, manual checkpoints).
Audit document for compliance, accessibility, performance, and best practices; returns structured findings.
Convert a document to another format (.docx ↔ .xlsx ↔ .pptx, or to/from markdown/csv).
Create a blank .docx/.xlsx/.pptx inside the workspace (kind inferred from the extension), or import one via 'from' (markdown→docx, csv→xlsx).
Compare two documents or revisions; returns a structured diff with paths and change types.
ALL mutations: apply an atomic batch of set/add/remove/move/replace/accept/reject/extract ops — all-or-nothing single save, auto-snapshot, optional rev guard.
Output schemas not explicitly documented. Tool descriptions infer return structure but do not formally specify response fields, types, or pagination. LLMs cannot reliably plan downstream calls without knowing what fields to extract.
Error handling lacks recovery guidance. Tools do not document what errors are retryable, what the LLM should do on failure, or how to self-correct. E.g., office_query with invalid selector returns no guidance on valid selector syntax.
Descriptions for office_validate, office_audit, office_status, office_schema are generic and lack WHEN-to-use context. They do not explain when to call validate vs. audit, or how they differ from office_read with 'structure' view.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
Read one node and its properties by canonical path (inspect before editing).
Get help on selectors, addressing, formulas, element types, and other topics.
Find elements with a CSS-like selector; returns canonical paths for office_get/office_edit.
Read a document: outline, plain text, stats or full structure tree. First step to understand a file.
Render the document (or a subtree) to an inspectable artifact — the look step of render→look→fix. png also returns the image inline.
Return the complete MCP tool schema surface (all tools, properties, enums) as a single JSON document.
Report server status, workspace root, and available handlers.
Extract or apply a template; templates are reusable document structures with placeholders.
Validate document structure, schemas, and constraints; returns a list of issues with paths and suggestions.
Scroll the live preview to a specific element path.
Add a visual mark (highlight, note, flag) to an element in the live preview.
Open a live preview server for a document; spawns a detached HTTP server, waits for startup, returns the URL.
Read the human's click selection from the live preview (paths and metadata).
office_edit's 'ops' parameter is a complex nested array with 8 operation types and conditional properties. Description references external help topics (office_help {topic:...}) rather than inline constraints. LLMs may struggle to construct valid ops without trial-and-error.
preview_* tools spawn detached HTTP servers but do not document timeout behavior, port allocation strategy, or cleanup on agent crash. If an agent crashes, preview servers may leak and accumulate.