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., "@AI Conversation Logger log our conversation about fixing the login bug"
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.
An intelligent MCP (Model Context Protocol) server designed specifically for AI assistants to automatically log and manage conversation history with developers.
🤖 AI-Driven Logging - All content is determined and provided by the AI assistant
📝 Pure Save Mode - MCP only formats and stores, no content extraction or analysis
🔄 Designed for AI Retrospection - Log format optimized for AI to quickly understand project history
🏷️ Smart Organization - Auto-organize by project and date with tagging support
🔍 Powerful Search - Multi-dimensional search by keywords, files, tags, and time range
📊 Context Suggestions - Smart recommendations based on file associations
Related MCP server: MCP Memory Server
npm installnpm run buildAdd MCP server configuration to Claude Code's config file (~/.claude.json):
{
"mcpServers": {
"conversation-logger": {
"command": "node",
"args": ["/path/to/ai-conversation-logger-mcp/dist/index.js"]
}
}
}Restart Claude Code to apply the configuration.
Records every AI-user interaction with structured information:
interface LogConversationParams {
userRequest: string; // User's original request + uploaded file descriptions
aiTodoList: string[]; // AI's execution plan (list even for view-only tasks)
aiSummary: string; // AI's operation summary (3-5 sentences)
fileOperations?: string[]; // File operations in format: "action filepath - description"
title?: string; // Conversation title (optional)
tags?: string[]; // Tag array (optional)
project?: string; // Project name (auto-detected if not provided)
}Search through conversation history with multiple filters:
interface SearchParams {
keywords?: string[]; // Keyword search
filePattern?: string; // File name pattern search
days?: number; // Recent N days
project?: string; // Project filter (defaults to current)
tags?: string[]; // Tag filter
limit?: number; // Result limit (default: 10)
}Get relevant historical context based on current work:
interface ContextParams {
currentInput: string; // Current user input
currentFiles?: string[]; // Currently involved files
project?: string; // Project filter (optional)
}Logs are stored in the project's ai-logs/ directory:
project-root/
├── ai-logs/
│ ├── 2025-08-07.md # Daily conversation logs
│ ├── 2025-08-06.md
│ └── config.json # Project configuration
├── src/
└── ...Each conversation is recorded with the following structure:
## [Timestamp] Title #tags
### 🗣️ User Request
[Original user request]
### 📋 AI Execution Plan
- [x] Completed task
- [ ] Pending task
### 🤖 AI Summary
[Summary of what was accomplished]
### 📂 File Operations
- **Created** `path/to/file` - Purpose description
- **Modified** `path/to/file` - What was changed
- **Deleted** `path/to/file` - Reason for deletion
### 🏷️ Tags
#module #technology #typeAll conversations should be logged, including:
New feature development
Bug fixes (any size)
Code refactoring
Configuration changes
Code explanations and analysis
Technical Q&A
Code reviews
Any project-related dialogue
AI-Driven Content - AI determines what information to log
Complete Context - Include all relevant details for future reference
Focus on "What" not "How" - Emphasize functionality over technical details
Consistent Format - Maintain standardized markdown structure
npm run devnpm testnpm run lint
npm run lint:fixnpm run type-checkTypeScript - Type-safe development
MCP SDK - Model Context Protocol implementation
Node.js - Runtime environment
Jest - Testing framework
MIT
Contributions are welcome! Please feel free to submit a Pull Request.
For issues or suggestions, please open an issue on GitHub.
获取相关上下文建议
基于当前输入和文件推荐历史记录
| Name | Required | Description | Default |
|---|---|---|---|
| currentInput | Yes | 当前用户输入 | |
| currentFiles | No | 当前涉及的文件 | |
| project | No | 项目过滤(可选) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the tool provides suggestions based on input and file history, but doesn't describe what the suggestions look like, whether they're ranked, how many are returned, or any rate limits or authentication requirements. For a suggestion tool with zero annotation coverage, this leaves significant 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (two short sentences) and gets straight to the point without unnecessary elaboration. However, it could be more front-loaded with the most critical information about what type of suggestions are provided.
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 suggestion-generation tool with 3 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what format the suggestions take, what they're useful for, or how they relate to the sibling tools. The agent lacks crucial context about what this tool actually returns and when it should be preferred over alternatives.
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 100%, so the schema already documents all three parameters with Chinese descriptions. The description mentions '基于当前输入和文件推荐历史记录' (based on current input and file recommendation history), which aligns with currentInput and currentFiles parameters but doesn't add meaningful semantic context beyond what the schema provides. The project parameter isn't mentioned in the description at all.
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 states the tool '获取相关上下文建议' (get relevant context suggestions) and mentions it's based on current input and file recommendation history. This provides a general purpose but lacks specificity about what type of suggestions are returned or what 'context' means. It doesn't clearly differentiate from sibling tools like search_conversations or log_conversation.
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 provides no guidance on when to use this tool versus alternatives. There's no mention of when this tool is appropriate versus using search_conversations or other siblings, nor any prerequisites or constraints for usage. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all projects with optional statistics
| Name | Required | Description | Default |
|---|---|---|---|
| includeStats | No | Include statistics for each project |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool lists projects but doesn't cover critical aspects like whether it's read-only (implied by 'list'), pagination behavior, rate limits, authentication needs, or what happens if no projects exist. The mention of 'optional statistics' hints at output behavior but lacks detail.
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 a single, efficient sentence that front-loads the core action ('List all projects') and adds a useful detail ('with optional statistics'). There is zero waste, and every word earns its place, making it easy to parse quickly.
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 tool with no annotations and no output schema, the description is incomplete. It doesn't explain the return format (e.g., list structure, fields), error conditions, or behavioral traits like pagination. The mention of statistics is vague, and without output schema, the agent lacks guidance on what to expect from the tool's execution.
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 100%, with the parameter 'includeStats' fully documented in the schema. The description adds minimal value by mentioning 'optional statistics', which aligns with the schema but doesn't provide additional context like what statistics are included or why to use them. Baseline 3 is appropriate since the schema does the heavy lifting.
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 ('List') and resource ('projects'), making the purpose immediately understandable. It distinguishes the action from siblings like 'search_conversations' by focusing on listing rather than searching. However, it doesn't specify the scope (e.g., all projects accessible to the user) or differentiate from 'get_context_suggestions' in terms of resource type.
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 provides no guidance on when to use this tool versus alternatives like 'search_conversations' or 'get_context_suggestions'. It mentions 'optional statistics' but doesn't explain when to include them or any prerequisites. Usage context is implied at best, with no explicit when/when-not instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
记录AI对话 - 所有会话都要记录
使用规范： • userRequest: 用户原始需求+上传文件说明 • aiTodoList: 你的执行计划清单(即使只是查看也要列出) • aiSummary: 你的操作总结(3-5句话,包括解释、分析等) • fileOperations: 文件操作总结,格式:"动作 文件路径 - 说明"(可为空) • title: 对话标题(可选) • tags: 标签数组(可选)
| Name | Required | Description | Default |
|---|---|---|---|
| userRequest | Yes | 用户原始需求 + 上传文件说明 | |
| aiTodoList | Yes | AI的执行计划清单(即使只是查看也要列出) | |
| aiSummary | Yes | AI的操作总结(3-5句话,包括解释、分析等) | |
| fileOperations | No | 文件操作总结,格式:"动作 文件路径 - 说明"(可为空) | |
| title | No | 对话标题(可选) | |
| tags | No | 标签数组(可选) | |
| project | No | 项目名(可选,自动检测) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly indicates this is a logging/write operation ('记录'), but doesn't specify persistence characteristics, potential side effects, error conditions, or what happens after logging. The description adds some behavioral context through the usage guidelines, but doesn't fully describe the tool's behavior beyond the basic logging action.
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 well-structured with a clear purpose statement followed by organized usage guidelines. It's appropriately sized for a 7-parameter tool with detailed requirements. Every sentence serves a purpose, though the Chinese text could potentially be more concise in some sections. The information is front-loaded with the core purpose first.
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 logging tool with 7 parameters, no annotations, and no output schema, the description provides good parameter guidance but lacks information about what happens after logging. It doesn't specify return values, success/failure indicators, or how the logged data can be retrieved later. The usage guidelines are comprehensive for input preparation, but the overall context of the logging operation is incomplete.
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 100%, so the schema already documents all parameters thoroughly. The description adds value by providing usage guidelines that explain the purpose and format expectations for each parameter (e.g., '3-5句话' for aiSummary, specific format for fileOperations). This goes beyond the schema's basic descriptions and provides practical guidance for parameter usage.
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's purpose: '记录AI对话 - 所有会话都要记录' (Log AI conversations - all conversations must be logged). This is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'search_conversations' or explain how this logging tool relates to those search/retrieval tools.
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 provides explicit usage guidelines with a '使用规范' section that details when and how to use this tool. It specifies required parameters and their purposes, and the statement '所有会话都要记录' (all conversations must be logged) gives clear context about when this tool should be invoked. No explicit alternatives are mentioned, but the guidelines are comprehensive for this specific logging operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
搜索历史对话记录
支持： • 关键词搜索 • 文件名模式搜索 • 时间范围筛选 • 标签过滤
| Name | Required | Description | Default |
|---|---|---|---|
| keywords | No | 关键词搜索 | |
| filePattern | No | 文件名模式搜索 | |
| days | No | 最近N天 | |
| project | No | 项目过滤(默认当前) | |
| tags | No | 标签过滤 | |
| limit | No | 结果数量限制 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While it lists search capabilities, it doesn't describe important behavioral aspects: whether this is a read-only operation, what permissions are needed, how results are returned (format, pagination), whether there are rate limits, or what happens with no matches. For a search tool with 6 parameters and no annotations, this is insufficient.
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 appropriately concise with a clear purpose statement followed by bullet points of capabilities. Every sentence earns its place, though the bullet points could be more efficiently integrated into the main description. The structure is front-loaded with the core purpose first.
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 search tool with 6 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the search returns (conversation objects? summaries? IDs?), how results are ordered, whether there's pagination, or error conditions. The lack of output schema means the description should compensate by explaining return values, which it doesn't.
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 100%, so the schema already documents all 6 parameters thoroughly. The description's bullet points (关键词搜索, 文件名模式搜索, 时间范围筛选, 标签过滤) map to 4 of the 6 parameters but don't add meaningful semantic context beyond what the schema provides. The baseline of 3 is appropriate when the schema does the heavy lifting.
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 searches historical conversation records, which is a specific verb+resource combination. However, it doesn't distinguish this tool from potential sibling tools like 'get_context_suggestions' or 'log_conversation' - we can't tell if those tools also search conversations or perform different functions.
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 provides no guidance on when to use this tool versus alternatives. There's no mention of sibling tools like 'get_context_suggestions' or 'log_conversation', nor any context about when search is appropriate versus listing or logging conversations. The bullet points describe capabilities but not usage scenarios.
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.
get_context_suggestionslist_projectslog_conversationsearch_conversationsScored across 4 tools
The four tools have distinct purposes: get_context_suggestions provides recommendations, list_projects enumerates projects, log_conversation records conversations, and search_conversations finds historical data. There is minor potential confusion between get_context_suggestions and search_conversations, as both involve retrieving conversation-related information, but their descriptions clarify that one is for recommendations and the other for direct searches.
The tool names follow a mixed pattern: get_context_suggestions and search_conversations use verb_noun format, while list_projects and log_conversation use verb_noun but with slight inconsistency in structure. The naming is readable but lacks strict uniformity, as seen in the variation between 'get_' and 'search_' prefixes and the absence of a consistent convention across all tools.
With 4 tools, the count is appropriate for a conversation logging server, covering core functions like listing, logging, searching, and context suggestions. It is slightly lean but reasonable, as each tool serves a distinct role without obvious redundancy or bloat, though it might benefit from additional tools for advanced management tasks.
The tool set covers essential CRUD-like operations for conversation logging: list_projects for reading, log_conversation for creating, and search_conversations for querying, with get_context_suggestions adding utility. Minor gaps exist, such as the lack of update or delete tools for conversations or projects, but agents can likely work around these limitations for basic logging workflows.
One searchable history across every AI coding tool, with secret scanning and a shared task board.
Personal context for every AI: search, read, and write back to your private Markdown library.
Versioned documentation registry and semantic search for AI tools and coding assistants.
AI colleagues that keep your standards, your project and their reasoning between sessions
