Skip to main content
Glama
dev-diary-mcp

dev-diary-mcp

by rogeriolaa

dev-diary-mcp

CI License: MIT Node MCP

A Model Context Protocol server that turns a plain folder of Markdown files into a searchable work journal any LLM can read and write.

No database. No app. Your work log is just diary/2026-11-07.md — human-readable, diffable, git-friendly — and your AI assistant gets six tools to use it:

Tool

What it does

log_work

Appends a timestamped entry (with tags) to today's file

edit_entry

Replaces an existing entry by date + time

delete_entry

Removes an existing entry by date + time

search_diary

Full-text search across all entries, optional tag/date filter

daily_summary

Everything logged on a given day

stats

Totals, active days, current streak, top tags

Why

"Log what I did today" is the task everyone abandons after a week. But your AI assistant already knows what you did — it helped you do it. Give it tools against a Markdown folder and keeping a work journal becomes a byproduct of working with AI.

Related MCP server: Stoa

Run the demo

The repo ships a real MCP client that drives the server end-to-end (handshake → listTools → tool calls), so you can verify everything without an editor:

npm install
npm run build
npm run demo

Then look at diary/*.md — that's your data. Plain Markdown.

Connect it to your editor / agent

The package is on npm, so the easiest setup is npx — no clone, no build:

Claude Desktop / Cursor / any MCP client

{
  "mcpServers": {
    "dev-diary": {
      "command": "npx",
      "args": ["-y", "dev-diary-mcp"],
      "env": { "DIARY_DIR": "/absolute/path/to/your/diary" }
    }
  }
}

Or from a source checkout:

{
  "mcpServers": {
    "dev-diary": {
      "command": "node",
      "args": ["/absolute/path/to/dev-diary-mcp/dist/server.js"],
      "env": { "DIARY_DIR": "/absolute/path/to/your/diary" }
    }
  }
}

Hermes Agent

hermes mcp add dev-diary --command npx --args -y dev-diary-mcp

Inspect it interactively

npx @modelcontextprotocol/inspector node dist/server.js

The storage format

One file per day (diary/YYYY-MM-DD.md), entries as H2 headings with embedded tags:

## 14:32 #bugfix #websocket
Fixed the race condition in the WebSocket broadcast queue

## 16:10 #testing
Wrote E2E test covering two-client sync

Because it's just files, you can grep it, back it up, edit it by hand, or commit it. The server reads whatever is on disk on every call — no cache to invalidate.

Correctness guarantees

Writes are the risky part of a file-backed store, so the server is careful about them:

  • Your hand-written content is never touched. A day file may contain any Markdown you wrote by hand. The server never re-serializes a whole file from its parsed entries — it appends, and it splices edits into the original text. Content it doesn't understand survives untouched.

  • Concurrent calls can't lose entries. All day-file mutations are serialized through an in-process queue, and each write goes to a temp file and is then renamed into place, so a reader never sees a half-written file.

  • Editing one entry doesn't affect its neighbours. Entries are addressed by date, time, and occurrence, so two entries logged in the same minute stay individually editable and deletable.

  • Failed operations don't leave litter. Deleting an entry that doesn't exist reports an error and creates no file; removing the last entry of a day removes the day file, so stats and streaks stay accurate.

  • today means your local day. Dates default to the local timezone, not UTC, so an entry written at 22:00 lands on the right day.

  • Search can't flood your context. search_diary accepts from/to date ranges and a limit (default 50).

Development

npm run typecheck   # tsc --noEmit
npm run build       # compile to dist/ (tests excluded)
npm test            # unit tests (vitest)
npm run test:e2e    # end-to-end checks over a real MCP stdio session
npm run demo        # human-readable walkthrough

The end-to-end suite drives the server through a real MCP client and asserts on the resulting files — including that hand-written content survives every operation, that concurrent writes don't drop entries, and that error paths don't create stray files.

How it works

Built with the official @modelcontextprotocol/server SDK (2026-07-28 spec):

  • McpServer + registerTool(name, { description, inputSchema }, handler) — schemas are Standard Schema; this project uses Zod v4

  • StdioServerTransport — the editor spawns the process and talks JSON-RPC over stdin/stdout

  • src/storage.ts holds the pure, side-effect-free parsing and editing logic; src/server.ts wires it to the MCP tools

Companion article: "I Built an MCP Server That Keeps My Work Journal — Here's Everything I Learned" (draft in this repo).

License

MIT

Available Tools

6 tools
daily_summaryB

Everything logged on a given date (YYYY-MM-DD). Defaults to today.

Inputs: date.

delete_entryA

Remove an existing entry identified by date and time (HH:MM). If several entries share the same time, use occurrence to pick one (1-based).

Inputs: date (required), time (required), occurrence.

edit_entryA

Replace an existing entry identified by date and time (HH:MM). If several entries share the same time, use occurrence to pick one (1-based). Omit tags to keep the existing tags.

Inputs: date (required), text (required), time (required), tags, +1 more.

log_workA

Append a timestamped entry to the developer diary for today (or a given date). Use this whenever the user says they finished/did/fixed something and wants it recorded.

Inputs: text (required), date, tags, time.

search_diaryA

Full-text search across every diary entry. Returns matching entries with date, time and tags.

Inputs: query (required), to, tag, from, +1 more.

statsA

Diary statistics: total entries, active days, current streak of consecutive days, and top tags.

Inputs: no named parameters.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    A3.8/5.0

    Scored across 6 tools

    Disambiguation5/5

    Each tool maps to a distinct action on the diary: append (log_work), replace (edit_entry), remove (delete_entry), full-text lookup (search_diary), date-scoped listing (daily_summary), and aggregate metrics (stats). The retrieval tools could superficially overlap, but their descriptions clearly separate full-text search, per-date listing, and aggregate statistics.

    Naming Consistency4/5

    Four tools follow a clean verb_noun snake_case pattern (log_work, edit_entry, delete_entry, search_diary). The two read-only views, daily_summary and stats, drop the verb and are bare noun phrases, a minor but noticeable deviation in an otherwise consistent set.

    Tool Count5/5

    Six tools is well-scoped for a personal diary server: one write, one update, one delete, and three read/query shapes. Nothing appears redundant and no obvious capability is missing from the surface.

    Completeness4/5

    Full lifecycle coverage exists: create, edit, delete, search, date view, and stats, so agents won't hit dead ends for core workflows. Minor gaps remain, such as tag-based filtering/listing, retrieving entries across a custom date range, or fetching a single entry directly without search.

    Maintenance

    ActivityMaintained
    ResponsivenessOutdated data

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      Not graded
      quality
      C
      maintenance
      Persistent shared memory for AI coding agents that turns a folder of markdown files into searchable memory across sessions, repos, and machines.
      10 npm
      Functional Source , Version 1.1, MIT Future
    • A
      license
      Not graded
      quality
      C
      maintenance
      Turns any folder of Markdown files into a searchable, structured knowledge base for Claude Code, enabling persistent memory across sessions via tools like list, read, write, edit, search, and summarize.
      MIT