Minutes: local Markdown meeting memory that an MCP client can query
Open-source, local-first Granola/Otter alternative that Claude Code, Codex, Cursor, and any MCP client can query. Meetings, calls, and voice memos transcribed on-device into markdown you own.
At a glance
- What is it?
- Minutes is a Rust, MIT-licensed capture and transcription tool that writes meeting notes as Markdown files under ~/meetings/ and exposes them to Claude Code, Codex, Cursor or any MCP client. The interesting part is not the recorder, it is the decision to make the files the interface.
- Who is it for?
- Adopt Minutes if your agent already lives in a terminal and you want meeting history as plain files under ~/meetings/ that grep, Obsidian and an MCP client can all read. Do not adopt it if you need a hosted notepad that works on a locked-down laptop with no local install, or if you want the vendor to own the summarisation model and the storage.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem is retrieval, not transcription
Transcription is close to solved and mostly commoditised. What is not solved is getting a decision made in a meeting six weeks ago back into the context window of whatever agent you are currently using. Hosted notepads answer that by keeping the corpus in their workspace and exposing it through their own integration. Minutes answers it by writing each conversation to a Markdown file with YAML frontmatter in ~/meetings/ and then exposing that directory over MCP. The README frames the product as a "conversation memory app for the AI you already use", which is a narrower claim than meeting assistant. The target user is the person who already runs Claude Code or Cursor all day and wants meeting history to be one more thing the agent can search, alongside the repo and the notes vault. The secondary audience is the desktop notetaker who wants a menu bar recorder and a Recall view, and the README splits these into two sets of personas in docs/personas.md.
Markdown plus frontmatter is the whole data model
The README's output example shows the shape: a YAML block with title, type, date, duration, context, action_items and decisions, followed by the transcript body. Action items carry assignee, task, due and status. Decisions are a list of text entries. A separate frontmatter schema document is referenced at docs/architecture/frontmatter-schema.md, and that is where the real contract lives, because anything reading these files programmatically depends on those keys staying stable. This is the design decision that everything else follows from. Because the store is a directory of files, Obsidian and Logseq can open it without an import step, grep works, and the MCP server is a reader over the same corpus rather than a separate database. It also means the schema is a public API whether or not the project treats it as one. Renaming a frontmatter key is a breaking change for every downstream script, and the README does not describe a versioning policy for that schema.
Four surfaces over one corpus
The README lists a desktop app, a CLI with 58 commands, an MCP server with 34 tools, a Claude Code plugin with 23 skills, and a TypeScript SDK. That is a lot of surface area for a project at v0.26.x, and the honest reading is that the CLI and MCP server are the load-bearing parts while the plugin and SDK are conveniences layered on top. The MCP server is distributed on npm as minutes-mcp, so the agent integration does not require the Rust toolchain. The SDK is documented as TypeScript access to meeting files without MCP, which is the escape hatch for anyone building an agent that does not speak the protocol. The risk with five surfaces is drift: a tool count in the README is a claim that has to be kept true release after release. The release notes suggest active work in this area, with v0.26.0 titled "Recall from the right meeting library", which implies the recall path was previously reading the wrong corpus.
Getting it running
Installation is four options. The Homebrew cask gives you the desktop app: brew install --cask silverstein/tap/minutes. The formula gives the CLI: brew install silverstein/tap/minutes. Cargo users get cargo install minutes-cli. The MCP server runs from npm with npx minutes-mcp. The README notes that Homebrew may report an untrusted tap, in which case run brew trust silverstein/tap once. Wiring it into an agent is a single command: claude mcp add minutes -- npx -y minutes-mcp. To try it without a microphone, the README suggests minutes demo --full, which seeds five sample meetings, and minutes demo --clean removes them. A direct tool call looks like search_meetings({"query":"monthly billing decision"}). Recording is minutes record followed by minutes stop to trigger transcription. Client-specific setup for Codex, Gemini CLI, Claude Desktop, Cursor, OpenCode, Pi, Mistral Vibe, Cowork and Dispatch lives in docs/integration/clients.md and per-client pages. Configuration keys are in docs/configuration.md, which the README links but does not reproduce, so I cannot state any specific key names or defaults from the material supplied.
The demo query is the real product claim
The README's worked example asks what was decided about monthly billing and whether it stuck. The stated answer spans two meetings a month apart, one launching the decision on Feb 28 and one reversing it on Mar 25. That is a temporal reasoning problem, not a search problem, and it is the claim worth testing. A keyword search over Markdown would find both files. Producing the reversal requires the agent to read both, notice the dates, and reconcile them, which is work the MCP layer can support but not perform. Minutes supplies retrieval; the reasoning is the client's. That distinction matters when evaluating it, because a weak model will return the first meeting and call it the answer. It also explains why the frontmatter carries structured decisions rather than leaving them buried in prose: the structure gives the agent something to compare across files without re-reading every transcript.
Where it is the wrong tool
The README is explicit that text leaves the machine when you send authorised context to a cloud agent or summariser. So the privacy claim is about capture and storage, not about the whole pipeline. If you point a hosted model at the corpus, the meeting content goes to that provider. The on-device guarantee covers transcription and speaker processing and audio storage, and nothing beyond that. The second limitation is operational. This is a local install with a Rust binary, a Homebrew tap and an npm package, which means it does not fit environments where you cannot install software, cannot run a local speech model, or cannot keep audio on the endpoint. A browser-based hosted notepad works on a managed laptop where Minutes does not. The third is maturity: v0.26.x with releases landing days apart, including one titled "The live transcript is back" and another about keeping the microphone running after an overload, tells you the capture path has had regressions recently. If you need a recorder that has never dropped a live transcript, this version history is a reason to wait or to pin a specific release.
Against Granola, Otter and Anarlog
The README's own comparison table is the most useful part of the document. Granola and Otter are described as hosted products with hosted workspaces and cloud transcription, and hosted MCP or hosted integrations for agent access. Anarlog (formerly Hyprnote) is the closest architectural relative: local meeting notepad, local SQLite plus files, CLI and MCP, local AI only with local providers. Minutes differs from Anarlog in two concrete ways. Storage is Markdown plus YAML rather than SQLite plus files, which trades query performance and transactional safety for readability by any text tool. And the AI provider is your choice rather than tied to local providers, which is the opposite trade: more flexibility, but also the path by which text leaves the machine. Against Granola and Otter the difference is simpler. They keep the corpus; Minutes keeps it in ~/meetings/ and gives the agent a reader. The README also notes that Anarlog's community app is MIT while its enterprise components use a commercial licence, whereas Minutes states no relicensing and no paid tier for anything in the repository.
Licence, upgrades and what to check before committing
Minutes is MIT licensed, and the README commits to staying that way with no relicensing and no paid tier for anything in the repo. For a tool that writes your meeting history to a directory you own, the licence matters less than the file format, because the format is what you would have to migrate away from. MIT gives you the right to fork the reader if the project stalls. On maintenance cost, the release cadence is high: three releases in the first ten days of September 2026, two of them fixing capture behaviour. High cadence on a local tool means you either track releases closely or pin a version, and the README's install instructions do not describe a pinning mechanism. The upgrade path is documented in docs/install.md alongside troubleshooting. Before adopting, check three things in the repository rather than the marketing: the frontmatter schema document, the consent enforcement design at docs/architecture/consent-enforcement.md, and whether the CLI command set in docs/features.md covers your recording sources. The consent material deserves particular attention because recording law varies by jurisdiction and the README only says the tool provides reminders, acknowledgement and provenance to help you disclose.
Editorial conclusion
Adopt Minutes if your agent already lives in a terminal and you want meeting history as plain files under ~/meetings/ that grep, Obsidian and an MCP client can all read. Do not adopt it if you need a hosted notepad that works on a locked-down laptop with no local install, or if you want the vendor to own the summarisation model and the storage. Verify three things first: that on-device transcription runs acceptably on your hardware, that your MCP client connects with claude mcp add minutes -- npx -y minutes-mcp, and that the consent and restricted-meeting behaviour in docs/security/ matches your jurisdiction's recording rules.
Community notes