Mcp Ooxml Ledger

io.github.Anselmoo由 GitHub 账号 Anselmoo 发布v0.3.0更新于 Oct 24, 2026

Edit Office documents and prove no edit went unrecorded

概览

AI 生成的概览

一个 MCP 服务器,用于编辑 Word 和 PowerPoint 文档,记录每一次更改,并拒绝提交无法解释的编辑。

可以做什么
它在会话中打开 Office 文档,并提供读取工具(describe_structure、find_text)、编辑工具(preview_edits、apply_edits、delete_paragraph、insert_paragraph)以及封存工具(commit_document)。封存前,它会根据文档基线重放所有已记录的操作,并将结果与磁盘上的内容进行比较;如果存在无法解释的更改,提交会被拒绝。它还提供无状态验证工具(digest、verify、list_receipts、export_receipt)以及用于聊天客户端的传输工具(import_document、export_document)。
适用场景
当助手需要修改 Word 或 PowerPoint 文件,并且你希望有可审计的记录来证明没有编辑未被记录时,可以使用它。它适用于问责制重要的文档编辑工作流,例如在 CI 或提交前钩子中让无法解释的更改导致构建失败。
运行要求
作为本地 stdio 进程运行;需要 PATH 中有 uv。文档根目录通过 OOXML_LEDGER_ROOTS 设置(以 os.pathsep 分隔的列表);如果未设置,则默认为服务器的工作目录。可选的 OOXML_LEDGER_READ_ONLY=1 会限制为只读工具,OOXML_LEDGER_IMPORT_MAX_BYTES 设置导入大小上限(默认 25 MiB)。.mcpb 桌面捆绑包仅在 macOS/arm64 上构建并验证,首次启动需要网络访问以从 PyPI 解析固定依赖。
安装前请注意
该服务器会写入文档以及配置根目录内的回执文件,因此请将 OOXML_LEDGER_ROOTS 作为安全边界谨慎设置。导入的文档只会写入 _inbox/,并且从不覆盖现有文件。未签名的回执只能证明意外,不能防篡改:它无法防止有人在改写文档的同时改写回执。v0.3.0 验证器会按设计拒绝 ooxml-ledger/2 回执,并且 verify 从不重放操作。

安装

在 SourceWeft 中

  1. 打开 控制台中的 Mcp Ooxml Ledger,将其添加到工作区。
  2. 为需要使用其工具的对话启用该服务。

Desktop only,通过 STDIO。 STDIO 服务会启动本地进程,因此需要 SourceWeft 桌面宿主。

其他 MCP 客户端

参照 仓库 中的启动说明。

README

mcp-ooxml-ledger

[CI] [codecov] [PyPI] [TestPyPI] [Python] [License: MIT] [MCP]

An MCP server that edits Office documents and refuses to write one where an edit went unrecorded.

Before sealing a session it replays every recorded operation against the document's baseline and compares the result to what is actually on disk. A change no operation explains means the commit is refused. Of ~18 competing MCP document-editing projects, none gates the write on that check. The refusal is the product.

Setup

bash
uv add mcp-ooxml-ledger

