MCP for meeting notes: connecting Claude Desktop to your own local meeting index
Anthropic's Model Context Protocol turned what used to be a locked-in dashboard into an open socket. Here is what MCP is, why it matters for meeting notes, and how MeetMemo exposes a local meeting index to Claude Desktop and Cursor with eight tools and a synthesize call.
MCP for meeting notes: connecting Claude Desktop to your own local meeting index
The most underrated piece of infrastructure released in late 2024 was not a new model. It was a protocol.
Anthropic released the Model Context Protocol (MCP) in November 2024. It looked, to most people, like a standard JSON-RPC server spec. Eighteen months later, it has done the quiet thing that protocols do: it changed where the value lives in AI tooling.
This post is for people who already use Claude Desktop, Cursor or any other MCP-aware AI client, and who want to understand what MCP unlocks specifically for meeting notes. We will walk through what an MCP server actually is, what eight tools we expose from MeetMemo, and how a "second brain" feels different when it is local plus addressable by any AI you already use.
What MCP actually is
MCP is a JSON-RPC 2.0 protocol that lets AI clients talk to external tools and data sources through a standard interface. The client is something like Claude Desktop or Cursor. The server is anything that exposes the right RPC methods.
The protocol defines a small surface:
- Tools. Named, schema-typed functions the client can call. ("Search my meetings for X" or "Read action items between dates Y and Z".)
- Resources. Addressable items the client can pin into a chat context. (Each meeting has a URI like
meetmemo://meeting/{uuid}.) - Prompts. Optional templated prompts the server suggests.
A client connects to a server over stdio (most common), HTTP, or a Unix socket. Authentication is up to the server; for local servers there is usually none, because the trust boundary is the user's own machine.
That is the whole protocol. It is small on purpose. The point is to give every AI client a uniform way to read from anything, and to let any developer expose their data to every AI client without writing an integration per client.
Why this matters for meeting notes
Meeting notes used to be a locked-in dashboard problem.
Otter has a chat. Fireflies has a chat. Notion AI has a chat. Each cloud meeting tool exposes its data through its own UI, and the way you ask "what did we agree about pricing across the last five product meetings" is to open the vendor's chat and hope their model answers. The meeting tool's value lived in two layers: the storage layer (your transcripts in their database) and the chat layer (their UI for asking questions).
MCP flattens that.
Once a tool exposes its data through MCP, the chat UI is the AI client you already use. Claude Desktop becomes the surface. Cursor becomes the surface. Whatever MCP-aware tool the user prefers becomes the surface. The meeting tool's value collapses back to where it always belonged: the index.
For users this is a clean win. They stop juggling six product chats and instead ask Claude. For tool builders it is a forced re-evaluation. If the chat UI was your moat, MCP just removed it. If the index was your moat, MCP just amplified it.
What we expose from MeetMemo over MCP
MeetMemo's MCP server exposes eight tools, all of which read from the local SQLite index in ~/Library/Application Support/MeetMemo/index.sqlite. Every call is logged to a local audit table.
search_meetings. Free-text search across every meeting you have recorded. Backed by SQLite FTS5 plus 384-dim Apple NLEmbedding vectors and Reciprocal Rank Fusion. Returns snippets with timestamp boundaries.
get_transcript. Returns the structured transcript of a specific meeting, including speaker turns when available, with bracketed timestamps.
get_transcript_text. Like get_transcript, but returns plain text without metadata. Cheaper for the model when full structure is not needed.
find_related. Cross-meeting recommendations. Computes the centroid embedding of the source meeting and returns the top-K most similar meetings by cosine similarity. Falls back to lexical OR-query when no embeddings exist for the source.
list_action_items. Returns the structured action-items table, filterable by date range, theme, owner or status. These are extracted by the on-device summariser at index time, not regex-parsed from the transcript.
get_context_for_date. Gives the model a window of meetings around a date. Useful for "summarise yesterday" or "what was on my calendar last Tuesday" style questions.
summarize_meeting. Asks the on-device LLM to summarise a specific meeting on the fly, with kind options (tldr, decisions, action_items, themes). Uses map-reduce for long meetings.
synthesize. The killer tool. Cross-meeting question answering with citations. Top-K retrieval over the index, on-device LLM call to draft an answer, citation extraction so the response includes [1][2][3] markers resolved to specific meeting plus timestamp pairs.
In addition, every meeting is exposed as an MCP resource at meetmemo://meeting/{uuid}. Claude Desktop's chat UI can pin a specific meeting to a conversation without making a tool call.
What the workflow looks like in Claude Desktop
Concrete example. You are preparing for a quarterly review and want to know what the team committed to over the last five product meetings.
You open Claude Desktop and type: "What did we agree to ship in Q3 across the last five product meetings?"
Claude calls synthesize on the MeetMemo MCP server. The server retrieves the top-ranked chunks across the matching meetings, runs the local LLM on the user's Mac to draft an answer, extracts citations, and returns:
Across the last five product meetings (April 12, April 19, April 26, May 3, May 10), the team committed to ship: a redesigned onboarding [1], the new export-to-PDF flow [2], the bulk-tagging feature [3], and the public API beta [1][4]. Spec drafts due May 17 [5].
[1] Product Standup, 12 April 2026 (00:14:32) [2] Engineering Review, 19 April 2026 (00:31:08) [3] Product Standup, 26 April 2026 (00:08:51) [4] Engineering Review, 3 May 2026 (00:22:14) [5] Product Standup, 10 May 2026 (00:41:09)
The citations are clickable in some clients. The user's relationship with Anthropic does not change; they already had a Claude subscription. MeetMemo is not a chat product, it is the index Claude reads from.
Three properties of this flow are worth naming:
- No data left the Mac. The retrieval ran against a local SQLite file. The LLM that drafted the answer ran on Apple MLX on the user's Neural Engine. Claude Desktop received a JSON-RPC response over stdio.
- The index is portable. If a user later wants to use Cursor's MCP integration instead of Claude Desktop, the same MeetMemo server works. If they install a new MCP-aware client tomorrow, same again.
- The audit trail is local. Every tool call is in
audit_log. The user can see what each AI client read from their data and when.
What you have to do to make this work
The setup is one click. In MeetMemo, Settings → Connect AI → Connect Claude Desktop writes the right entry to ~/Library/Application Support/Claude/claude_desktop_config.json. Same for Cursor (Settings → Connect Cursor).
Under the hood, the config that gets written looks like:
{
"mcpServers": {
"meetmemo": {
"command": "/Applications/MeetMemo.app/Contents/MacOS/MeetMemo",
"args": ["--mcp-server"]
}
}
}
Claude Desktop will spawn the MeetMemo binary with the --mcp-server flag when needed, talk to it over stdio, and shut it down when the chat ends. The user does not need to keep the MeetMemo menu-bar app running for MCP to work; the spawned process serves the index directly from the SQLite file.
For users who want to wire it up manually (Zed, Continue, custom MCP clients, etc.), the binary plus flag is the whole interface. We documented the JSON-RPC schema at meetmemo.app/mcp.
Why this is the right shape for "second brain"
A second brain that lives in a vendor's cloud and is queryable only through their chat is a custody problem dressed up as a feature. A second brain that lives in your own SQLite file and is queryable through any AI you trust is what you would build if you started from a blank page.
MCP is not magical. It is a small, sensible JSON-RPC contract. But by making the chat UI a commodity (any MCP client) and the index the value layer (yours, locally), it inverts who owns what in the AI-tooling stack.
For meetings specifically, that inversion is the whole story. We bet on it three years ago. As of 2026, with Claude Desktop, Cursor, Zed and a long tail of agentic frameworks all speaking MCP, that bet looks straightforwardly correct.
If you want to try it: download MeetMemo, record one meeting, run the one-click Connect Claude Desktop step, and ask Claude something about the meeting you just recorded. The whole loop runs on your Mac. No cloud. No vendor chat. Just your meetings, addressable by your AI.
