Petrichor

Petrichor keeps tasks, a knowledge base and AI agent memory in one Drupal site, with a built-in MCP server so AI assistants can read and update your work directly instead of through a bolted-on API.

Features

Petrichor is a suite: a small base module plus ten submodules that each own one entity type. Enable only what you need.

• Projects, tasks and milestones as real content entities — so Views, Field UI and your own custom fields all work, without writing code.
• A markdown knowledge base with hierarchical pages, [[Wiki Links]] and automatic backlinks. Links to pages that do not exist yet are kept and shown, because a page you have already linked to is a to-do.
• Full revision history on wiki pages: who saved each version, when, and the log message they left.
• A drag-and-drop kanban board built on core/sortable, which already ships with Drupal. No npm, no build step, no CDN.
• Time tracking against tasks, and worklog comments that make a project activity feed say something more useful than "this changed".
• Persistent agent memory — a queryable store of decisions and context, scoped per project or globally, attributed to whichever agent wrote it.
• An MCP server at /mcp (Streamable HTTP, JSON-RPC) exposing around 29 tools.
• Optimistic concurrency on writes, so a person and an agent editing the same task get a conflict instead of a silent overwrite.

The organising rule is that every MCP tool calls the same domain service the user interface calls. There is no second implementation to drift out of sync, which is the usual fate of an API maintained beside an application rather than underneath it.

Post-Installation

After enabling the modules you want:

• The project dashboard is at /pm, and also appears in the admin menu.
• The knowledge base is at /kb.
• Permissions are at /admin/people/permissions. There are five: administer petrichor, manage petrichor content, delete petrichor content, view petrichor content and access petrichor mcp.

Note that delete is deliberately separate from manage. For an AI agent, create a role holding access petrichor mcp plus view petrichor content for read-only, adding manage petrichor content if it should be able to write. Do not grant an agent role delete petrichor content. Nothing in the MCP surface hard-deletes by design — the forget tool archives rather than removes — and that guarantee is enforced in the access handler rather than in shipped configuration, so it holds even when the modules are installed piecemeal.

The suite ships no theme. Module CSS reads design tokens with fallbacks, so it inherits your theme's appearance by default.

Additional Requirements

• Drupal 11
• PHP 8.3 or newer
• league/commonmark ^2.6 — installed automatically when you require the module with Composer. The wiki link syntax is implemented as a CommonMark extension, so this is a real dependency rather than a convenience.

Recommended modules/libraries

Key authentication — gives each AI agent its own API key for the MCP endpoint, which makes it possible to tell agents apart in the activity log and revoke one without affecting the others. Without it the endpoint still authenticates over HTTP basic auth and session cookies, which is fine for a browser and awkward for an autonomous client.

Similar projects

Drupal has modules for wikis, for issue tracking, and increasingly for AI integration. Petrichor differs in that these are not separate concerns here: tasks, knowledge base pages and agent memories share one project scope and one permission model, which is what lets a single call return a project brief, its open tasks, its wiki index and its memories together. That is the part that is difficult to assemble from separate modules, because no two of them agree on what a "project" is.

If you only want one of these things, a focused single-purpose module will serve you better. Petrichor is aimed at people whose research notes, small experiments and client work keep turning out to be the same material at different stages.

Supporting this Module

No funding links. Issues and merge requests are welcome, and honest bug reports are worth more than either.

Community Documentation

Documentation currently lives in the repository README.

Project status

This is a development release, and the limits are worth stating plainly rather than leaving to be discovered:

• It has had one user. Every ergonomic decision came from watching one person work, and it is not yet known which of them generalise.
• It has been exercised on SQLite. Other database drivers are untested rather than unsupported.
• The suite is architected so submodules can be installed à la carte, but that path has not yet been verified end to end.
• There is no security advisory coverage. That requires a stable release and a separate opt-in.