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., "@Pensieve MCP Server search my conversations for project planning discussions"
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 MCP (Model Context Protocol) server that enables conversation history sharing between ChatGPT and Claude with multi-user support and cloud deployment.
Multi-user Support: Each user has their own isolated conversation space
Authentication: Secure JWT-based authentication
Cloud Deployment: Deploy to Azure Container Apps
Save Conversations: Store conversation history securely
Load Conversations: Retrieve saved conversations by ID
List Conversations: View all saved conversations
Search Conversations: Search conversation content by keywords
Append to Conversations: Add new messages to existing conversations
Related MCP server: Conversation Handoff MCP
Clone the repository:
git clone <repository-url>
cd pensieve-mcpInstall dependencies:
uv pip install -e .Open Claude Desktop configuration file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Add the following configuration:
{
"mcpServers": {
"pensieve-mcp": {
"command": "uv",
"args": ["run", "python", "-m", "mcp_server.server"],
"cwd": "/path/to/pensieve-mcp"
}
}
}Restart Claude Desktop
Use the save_conversation tool to save the current conversation.
You can add metadata like title or tags.
Use the load_conversation tool to retrieve a previous conversation by its ID.
Use the search_conversations tool to find conversations containing specific keywords.
Conversation data is stored as JSON files in the ~/.pensieve-mcp/conversations/ directory.
API Server: FastAPI backend deployed on Azure Container Apps
Database: Azure Cosmos DB (MongoDB API)
Authentication: JWT-based user authentication
MCP Client: Connects to the cloud API
Prerequisites:
Azure CLI installed and logged in
Docker installed
Deploy to Azure:
cd deploy
./deploy-azure.shConfigure MCP client: Set the API URL in your environment:
export PENSIEVE_API_URL="https://your-api-url.azurecontainerapps.io"Register a new account:
Use the 'register' tool with your email and passwordLogin:
Use the 'login' tool with your credentialsYour token will be automatically saved for subsequent requests.
기존 대화에 메시지를 추가합니다
| Name | Required | Description | Default |
|---|---|---|---|
| conversation_id | Yes | 대화 ID | |
| messages | Yes | 추가할 메시지 목록 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the action (append) but doesn't cover permissions, side effects, response format, or error handling. This leaves significant gaps 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 a single, efficient sentence with zero waste. It's front-loaded and appropriately sized for the tool's purpose, making it easy to parse.
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 complexity of a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavior, outcomes, and integration with sibling tools, leaving the agent with insufficient context.
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 fully documents the two parameters (conversation_id and messages). The description adds no additional meaning beyond what's in the schema, meeting the baseline for high coverage.
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 '기존 대화에 메시지를 추가합니다' (Appends messages to an existing conversation) clearly states the action (append) and resource (conversation), but it's vague about scope and doesn't distinguish from siblings like 'save_conversation'. It's functional but lacks specificity.
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 is provided on when to use this tool versus alternatives like 'save_conversation' or 'load_conversation'. The description implies usage for adding messages but offers no context on prerequisites, exclusions, or typical scenarios.
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 |
|---|---|---|---|
| limit | No | 조회할 대화 수 (기본값: 50) | |
| offset | No | 시작 위치 (기본값: 0) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While '조회합니다' (retrieve/list) implies a read-only operation, the description doesn't mention pagination behavior (implied by limit/offset parameters), rate limits, authentication requirements, or what constitutes 'stored' conversations. This leaves significant gaps for a tool that presumably accesses user data.
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 in Korean that directly states the tool's purpose. There's no wasted language or unnecessary elaboration. However, it could be slightly more front-loaded with key distinguishing information given the sibling tools.
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 data retrieval tool with no annotations and no output schema, the description is insufficient. It doesn't explain what information is returned (conversation titles, dates, IDs?), the format of results, error conditions, or how 'stored conversations' are defined. The agent lacks crucial context to use this tool effectively.
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% description coverage with clear documentation of both parameters (limit and offset with defaults). The tool description adds no parameter information beyond what's in the schema. According to scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description.
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 verb ('조회합니다' - retrieve/list) and resource ('저장된 대화 목록' - stored conversation list), which gives a basic understanding of the tool's function. However, it doesn't distinguish this tool from sibling tools like 'search_conversations' or clarify what 'stored conversations' means versus other conversation types that might exist in the system.
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 'load_conversation'. There's no mention of prerequisites, typical use cases, or exclusion criteria. 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.
저장된 대화를 불러옵니다
| Name | Required | Description | Default |
|---|---|---|---|
| conversation_id | Yes | 불러올 대화 ID |
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 action ('불러옵니다' - loads) but doesn't clarify if this is a read-only operation, what permissions are required, how errors are handled (e.g., invalid ID), or the return format. This leaves significant gaps in understanding the tool's behavior beyond the basic 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 a single, efficient sentence ('저장된 대화를 불러옵니다') that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple tool, though it could be more front-loaded with additional context if needed.
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 complexity (a read operation with one parameter) and the absence of annotations and output schema, the description is incomplete. It doesn't explain what '불러옵니다' entails (e.g., returns conversation data, metadata, or both), error conditions, or how it fits with siblings, making it inadequate for full contextual understanding.
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% description coverage, with 'conversation_id' clearly documented as '불러올 대화 ID' (ID of the conversation to load). The description doesn't add any meaning beyond this, such as format examples or sourcing hints. According to the rules, with high schema coverage, the baseline is 3 even without param info in the description.
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 '저장된 대화를 불러옵니다' (Loads a saved conversation) clearly states the verb ('불러옵니다' - loads) and resource ('저장된 대화' - saved conversation), making the basic purpose understandable. However, it doesn't differentiate from siblings like 'search_conversations' or 'list_conversations' in terms of scope or function, leaving the distinction ambiguous.
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. It doesn't mention prerequisites (e.g., needing a conversation_id from 'list_conversations'), exclusions, or comparisons to siblings like 'search_conversations' for filtering or 'append_to_conversation' for updates, leaving usage context unclear.
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 |
|---|---|---|---|
| conversation_id | No | 대화 ID (없으면 자동 생성) | |
| messages | Yes | 저장할 메시지 목록 | |
| metadata | No | 대화에 대한 추가 메타데이터 (제목, 태그 등) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but reveals minimal behavior. It implies a write operation ('저장합니다' - saves) but doesn't disclose permissions needed, whether it's idempotent, error conditions, or side effects. It mentions auto-generation of conversation_id if missing, which is useful, but lacks details on storage format, persistence, or response format.
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 with no wasted words. It's appropriately brief given the tool's straightforward name, though this conciseness comes at the cost of detail. Every word earns its place in conveying the core action.
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 mutation tool with 3 parameters, nested objects, no annotations, and no output schema, the description is insufficient. It doesn't explain what happens on success/failure, return values, or how it interacts with sibling tools. The auto-generation hint for conversation_id is helpful but doesn't compensate for missing behavioral and contextual details.
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 parameters are well-documented in the schema. The description adds no parameter-specific information beyond the schema's details for conversation_id, messages, and metadata. Baseline score of 3 applies as the schema handles parameter documentation adequately.
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 '대화 내역을 저장합니다' (Saves conversation history) states the basic action but is vague about scope and mechanism. It doesn't specify whether this creates new conversations or updates existing ones, nor does it differentiate from sibling tools like 'append_to_conversation' or 'load_conversation'. The description essentially restates the tool name without adding meaningful specificity.
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 is provided on when to use this tool versus alternatives. It doesn't mention prerequisites, when to choose 'save_conversation' over 'append_to_conversation' for updates, or how it relates to 'list_conversations' or 'search_conversations'. The description offers no context for decision-making among siblings.
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 |
|---|---|---|---|
| query | Yes | 검색할 텍스트 | |
| limit | No | 최대 결과 수 (기본값: 20) |
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 only states the action (search) without mentioning permissions, rate limits, response format, pagination, or whether it's read-only. For a search tool with zero annotation coverage, this leaves critical behavioral traits undocumented.
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 in Korean with zero waste. However, it's under-specified rather than concise—it lacks necessary details, so while it's structurally simple, it doesn't fully earn its place by providing adequate 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 complexity of a search operation, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns, how results are structured, or any behavioral aspects. For a tool with two parameters and no structured support, this minimal description fails to provide enough context for effective use.
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 fully documents the two parameters (query and limit). The description adds no additional meaning beyond what the schema provides, such as query syntax examples or limit constraints. Baseline 3 is appropriate when the schema does all the parameter documentation work.
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 '대화 내용을 검색합니다' (Search conversation content) states a clear verb (search) and resource (conversation content), but it's vague about scope and doesn't distinguish from sibling tools like 'list_conversations'. It doesn't specify what kind of conversations or what 'content' includes beyond the basic purpose.
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 is provided on when to use this tool versus alternatives like 'list_conversations' or 'load_conversation'. The description implies searching within content, but it doesn't specify use cases, prerequisites, or exclusions, leaving the agent to guess based on tool names alone.
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.
v0.1.0append_to_conversationlist_conversationsload_conversationsave_conversationsearch_conversationsScored across 5 tools
Each tool has a clearly distinct purpose: append_to_conversation modifies content, list_conversations retrieves metadata, load_conversation accesses full conversations, save_conversation persists them, and search_conversations finds specific content. There is no overlap in functionality that would cause confusion.
All tool names follow a consistent verb_noun pattern with snake_case (e.g., append_to_conversation, list_conversations). The verbs (append, list, load, save, search) are distinct and appropriately descriptive, making the set predictable and easy to understand.
With 5 tools, this server is well-scoped for managing conversations, covering essential operations like listing, loading, saving, appending, and searching. Each tool earns its place without feeling excessive or insufficient for the domain.
The tool set provides strong coverage for core conversation management tasks, including CRUD-like operations (create via append/save, read via list/load/search). A minor gap is the lack of explicit delete or update tools, but agents can work around this by overwriting or managing storage externally.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Private persistent memory for Claude, ChatGPT & Gemini via MCP - semantic search, zero-code setup.
Persistent AI memory shared across Claude, ChatGPT, coding agents, and compatible MCP clients.
Instantly save notes and conversation handoffs in one AI chat, seamlessly load them in any other.
Memory for deep conversational context across any platform
