v0.2.3 — description mentions restoring

The server is unchanged — nothing under src/ differs from 0.2.2. This release exists to get the corrected description onto the npm page, which renders it from the published tarball rather than from the repository.

Changed

• The one-line description now mentions restoring. It previously listed classify, archive, and compact, so a reader of the npm page or repository header could not tell the server can undo an archive. md_restore_files has existed since 0.2.0.

Internal

• Trusted publishing works. registry-url on actions/setup-node was writing an .npmrc containing _authToken=${NODE_AUTH_TOKEN}; with no token configured, npm read that empty value as configured credentials and never attempted the OIDC exchange. See actions/setup-node#1551.
• The publish workflow now checks out the release tag explicitly, so a provenance attestation always points at the commit the release claims to ship rather than at a branch head.
• Added a diagnostics step to the publish workflow. npm reports every trusted-publishing misconfiguration as a 404 or ENEEDAUTH, indistinguishable from a missing package or a forgotten login (npm/cli#9088).

Full changelog: v0.2.2...v0.2.3

v0.2.2 — first CI-published release

No change to the server itself — nothing under src/ differs from 0.2.1, so behavior is identical.

This is the first release published from CI, and therefore the first carrying a provenance attestation linking the published tarball to the commit it was built from. That verifiable build origin is the only reason to prefer it over 0.2.1.

Patch rather than minor deliberately: no functionality was added. The release tooling behind this version does not ship — scripts/ and .github/ are outside the npm tarball — so a minor bump would advertise features that do not exist.

Internal

• Publishing moved to GitHub Actions via npm trusted publishing. Cutting a release is now the only publish step; the workflow exchanges a short-lived OIDC token for publish rights, so no npm token exists anywhere and no 2FA prompt interrupts a release.
• check:version accepts --tag, asserting a release tag matches package.json before anything reaches npm. A published version can never be reused.

Full changelog: v0.2.1...v0.2.2

v0.2.1 — release tooling

No functional change for users. The published package is identical to 0.2.0 apart from the version it reports. Adds check:version to the test suite, asserting package.json, SERVER_VERSION, and the changelog agree before a release. Full changelog: v0.2.0...v0.2.1

v0.2.0 — restore files from the archive

Adds the undo half of archiving.

Added

md_restore_files — moves files back out of .archiveMD/ to where they came from, using the manifest. A file can be named by either the path it was archived to or the path it came from; both resolve to the same entry.

"restore docs/plans/billing-rework.md"
".archiveMD/docs/plans/billing-rework.md"   # equivalent

Three behaviors worth knowing:

• Called with no paths, it lists rather than restores. Defaulting a malformed call to "restore everything" would be the worst possible failure mode for an undo tool. The listing shows each archived file's original path, why it was archived, when, and whether something now occupies its old location.
• A file already at the original path is never overwritten. The restore is skipped by default; pass on_conflict: "suffix" to bring the archived copy back alongside the current one.
• Files moved into .archiveMD/ by hand still restore. Without a manifest entry, the original location is derived by stripping the archive prefix.

Restores append to the manifest too, so the audit trail records both directions.

Changed

Manifest entries now carry event ("archive" or "restore") and a canonical at timestamp. Reading is backward compatible — entries written by 0.1.0 have no event and are treated as archives.

Shared move helpers moved to src/lib/move.ts so archive and restore cannot drift on collision handling or the no-copy-then-delete rule.

Known limitation

Empty directories are left behind in .archiveMD/ after a restore. Removing them would require a delete call, and the no-delete guarantee is worth more than the tidiness.

Updating

The server is a subprocess your MCP client spawns at startup, so restart the client to pick this up. With the npx install, that is all you need.

Full changelog: v0.1.0...v0.2.0

v0.1.0 — initial public release

Initial public release.

An MCP server for maintaining a markdown knowledge base: classify plans, archive completed docs into a .archiveMD/ recycle bin, and compact noisy files.

Install

claude mcp add --scope user markdown-archive -- npx -y markdown-archive-mcp

Tools

Five tools over stdio, each taking an absolute root_path so one registration serves any markdown repository.

Tool	Writes?	Purpose
md_list_repo	no	List .md files with size, last-touched date, heading count
md_analyze_plans	no	Classify as ACTIVE / COMPLETED / STALE / UNKNOWN with evidence
md_archive_files	moves	Move explicit paths into .archiveMD/, recording each move
md_compact_file	no	Return a compacted version without writing it
md_update_file	yes	Write a change and report a diff summary

It never deletes

Archiving is a move. Collisions get a timestamp suffix rather than an overwrite, every move is appended to a manifest, and scripts/check-no-delete.mjs fails the build if a delete call appears anywhere in src/.

Paths are contained against root_path both lexically and after following symlinks. Archiving takes explicit paths only — never globs — and refuses batches over 25.

Conservative by design

Absence of evidence yields UNKNOWN, never COMPLETED. Conflicting evidence yields low confidence. Age alone never proposes an archive — an early build ignored that and proposed archiving 65 of 67 files in a healthy reference-doc tree.

Full notes in CHANGELOG.md.