Skip to main content
Glama
oscar-wang-xin

MCP Session Saver

by oscar-wang-xin
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

🎉 MCP Session Saver

English | 简体中文

An MCP service for saving session records. Session content can be saved to a specified directory and stored as Markdown files organized by IDE name, date, and session description.

✨ Key Features

  • 📝 Save Session Records - Save AI conversations as Markdown files

  • 📁 Smart Organization - Automatically categorized by IDE/date/description

  • 🔍 Session Management - Read, search, and delete sessions

  • 🌐 Multi-IDE Support - Compatible with Qoder, Cursor, Claude Desktop, Windsurf, Trae, Codebuddy, Lingma, Continue, Aider, and more

Related MCP server: Claude Code History MCP Server

🚀 Quick Start

Method 1: Using npx (Recommended)

No installation required. Simply add to your IDE's MCP configuration:

{
  "mcpServers": {
    "session-saver": {
      "command": "npx",
      "args": ["-y", "mcp-session-saver"]
    }
  }
}

Method 2: Global Installation

npm install -g mcp-session-saver

MCP Configuration:

{
  "mcpServers": {
    "session-saver": {
      "command": "mcp-session-saver"
    }
  }
}

Method 3: Local Installation

npm install mcp-session-saver

📁 Custom Storage Path (Optional)

Add environment variable in MCP configuration:

{
  "mcpServers": {
    "session-saver": {
      "command": "npx",
      "args": ["-y", "mcp-session-saver"],
      "env": {
        "MCP_SESSION_BASE_DIR": "D:\\MyProjects\\sessions"
      }
    }
  }
}

🎯 How to Use

After configuration, simply say in your IDE:

Save current session
List all sessions
Search session content

📚 Documentation

🛠️ Tech Stack

  • JavaScript (ES Module)

  • @modelcontextprotocol/sdk

  • Node.js >= 16.0.0

📝 License

MIT

👏 Contributing

Issues and Pull Requests are welcome!

Available Tools

5 tools
delete_sessionA

【删除会话】当用户说"删除这个会话"、"移除这条记录"、"清理这个对话"、"不需要这个会话了"等时调用。永久删除指定的会话文件。触发词：删除、移除、清理、不需要会话/对话/记录

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYes要删除的会话文件路径(可从 list_sessions 结果中获取)

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description notes that the deletion is permanent ('永久删除'), which is a key behavioral trait. However, with no annotations provided, the description lacks details on permissions, error handling, or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, front-loaded with purpose, and includes a helpful list of trigger words. Every element serves a clear purpose with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter tool with no output schema, the description covers when to use it and what it does. It could include more about error cases, but it is sufficiently complete for typical use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the parameter description in the schema is sufficient. The tool description does not add further meaning to the file_path parameter beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'delete' and resource 'session', and specifies when to invoke based on user phrases. It also distinguishes from sibling tools like list_sessions, read_session, etc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly lists trigger words for invocation, providing clear usage context. However, it does not specify when not to use the tool or mention alternatives, though siblings are implicitly differentiated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_sessionsB

【列出会话】当用户说"查看会话列表"、"列出所有会话"、"显示已保存的对话"、"有哪些会话记录"等时调用。支持按IDE和日期筛选。触发词：列表、查看、显示、所有、历史会话/对话/记录

ParametersJSON Schema
NameRequiredDescriptionDefault
base_dirNo会话保存的基础目录路径(可选,优先级最高。未指定时依次使用: 环境变量MCP_SESSION_BASE_DIR > config.json配置 > 默认路径)
ide_nameNoIDE名称(可选,用于筛选特定IDE的会话，如只查看Cursor的会话)
date_filterNo日期过滤(可选,格式: YYYY-MM-DD，如 2025-12-16，用于查看指定日期的会话)

TDQS

B3.3/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavior. It only states 'list sessions' without detailing what information is returned (metadata vs content), pagination, or any side effects, leaving gaps for an AI agent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loaded with the main purpose. However, it includes redundant trigger words that slightly reduce efficiency. Still, it's well-structured for its length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 3 optional parameters and no output schema, the description fails to mention what the list returns (e.g., session metadata, count limits, or ordering). This lack of completeness hinders an agent's effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so parameters are well-documented. The description adds minimal value beyond the schema, simply noting support for IDE and date filtering, which is already clear from parameter descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: listing sessions, with specific trigger phrases and filtering options (by IDE and date). It distinguishes from siblings like search_sessions by implying a simpler list operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides trigger words and when to call (e.g., 'view session list'), but does not explicitly mention when not to use or alternatives like search_sessions for more extensive queries.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