Add to .mcp.json (project) or claude_desktop_config.json (desktop — use an absolute path, ${CLAUDE_PROJECT_DIR} isn't expanded there):

json
{  "mcpServers": {    "ooxml-ledger": {      "command": "uv",      "args": ["run", "--project", "${CLAUDE_PROJECT_DIR}", "ooxml-ledger-mcp"],      "env": { "OOXML_LEDGER_ROOTS": "${CLAUDE_PROJECT_DIR}" }    }  }}

Needs uv on PATH; nothing else installed globally. Invoking the ooxml-ledger-mcp script directly gives ENOENT — it lives in the project venv, not your shell's PATH.

OOXML_LEDGER_ROOTS is the security boundary. An os.pathsep-separated list; every path any tool receives is resolved inside it and refused outside. Unset, it defaults to the server's working directory — set it deliberately, since export_receipt writes anywhere inside a root.

Tools

Tool
sessionopen_document · close_documentwrites
readdescribe_structure · find_textread-only
editpreview_edits · apply_edits · delete_paragraph · insert_paragraphwrites
sealcommit_documentwrites · enforces the gate
statelessserver_info · digest · verify · list_receiptsread-only
export_receiptwrites
transferimport_documentwrites — into _inbox/ only
export_documentread-only

Typical loop:

open_document → find_text → preview_edits → apply_edits → commit_document → verify
python
sid = open_document(document="report.docx")["session_id"]find_text(sid, query="Q3 revenue")                     # → part, para_id, para_hashpreview_edits(sid, edits=[...], author="alice")        # → what WOULD happen; writes nothingapply_edits(sid, edits=[...], author="alice", mode="tracked")commit_document(sid)                                   # → refuses if anything is unaccounted forverify("report.docx")                                  # → verified | unknown | failed

preview_edits runs the same engine function as apply_edits against a throwaway copy, so the two cannot disagree. Batches are all-or-nothing: a failing edit leaves the document byte-identical.

mode="tracked" emits Word revision marks a reviewer sees in the document. mode="direct" rewrites the text with none — still fully recorded, and the receipt discloses that a direct edit touched a revision-capable part, so it is never silently indistinguishable from an ordinary save.

Chat and hosted clients

A file uploaded into a chat lives in the client's sandbox, not on the server's filesystem, so open_document correctly refuses its path. Widening OOXML_LEDGER_ROOTS cannot reach it. Send the bytes instead:

import_document → open_document → … → commit_document → export_document
python
p = import_document(name="report.docx", content_base64="UEsDB…")["path"]  # → <root>/_inbox/report.docxsid = open_document(document=p)["session_id"]...                                                    # edit as usualcommit_document(sid)                                   # → receipt schema ooxml-ledger/2export_document(document=p)                            # → file + receipt as embedded resources
  • Where it lands. import_document takes a bare filename and writes _inbox/<name> under the first root. It never overwrites an existing file, and it validates the bytes as a real Office package before anything is published.
  • Large files. A model has to emit the base64 itself, so a single call carries far less than the cap. Send chunks: final=false returns an upload_id; continue with it and offset (the bytes received so far); the final=true call must carry the sha256 of the whole file. A lost or repeated chunk is a refusal, never a different document.
  • Size cap. OOXML_LEDGER_IMPORT_MAX_BYTES sets the largest document either tool accepts, in decoded bytes. The default is 25 MiB.
  • Provenance. An imported document's first bytes on this host came from a tool call, not from the user's filesystem. Every receipt in that lineage is therefore sealed as ooxml-ledger/2, with a chain-bound provenance block (docs/superpowers/specs/receipt-format-v2.md). verify prints it as a PROVENANCE line, and it never changes the verdict. Receipts for every other document stay ooxml-ledger/1, byte-identical to before.
  • Getting it back. export_document returns the file as an MCP embedded resource, with its Office media type and the receipt alongside. By default it refuses a document that no stored receipt matches, so an unsealed edit is never handed out; pass require_receipt=false to override.

Format matrix

FormatVerifyEdit
Word .docxYesYes — tracked + direct, paragraph insert/delete
PowerPoint .pptxYesDirect only — PresentationML has no revision model, so every edit carries a mandatory disclosure
Excel .xlsxYesNo — editing verbs refuse, naming the format

Verification, digests, the gate and the receipt model are format-agnostic. Only the editing engines are format-specific: wml.py (Word) and pml.py (PowerPoint).

Read-only deployment

OOXML_LEDGER_READ_ONLY=1 leaves exactly server_info, digest, verify, list_receipts, export_document. The others aren't merely hidden — calling one answers Unknown tool. No write surface inside the roots at all.

CLI

bash
ooxml-ledger verify report.docx    # exit 0 only when verified

No server, no session — digests the file, finds its receipt by content address, checks it. Wire it into CI or a pre-commit hook and an unaccounted-for change fails the build.

Desktop bundle (.mcpb)

Every GitHub Release attaches a .mcpb file — a one-click Claude Desktop install: drag it onto the app and Desktop launches it with uv run --directory <bundle> --frozen --no-dev ooxml-ledger-mcp. Nothing is vendored — the bundle carries only manifest.json, pyproject.toml, uv.lock, README.md, LICENSE and src/. The host needs uv on PATH, and the first launch resolves the exact dependency versions uv.lock pins from PyPI, which needs network access; --frozen means it installs precisely the versions the test suite ran against, never a fresh resolve, and --no-dev keeps the dev group (pytest, ruff, pre-commit) out of the install. mcpb/manifest.json exposes the document root and read-only toggle as install-time settings instead of environment variables; the tool list matches the stdio server's.

CI builds and smoke-tests the bundle on macos-latest only, and the manifest's compatibility.platforms declares darwin only — the bundle is built and proven on macOS/arm64, nothing else. Because nothing is vendored, uv itself picks a Python satisfying requires-python = ">=3.13" and installs the wheels uv.lock pins for the host's own platform — native ones such as pydantic-core and cryptography included. That part is not darwin-specific, but only the darwin launch path has actually been proven end-to-end here.

Honest limits

  • An unsigned receipt is accident-evident, not tamper-evident. It catches an agent falling back to a generic file write, an Office round-trip, a careless collaborator — not someone who rewrites the receipt alongside the document. Anchoring its hash somewhere the holder doesn't control (a git commit, a DOI, a submission portal) is what buys tamper-evidence.
  • Imported provenance lives beside _inbox/. The import record sits in the store next to the imported file. Moving that file out of _inbox/ before its first commit drops the record, so the first receipt is written as v1. After a commit, the lineage travels with the receipts store. Provenance records what arrived, not that it matches the user's original upload: compare its sha256 out of band if that matters.
  • A v0.3.0 verifier rejects ooxml-ledger/2. This is by design. It cannot check the genesis rule, so refusing is better than silently accepting a chain it does not understand.
  • verify never replays. It checks the digest and the receipt's internal consistency; the replay runs once, at commit, and verify reports that verdict rather than recomputing it.
  • pptx and xlsx have no human-visible record. Word tracked changes are a second recording layer inside the document; those two formats have none, so the ledger is the only record.
  • The Word engine reaches paragraph text only (w:p/w:r/w:t). Styles, numbering, settings and relationships are uneditable and covered by the accountability check alone.

Contributing and security

CONTRIBUTING.md covers setup, the branch and commit naming CI enforces, and the release flow. SECURITY.md covers private vulnerability reporting, and is explicit about which of this project's documented limits are design rather than defects.

MIT licensed. Design notes and specifications live in docs/superpowers/.

来源:README.md,提交 e5eac71

工具

0
SourceWeft 尚未在沙箱中启动过该软件包,因此其工具未知。

版本历史

1
  1. v0.3.0最新Sep 16, 2026

评分

已满足适用检查项的 50%

该评分衡量此收录条目的完整程度,依据注册中心条目、端点与公开来源计算得出。它不是对服务器本身的评价,也不表示服务器安全或当前可用:可连通性是带日期的检查结果,评分也不包含安装量或用户评价。

  • 近 30 天内可连通25 分

    请保持端点能够响应 MCP 握手;SourceWeft 每 30 天探测一次。

  • 已声明认证方式10 分

    请在注册中心条目中声明凭据请求头,或保持端点能够响应探测,以便判定其认证方式。

  • 已列出工具15 分

    请让服务器在无凭据时响应 tools/list,或发布可在沙箱中无凭据启动的软件包。

  • 描述必需15 分
  • 图标10 分
  • 文档15 分
  • 许可证10 分