Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@meeting-memory-mcp Log today's standup and check for any contradictions"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A local-first MCP server that gives Claude memory across your meeting transcripts.
Most "AI meeting notes" tools summarize one meeting at a time and forget everything once the chat window closes. This server stores transcripts locally (SQLite, full-text search) and lets Claude maintain a living, human-readable markdown wiki of decisions, open commitments, and contradictions across meetings — so the next time you talk to Claude about a project or a client, it already remembers what happened last time.
Everything stays on your machine. No transcript or summary is ever sent anywhere except to the LLM you're already chatting with (Claude).
You paste a transcript into Claude and say "log this meeting."
Claude calls add_meeting to store it, then search_meetings to pull up anything
related from past meetings.
Claude reasons over both (in its own context — this server does no LLM calls itself)
and calls write_wiki_page to update a markdown page for that topic/client/project
with the latest decisions, status, and any contradictions it noticed.
Next time, Claude calls read_wiki_page first to recall context before you even
mention details.
The wiki pages are plain markdown files on disk (~/.meeting-memory-mcp/wiki/ by
default) — you can open, edit, or read them yourself anytime, no app required.
Related MCP server: kb
Tool | Purpose |
| Store a new transcript |
| Full-text search across all past transcripts |
| Fetch a full transcript by id |
| List all stored meetings |
| Create/update a durable markdown memory page |
| Read a memory page |
| List all memory pages |
Requires uv.
git clone <this repo>
cd meeting-memory-mcp
uv syncAdd to your MCP config (claude_desktop_config.json or .mcp.json):
{
"mcpServers": {
"meeting-memory": {
"command": "uv",
"args": ["--directory", "/absolute/path/to/meeting-memory-mcp", "run", "meeting-memory-mcp"]
}
}
}Restart Claude. Then just say: "Here's a transcript from today's call, log it and let me know if it conflicts with anything we discussed before."
Defaults to ~/.meeting-memory-mcp/. Override with the MEETING_MEMORY_DIR environment
variable (e.g. to keep separate memory per client or sync the folder via your own
backup tool).
Every meeting-notes tool on the market summarizes a single meeting well. None of them help a non-technical user notice "you committed to this three meetings ago and it never came up again," because that requires reasoning across history, not just one transcript. This server doesn't do that reasoning itself — it gives Claude the storage and retrieval it needs to do it, and a human-readable place to keep what it learns.
MIT
Store a new meeting transcript locally so it can be searched and referenced in future sessions. Call this whenever the user shares a new meeting transcript.
Args: title: Short title for the meeting, e.g. 'Acme Corp - pricing call' transcript: The full raw transcript text meeting_date: Date of the meeting, ISO format if known (e.g. 2026-06-24)
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| transcript | Yes | ||
| meeting_date | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the action and the local storage behavior, but lacks details on constraints (e.g., duplicate titles, size limits), idempotency, or side effects. The description is adequate but not thorough for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a brief purpose/usage sentence, then a clear arg list. Every sentence adds value, and the information is front-loaded. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (not shown), the description needn't cover return values. It covers purpose, usage, and parameter details adequately. It could mention error conditions or constraints, but for a simple creation tool with rich parameter descriptions, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description provides explicit, helpful explanations for all three parameters: title is a short title with an example, transcript is full raw text, meeting_date is ISO format and optional with an example. This fully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Store' and resource 'meeting transcript', and specifies the action is local storage for future search/reference. It distinguishes from sibling tools like get_meeting, list_meetings, and search_meetings, which are retrieval-focused.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call this whenever the user shares a new meeting transcript', providing clear usage context. However, it does not mention when not to use it or alternatives, which would be helpful but is not critical given the sibling tool names imply different purposes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the full raw transcript text of a previously stored meeting by its id (returned by search_meetings or list_meetings).
Args: id: The meeting id
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool is a retrieval operation ('Retrieve') and mentions it returns 'full raw transcript text' of a previously stored meeting. This gives sufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a one-sentence purpose followed by a one-line parameter definition. It is front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter retrieval tool with an output schema present, the description is complete. It mentions the source of the input id and the nature of the output ('full raw transcript text').
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a single required parameter 'id' (integer). The description adds that the id comes from search_meetings or list_meetings, which provides context beyond the schema's title 'Id'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieve'), the resource ('full raw transcript text'), and the identifier ('by its id'). It distinguishes from siblings by referencing how to obtain the id (from search_meetings or list_meetings).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool: after obtaining the id from search_meetings or list_meetings. It does not explicitly state when not to use it, but the context is clear enough for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all stored meetings with id, title, and date, most recent first.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly mentions it returns id, title, and date, and orders by most recent first. Since no annotations are provided, this carries the full burden; it implies a read-only operation but does not discuss pagination or limits. However, for a zero-parameter list tool, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with 12 words, no redundancy. It front-loads the verb and resource, includes ordering, and no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (no parameters, output schema exists), the description fully covers the tool's purpose and behavior. It specifies the output fields and ordering, which is sufficient for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the description does not need to add meaning beyond the schema. Baseline score of 4 applies as per guidelines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list), resource (all stored meetings), output fields (id, title, date), and ordering (most recent first), which distinguishes it from siblings like get_meeting (single meeting) and search_meetings (filtered).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like search_meetings or get_meeting. The description only states what it does without indicating possible use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all existing wiki pages with their slug, title, and last-updated time, most recently updated first. Use this to see what topics already have durable memory before deciding whether to create a new page or update an existing one.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully bears the burden. It discloses the returned fields and ordering. The tool is read-only and non-destructive, which is implied and appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. First sentence describes functionality, second gives usage guidance. No filler, perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, the description fully covers what the agent needs: purpose, output fields, ordering, and strategic context. Output schema exists but description supplements it adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%. Baseline for 0 params is 4. Description adds no param info, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all wiki pages with slug, title, and last-updated time, ordered by most recent. It distinguishes from siblings like read_wiki_page or write_wiki_page by focusing on the overview of existing topics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly guides when to use: 'Use this to see what topics already have durable memory before deciding whether to create a new page or update an existing one.' This tells the agent to use it before write operations, providing clear decision context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the current content of a wiki page by slug. Call this at the start of a session about a known topic to recall prior context before reading raw transcripts.
Args: slug: The page's stable identifier
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states it reads content, but omits details like idempotency, permissions, or error handling. Does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences and a clear Args list, front-loaded with purpose and usage. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with one parameter and output schema present. Covers purpose, usage, and parameter meaning. Missing error conditions but adequate for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description compensates by explaining 'slug: The page's stable identifier', adding meaning beyond the schema's type string.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read the current content of a wiki page by slug' with a specific verb and resource. It distinguishes from siblings like write_wiki_page and list_wiki_pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when to use: 'at the start of a session about a known topic to recall prior context'. Does not state when not to use, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full-text search across all previously stored meeting transcripts. Use this before summarizing a new meeting to find related history, prior commitments, or context that might contradict the current discussion.
Args: query: Search terms, e.g. 'pricing' or 'renewal date' limit: Maximum number of results to return (1-50)
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses scope (previously stored transcripts) and nature (full-text search), appropriate for a read operation with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded purpose, every sentence adds value, with clean parameter listing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully adequate for a simple search tool with two parameters and an output schema; covers what, when, and parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description adds meaningful examples and constraints for both parameters (query terms, limit range).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs full-text search across meeting transcripts, distinguishing it from siblings like add_meeting or list_meetings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use context (before summarizing a new meeting to find related history), but lacks explicit when-not-to-use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create or fully overwrite a persistent local wiki page (markdown) that summarizes the durable knowledge about a topic, person, project, or recurring meeting series: key decisions, current status, open commitments, and any contradictions found across meetings. This is the long-term memory that future sessions will read back. Always start the content with a '# Title' heading.
Args: slug: A short stable identifier for this page, e.g. 'acme-corp' or 'q3-roadmap' content: Full markdown content of the page, starting with '# Title'
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| content | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It reveals the tool is destructive (overwrites) and requires markdown with a title. Missing details on authentication, rate limits, or conflict behavior, but the core behavior is adequately described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is clear and well-structured with an Args section. It is slightly verbose in the first sentence but each part is informative. No redundancy, and it efficiently communicates purpose and parameter expectations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema present but not shown; however, the description does not mention return values or error handling. It covers purpose and parameters adequately but leaves gaps regarding success confirmation and potential errors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by fully explaining both parameters: slug as a stable identifier with examples, and content as full markdown starting with '# Title'. This adds concrete guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool creates or overwrites a persistent wiki page with markdown content. It specifies the use case for summarizing durable knowledge about topics, people, projects, or meetings, distinguishing it from sibling tools like read_wiki_page and list_wiki_pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides context on when to use (for long-term memory storage) and what content to include (key decisions, status, commitments). However, it does not explicitly state when not to use or mention alternative tools for transient data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0add_meetingget_meetinglist_meetingslist_wiki_pagesread_wiki_pagesearch_meetingswrite_wiki_pageScored across 7 tools
Tools clearly separate meeting operations (add_meeting, get_meeting, list_meetings, search_meetings) from wiki operations (write_wiki_page, read_wiki_page, list_wiki_pages). Within each domain, each tool serves a distinct purpose with no overlap.
All tool names follow a consistent verb_noun pattern with snake_case (add_meeting, get_meeting, list_meetings, search_meetings, write_wiki_page, read_wiki_page, list_wiki_pages). No deviations or mixing of conventions.
7 tools is a well-scoped set covering two domains (meetings and wiki). Each tool provides essential functionality without unnecessary redundancy, fitting the server's purpose of storing and retrieving meeting transcripts and wiki summaries.
The tool surface covers core CRUD operations for meetings (add, get, list, search) and wiki (write, read, list). Missing delete and update for meetings, and delete for wiki, but these are minor gaps; agents can work around by writing new wiki pages or relying on search.
Persistent, governed institutional memory for Claude Code — specs, decisions, learnings.
Persistent memory for AI assistants. Save once; recall from Claude, ChatGPT, or any MCP client.
Persistent AI memory shared across Claude, ChatGPT, coding agents, and compatible MCP clients.
One memory, every AI. A shared, user-owned markdown memory your AI clients read and write over MCP.