read_sessionA

【读取会话】当用户说"打开这个会话"、"查看会话内容"、"读取这个文件"、"显示对话详情"等时调用。读取并显示指定会话的完整内容。触发词：打开、读取、查看、显示会话/对话内容/详情

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYes会话文件的完整路径(可从 list_sessions 结果中获取)

TDQS

A3.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It indicates a read operation ('读取并显示') but does not disclose side effects, error behavior, or that it is read-only, leaving some ambiguity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with one sentence and trigger words, front-loaded with the purpose. However, it could be more structured (e.g., separate sections) for clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a simple tool with one parameter, no output schema, and five sibling tools, the description covers the main purpose and usage context. It mentions returning full content, but lacks an explicit read-only warning.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the parameter description in the schema is informative ('full path from list_sessions'). The main description adds no further parameter semantics, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool reads and displays the complete content of a specified session, with trigger words that differentiate it from sibling tools like delete_session or save_session.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit trigger words and usage examples (e.g., 'open this session', 'view session content') that guide when to invoke the tool, but does not explicitly state when not to use it or name alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

save_sessionA

【保存会话】当用户说"保存当前会话"、"存储会话"、"记录对话"、"保存对话内容"等时调用。将AI对话内容保存为Markdown文件，按IDE/日期自动分类存储。

⚠️ 调用前必须执行的步骤：

  1. AI助手必须先在内部整理完整的对话历史

  2. 将所有用户问题和AI回答按时间顺序格式化

  3. 使用清晰的Markdown格式（# 用户、# AI助手等标题）

  4. 将整理好的完整对话作为content参数传入

❌ 禁止行为：

  • 禁止传入对话摘要或总结

  • 禁止遗漏任何历史问答

  • 禁止使用简化格式

✅ 正确格式示例：

用户

[第一个问题的完整内容...]

AI助手

[第一个回答的完整内容...]

用户

[第二个问题的完整内容...]

AI助手

[第二个回答的完整内容...]

触发词：保存、存储、记录、归档会话/对话/聊天

ParametersJSON Schema
NameRequiredDescriptionDefault
contentYes会话内容 - 必须是完整的原始对话记录，包含所有用户问题和AI回答。 ⚠️ 重要要求： 1. 必须包含从对话开始到现在的所有交互内容 2. 保持原始对话的完整性，不要总结或精简 3. 使用清晰的Markdown格式标记每轮对话 4. 保留代码块、列表、表格等所有格式 ✅ 标准格式： # 用户 [完整问题内容，包括所有细节] # AI助手 [完整回答内容，包括所有代码、解释、建议] # 用户 [下一个问题...] # AI助手 [下一个回答...] ❌ 错误示例： - "用户询问了关于X的问题，AI回答了Y"（这是总结，不是完整对话） - 只包含最近几轮对话（遗漏了历史内容）
base_dirNo保存会话的基础目录路径(可选,优先级最高。未指定时依次使用: 环境变量MCP_SESSION_BASE_DIR > config.json配置 > 默认路径~/Documents/ide_sessions)
ide_nameYesIDE名称(如: Qoder, VSCode, Cursor, Windsurf, Claude等)，用于分类存储
session_timeNo会话时间(ISO 8601格式,可选,默认为当前时间)
session_descriptionYes会话描述(简短概括本次对话的主题，如：实现用户登录功能、修复数据库bug等)

TDQS

A4.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It discloses that the tool saves markdown files with automatic categorization, and mandates full conversation content. It does not mention file overwrite behavior, authorization needs, or rate limits, leaving some behavioral gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections: purpose, pre-steps, prohibitions, examples, and trigger words. It is front-loaded with purpose. However, it is somewhat verbose; the pre-steps and prohibitions could be condensed without losing clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 5 parameters, no output schema, and no annotations, the description covers essential usage: content formatting, directory resolution, and prohibited actions. It lacks explicit info on return values or confirmation of success, but for a save operation this is acceptable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, baseline is 3. The description adds significant meaning beyond schema, especially for 'content' with detailed format requirements, examples, and prohibited patterns. It also explains fallback logic for 'base_dir'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool saves AI conversation as a Markdown file, auto-categorized by IDE and date. It is clearly distinct from sibling tools (delete, list, read, search) with a specific verb and resource.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides trigger words for when to call (e.g., 'save current session') and explicit prohibited behavior (no summaries, no omissions). However, it does not explicitly discuss when not to use or compare to alternatives, though siblings are distinct.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_sessionsA

