Workfile MCP server

Read from the package source without running it. The installed server may list more.

• project_agent_context

  Build a compact context bundle around a card from direct relations, active conventions, open incidents and active project context. Prefer this over reading records one by one before working on a card.

• project_card_archive

  Move a closed card to the canonical archive directory. Only done and discarded cards can be archived; the ID and the file survive, so project_card_reopen undoes this.

• project_card_claim

  Claim a card for an actor, move it to doing and optionally declare the filesystem scope that will be changed. Claim before editing anything the card covers; another actor's claim is refused unless forced. Once the claim is written the card's verify entries run, and an entry whose verdict disagrees with the card — a criterion marked met that no longer holds, or one unchecked that already does — com

• project_card_createwrite action

  Create one canonical Work card with a concurrency-safe stable ID. Search first: this mints a new record rather than finding an existing one.

• project_card_list

  List cards filtered by status, area, type, priority, parent or claim. Use before starting work; use project_search for full-text.

• project_card_note

  Append one timestamped line under a heading. Cheaper than rewriting the body and safe when two agents write at once.

• project_card_patchwrite action

  Patch allowed card metadata using optimistic concurrency. Use expectedRevision whenever the card was read earlier.

• project_card_release

  Release your claim on a card and move it out of doing. Call when work stops, finished or not.

• project_card_reopen

  Move an archived card back out of the archive directory and into a live status. The ID never changes, so every existing reference to it keeps resolving.

• project_card_transition

  Move a card to another protocol status. Moving to doing claims the card for the actor; review means the implementation is finished but unverified, and done requires evidence it ran, not a commit.

• project_card_writewrite action

  Replace the Markdown body of a card under the protocol's lock and revision check. Use project_card_note to append instead.

• project_changelog_addwrite action

  Create an atomic unreleased changelog fragment and relate it to cards, decisions or other records. One fragment per user-visible change, written when the change lands rather than when the release is cut.

• project_changelog_list

  List unreleased change fragments and cut releases, filtered by type, area or visibility.

• project_changelog_patchwrite action

  Patch an unreleased changelog fragment using optimistic concurrency. Only works before a release consumes the fragment; afterwards the text belongs to that release.

• project_changelog_preview

  Render selected unreleased fragments without mutating the repository. Use to read a release before project_changelog_release makes it permanent.

• project_changelog_release

  Consume selected unreleased fragments and create a canonical release record. This moves fragment files into the release directory, so preview first: the fragments stop being separately editable.

• project_doc_createwrite action

  Create a managed Markdown document with a stable DOC ID. Without an explicit folder the workspace docs.layout decides where it is written.

• project_doc_list

  List indexed and managed documents, filtered by kind, status or freshness.

• project_doc_move

  Move a managed document to another folder below the managed docs root. The DOC ID never changes; use an empty folder for the root.

• project_doc_note

  Append one timestamped line under a heading of a managed document, creating the heading if needed. Cheaper than rewriting the body and safe when two agents write at once.

• project_doc_patchwrite action

  Patch a managed document using optimistic concurrency. Indexed repository docs are intentionally read-only through this tool — edit those files directly.

• project_doc_writewrite action

  Replace the Markdown body of a managed document under the protocol's lock and revision check, leaving its frontmatter as it is. Use project_doc_note to append instead.

• project_doctor

  Validate Work, Docs, History, Memory, agent instructions, CI templates and cross-record references. Run before declaring work finished.

• project_get_record

  Read one canonical project record by stable ID, including body, revision, outgoing references, backlinks and health signals. The revision it returns is what a later write passes as expectedRevision.

• project_memory_addwrite action

  Create a typed learning, decision, incident, convention or temporary context record. For knowledge that should change future behaviour — not for narrating what happened this session.

• project_memory_graduate

  Mark a learning as graduated and link it to the convention, decision or documentation that now carries the durable rule. Create the target record first — graduating points at something that must already exist.

• project_memory_list

  List learnings, decisions, incidents, conventions and context, filtered by collection or lifecycle status.

• project_memory_patchwrite action

  Patch a durable memory record using optimistic concurrency. To retire one in favour of another use project_memory_supersede, which updates both sides.

• project_memory_supersede

  Supersede one memory record with another and update both sides atomically. Create the replacement first; neither record is deleted, so the superseded one stays readable and its ID keeps resolving.

• project_next

  Rank actionable cards: unblocked, unclaimed or claimed by you, highest priority first. Answers "what should I do now".

• project_search

  Search cards, documentation, changelog entries, releases and durable memory. Uses deterministic lexical ranking and an injected semantic provider when available.

• project_workspace

  Return the effective Workfile workspace, schema, enabled modules and mutation mode. Read this first when a vocabulary is project-declared: it reports the areas, axes, document kinds, changelog types and memory collections this project accepts, and under cards.verification which verification methods each area accepts at done.

• Code scan184 source files scanned25/25
• –Live reliabilityno gateway calls yet and no remote to proben/a
• –Tool poisoningtools not inspected (local package is not executed); not countedn/a
• Auth qualitylocal package, no credentials required12/15
• Maintenancelast push 2 days ago15/15
• Maintainer identityregistry namespace matches repository owner; GitHub account older than a year8/10

Safety score

92/100

higher than 90% of 1,299 Productivity servers

Tools

32

the typical Productivity server has 7

Tools that change things

31%

typical: 0%. Fewer write tools means less an agent can break

GitHub stars

3

more than 65% of 854 Productivity servers

Downloads a week

663

more than 87% of 427 Productivity servers with a package

Workfile: common questions

Is Workfile MCP server safe?

Yes, by our scan: it is graded A (92/100). Read the Workfile safety report

How do I install Workfile?

It runs on your machine. Copy the Claude Code, Cursor, VS Code or Claude Desktop config from the install section.

Does Workfile need an API key?

Not as far as the registry entry and our scan can tell: no credentials are declared or required.

Is Workfile maintained?

The last commit was 33 days ago (2026-10-01). The latest release is v0.13.2.

What can I use instead of Workfile?

Servers from other publishers that do the same job: Agent-Native Dispatch MCP server, loci MCP server and Obsidian Turbocharged MCP server. Compare all Workfile alternatives.

How does Workfile compare with other Productivity MCP servers?

safety score 92/100 (higher than 90% of 1,299 Productivity servers); tools 32 (the typical Productivity server has 7); tools that change things 31% (typical: 0%. Fewer write tools means less an agent can break). Full comparison.