The MCP Chat Logger server allows you to save chat histories as well-formatted Markdown files with several useful features:
Automatic Timestamps: Adds timestamps to messages for chronological tracking
Conversation ID Support: Organizes different chat sessions
Custom Save Directory: Lets you specify where chat logs are saved
Easy Integration: Configurable through cursor/cherry studio
Exports chat conversations to structured Markdown files with automatic timestamping and session organization
Click on "Install 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., "@MCP Chat Logger save this conversation with session ID project_planning"
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.
MCP Chat Logger is a small Model Context Protocol server that lets an AI client save a conversation as a readable Markdown file.
Exposes a save_chat_history MCP tool
Writes messages, roles, and timestamps to Markdown
Uses an optional conversation ID in the filename and document header
Stores logs locally in the chat_logs/ directory
Related MCP server: Conversation Handoff MCP
Python 3.10 or newer
An MCP-compatible client
Clone the repository and install the locked dependencies:
git clone https://github.com/AlexiFeng/MCP_Chat_Logger.git
cd MCP_Chat_Logger
uv syncStart the server over stdio:
uv run chat_logger.pyUse an absolute path to your clone. A typical MCP client configuration looks like this:
{
"mcpServers": {
"chat_logger": {
"command": "uv",
"args": [
"--directory",
"/absolute/path/to/MCP_Chat_Logger",
"run",
"chat_logger.py"
]
}
}
}The outer configuration shape can differ between clients; the command and args values remain the same.
save_chat_history accepts:
Field | Type | Required | Description |
| array | Yes | Chat messages containing |
| string | No | Identifier added to the output filename and document header |
Example message list:
[
{"role": "user", "content": "Summarize this experiment."},
{"role": "assistant", "content": "Here are the main findings..."}
]Generated files are written to chat_logs/chat_<timestamp>.md, or chat_logs/chat_<conversation_id>_<timestamp>.md when an ID is supplied.
For clients supported by Smithery:
npx -y @smithery/cli install @AlexiFeng/MCP_Chat_Logger --client claudeConversation logs are written to the machine running this server. Review the content before sharing or committing generated files. The chat_logs/ directory is excluded from Git by default.
uv sync
uv run python -m compileall chat_logger.pyIssues and pull requests are welcome.
Save chat history as a Markdown file
Args:
messages: List of chat messages, each containing role and content
conversation_id: Optional conversation ID for file naming
| Name | Required | Description | Default |
|---|---|---|---|
| conversation_id | No | ||
| messages | Yes |
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 saves to a file but doesn't specify where the file is saved (e.g., local path, cloud storage), permissions required, error handling, or whether the operation is idempotent. This leaves significant gaps in understanding the tool's behavior.
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 and front-loaded with the core purpose, followed by parameter explanations. It avoids unnecessary words, though the formatting with 'Args:' could be slightly more integrated. Overall, it's efficient with minimal waste.
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's moderate complexity (2 parameters, no annotations, no output schema), the description covers the basic purpose and parameters but lacks details on output (e.g., file location, success indicators), error cases, and behavioral traits. It's minimally viable but has clear gaps for a file-saving operation.
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 description adds basic semantics for both parameters ('messages' as a list of chat messages with role and content, 'conversation_id' for file naming), which is valuable since schema description coverage is 0%. However, it doesn't detail the structure of message objects or provide examples, leaving some ambiguity.
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 ('Save chat history') and the output format ('as a Markdown file'), providing a specific verb+resource combination. It distinguishes the tool's function well, though there are no sibling tools to differentiate from, which prevents a perfect score of 5.
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, prerequisites, or context for invocation. It lacks any mention of when-not-to-use scenarios or comparisons with other tools, leaving usage entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
With only one tool, there is no possibility of ambiguity or overlap between tools. The tool's purpose is clearly distinct as it is the sole operation available.
The single tool name 'save_chat_history' follows a clear verb_noun pattern. Since there is only one tool, consistency is inherently perfect with no deviations to assess.
A single tool is too few for a server named 'MCP Chat Logger', which suggests broader logging capabilities. This minimal set feels thin and under-scoped for the implied domain of chat logging.
The tool surface is severely incomplete for a chat logger. It only saves history, lacking essential operations like retrieving, updating, deleting, or listing chat logs, which are core to logging workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Portable AI memory shared across models and harnesses - plain markdown you own.
Shared Markdown notes for MCP-compatible AI tools.
Markdown workspace for AI agents: read, write, organize, and share markdown documents.
Clean, repair, and convert AI-generated Markdown to HTML/PDF/DOCX/PNG; save and share documents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/AlexiFeng/MCP_Chat_Logger'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