【搜索会话】当用户说"搜索包含 XX 的会话"、"查找关于 XX 的对话"、"找一下 XX 相关记录"、"哪些会话提到了 XX"等时调用。在会话文件名和内容中搜索关键词，不区分大小写。触发词：搜索、查找、找、包含、相关会话/对话/记录

ParametersJSON Schema
NameRequiredDescriptionDefault
keywordYes要搜索的关键词(不区分大小写，会在文件名和内容中匹配)
base_dirNo会话保存的基础目录路径(可选,优先级最高。未指定时依次使用: 环境变量MCP_SESSION_BASE_DIR > config.json配置 > 默认路径)
ide_nameNoIDE名称(可选,用于缩小搜索范围到特定IDE)
date_filterNo日期过滤(可选,格式: YYYY-MM-DD，用于在特定日期的会话中搜索)

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full weight. It discloses case-insensitive search across both filename and content, but lacks details on pagination, result limits, or what happens if no matches found. The core behavior is clear but not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with only a few sentences, front-loading the purpose and trigger phrases. Every sentence adds value, and there is no unnecessary information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers trigger phrases, search scope, and case-insensitivity. It also hints at base_dir fallback logic. However, it does not describe the return format (e.g., list of sessions, matched snippets). Given no output schema, this gap slightly reduces completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with all parameters described. The description reinforces the keyword parameter's case-insensitivity and search scope, but adds little beyond the schema. The baseline of 3 is appropriate given high coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states '搜索会话' (search sessions) and provides specific trigger phrases for invocation. It distinguishes from sibling tools like delete_session, list_sessions, read_session, save_session by focusing on searching across files and content.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes explicit trigger phrases like '搜索包含 XX 的会话' and '查找关于 XX 的对话', giving clear context for when to use the tool. It does not explicitly mention when not to use or provide alternatives, but the usage context is strong.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

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

  1. 5 tool updatesv1.3.1
    • Addeddelete_session
    • Addedlist_sessions
    • Addedread_session
    • Addedsave_session
    • Addedsearch_sessions
  2. 5 tool updates
    • Removeddelete_session
    • Removedlist_sessions
    • Removedread_session
    • Removedsave_session
    • Removedsearch_sessions
  3. 5 tool updates
    • First observeddelete_session
    • First observedlist_sessions
    • First observedread_session
    • First observedsave_session
    • First observedsearch_sessions
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4/5.0

Scored across 5 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: delete, list, read, save, and search. There is no overlap in functionality, and the descriptions provide clear context for when to use each.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case (e.g., delete_session, list_sessions), making them predictable and easy to differentiate.

Tool Count5/5

With 5 tools, the server is well-scoped for its purpose of managing saved sessions. The number is neither too many nor too few, providing essential operations without unnecessary complexity.

Completeness4/5

The tool set covers the core CRUD operations (save, read, delete) plus listing and searching. A minor gap is the lack of an update/rename tool, but this is not critical for the domain.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Claude Code History MCP Server

    yudppp
    A
    license
    A
    quality
    D
    maintenance
    An MCP server that enables users to retrieve, filter, and search through Claude Code conversation history stored in local projects. It provides tools for listing projects and sessions, paginating through message history, and searching across conversations with keyword filtering.
    4
    13 npm
    11
    MIT

  • Nemo

    gabriellangon
    F
    license
    Not graded
    quality
    D
    maintenance
    An MCP server that enables users to transform AI conversations into a structured, searchable knowledge base by saving ideas, code snippets, bookmarks, and reminders. It supports persistent storage through Supabase or PostgreSQL and includes webhook integrations for automating workflows with external tools.
    -

  • MCP Docs Server

    hamada-minoro
    F
    license
    Not graded
    quality
    D
    maintenance
    A centralized MCP server for internal technical documentation that integrates with IDEs like Claude Code and VS Code, enabling semantic search and management of Markdown documents via natural language.
    -