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., "@Chronicle Beta search my past conversations for discussions about Python deployment"
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 personal RAG memory system that turns your AI conversation history into a searchable, retrievable knowledge base. Designed to work with any LLM via MCP (Model Context Protocol).
Chronicle Beta ingests your exported AI conversations, chunks and embeds them into a local vector store, and exposes a retrieval interface via MCP. When connected to an LLM like Claude, the LLM can semantically search your entire conversation history. It finds relevant context, past decisions, code snippets, and ideas on demand.
The LLM handles query decomposition and answer synthesis. Chronicle handles storage and retrieval.
Related MCP server: OmniHub
Your LLM (via MCP) -> Chronicle MCP Server -> Retriever -> ChromaDB
↑
Ingestion: parser -> embedder -> vector storeTwo MCP tools:
retrieve_chunks - semantic search with optional metadata filters and date ranges
health_check - connectivity and status probe
Stack:
ChromaDB (persistent local vector store)
all-MiniLM-L6-v2 (sentence-transformers, ~22MB, runs locally)
MCP over stdio (JSON-RPC)
Full setup guide -> step-by-step instructions for macOS, Windows (WSL), and Linux, including how to install prerequisites.
The short version:
mkdir -p ~/Projects && cd ~/Projects
git clone https://github.com/AnirudhB-6001/chronicle_beta.git
cd chronicle_betaExport your ChatGPT data (Settings -> Data Controls -> Export Data), unzip the archive, and place conversations.json in the data/ folder:
chronicle_beta/
└── data/
└── conversations.json ← place it hereThen run the install script:
bash scripts/install.shThe script handles everything: verifies Python 3.10+, creates a virtual environment, installs dependencies (~2 GB first run), parses your conversations, embeds them into a local vector store, and prints the MCP config for Claude Desktop. It is idempotent, safe to re-run at any point, skipping completed steps.
Follow the printed instructions to connect to Claude Desktop, then ask Claude:
"Use chronicle health_check"
If it responds with status: ok and sample titles from your conversations, you're done.
Requirements: Python 3.10+, ~3 GB disk space, 30–90 minutes for first setup. See the full guide for how to install Python and other prerequisites on your OS.
See the Troubleshooting Guide for solutions to common installation, ingestion, and MCP connection issues across all platforms.
python -m scripts.embed_and_index \
--input data/chunks.json \
--db-path data/vector_store \
--collection chronicle_memory \
--model all-MiniLM-L6-v2 \
--batch-size 100 \
--reset # drop and rebuild collectionThe retrieve_chunks tool supports:
retrieval_query - string or list of strings for multi-query retrieval
k - number of results (default: 8)
date_from / date_to - ISO date strings for time-window filtering
filters - metadata filters: type, project, source, title, author, path
Chronicle Beta includes an evaluation pipeline for measuring retrieval quality.
# Run the eval suite
python -m eval.run_eval --dataset eval/golden_questions.jsonSee docs/eval.md for details on metrics (Precision@k, Recall@k, MRR, NDCG).
chronicle_beta/
├── mcp_server/
│ ├── server.py # MCP JSON-RPC server (2 tools)
│ └── tools/
│ └── retrieve_chunks.py # Retrieval tool wrapper
├── retriever/
│ └── core.py # Callable retriever: search(q, k, filters, dates)
├── scripts/
│ ├── install.sh # One-command setup (install + ingest)
│ ├── parser.py # ChatGPT export -> chunks.json
│ └── embed_and_index.py # Chunks -> ChromaDB (stable IDs, rich metadata)
├── tests/ # Unit + integration tests
├── eval/ # Evaluation pipeline + golden datasets
├── data/ # User data directory (gitignored)
├── docs/ # Documentation
│ ├── QUICKSTART.md # Full setup guide (macOS, Windows, Linux)
│ ├── TROUBLESHOOTING.md # Solutions to common issues
│ └── eval.md # Evaluation metrics and methodology
├── .github/ISSUE_TEMPLATE/ # Issue templates (setup, retrieval, feature request)
├── CONTRIBUTING.md # Contribution guidelines
├── pyproject.toml
├── LICENSE # Apache 2.0
├── SECURITY.md # Vulnerability reporting
└── README.mdChronicle Beta is local-first by design. Your conversation data never leaves your machine.
No cloud dependencies. Embeddings are computed locally using sentence-transformers. No OpenAI API, no external embedding services.
No telemetry. Chronicle Beta does not phone home, collect analytics, or transmit any data.
No API keys required. Everything runs on your hardware.
All user data is gitignored. The data/ directory (conversations, chunks, vector store) is excluded from version control by default.
MCP data flow. When connected to an LLM client like Claude Desktop, retrieved chunks are sent to the LLM via stdio for answer synthesis. At that point, the LLM provider's data handling policies apply. Chronicle Beta itself does not control what happens after chunks leave the MCP interface.
See SECURITY.md for vulnerability reporting instructions.
Chronicle Beta v0.1.x was released under the Apache 2.0 license.
From v0.2.0 onwards, Chronicle Beta is licensed under the GNU Affero General Public License v3.0 (AGPL-3.0).
You are free to use, modify, and distribute this software for personal and open-source use.
Any commercial use, hosted deployment, or product built on Chronicle requires explicit written permission from the author.
Copyright (C) 2024-2026 Anirudh Batra Contact for commercial licensing: [hello@anirudhbatraofficial.com]
See LICENSE for full terms.
Light connectivity and status probe. Returns server info, environment flags, and runs a tiny test retrieval to verify the vector store is accessible.
| Name | Required | Description | Default |
|---|---|---|---|
| probe_query | No | Optional test query to verify retrieval works (default: 'test'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses returns (server info, environment flags) and behavior (runs test retrieval to verify accessibility). The phrase 'light probe' implies non-destructive, though read-only is not explicitly stated.
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 effectively conveys purpose, output, and verification behavior without redundancy. Every phrase earns its place.
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 tool with one optional parameter and no output schema, the description covers what it does, what it returns, and how it verifies. It omits return format details, but these are not critical for a health check.
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 coverage is 100% for the single parameter (probe_query). The description's mention of 'tiny test retrieval' complements the schema by linking the parameter's purpose, but adds minimal extra meaning beyond what the schema already provides.
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 states 'Light connectivity and status probe' with clear verb 'probe' and resource (server/vector store). It distinguishes from sibling retrieve_chunks by framing as a connectivity test rather than actual retrieval.
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?
Clear context implies use for checking health/connectivity, reinforced by 'tiny test retrieval' suggesting it is not for real queries. Does not explicitly name alternatives or exclusions, but context alone is sufficient for a simple probe tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run Chronicle retrieval for one string query or a list of sub-queries; return standardized chunks with metadata. Supports optional date window and metadata filters.
Best practices for the calling LLM:
Decompose complex questions into 3-5 focused keyword queries.
Use array syntax: ["topic keywords", "related concept"] not full sentences.
Use filters when you know the content type or project.
Use date_from/date_to for temporal queries.
The returned chunks contain source_name, timestamp, relevance_score, content_raw, content_type, and project fields. The calling LLM should synthesize an evidence-based answer from these chunks, citing sources and presenting an evidence timeline.
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | Number of results per query (default: 8). | |
| date_to | No | Inclusive end date filter (YYYY-MM-DD). | |
| filters | No | Optional metadata filters. Supported keys: type (chat|code|doc|unknown), project, source, title, author, path. All filters are case-insensitive substring matches. | |
| date_from | No | Inclusive start date filter (YYYY-MM-DD). | |
| retrieval_query | Yes | One or more retrieval queries. Use keyword-dense phrases, not full sentences. Array of 3-5 variations recommended for complex questions. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It thoroughly explains the behavior: it accepts one or more queries, returns structured chunks with listed fields, and instructs the LLM to synthesize evidence-based answers. It doesn't explicitly state read-only behavior or rate limits, but 'retrieve' implies it, and the return format and no-side-effect expectation are clear.
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 opening sentence, a bulleted list of best practices, and a final paragraph about return fields and follow-up synthesis. It is somewhat lengthy but every section earns its place by providing practical guidance. The bullet points improve scanability.
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 5 parameters, nested objects, and no output schema, the description covers all key aspects: what the tool does, how to structure queries, when to use filters, and what fields are returned. It also provides downstream instructions for the calling LLM. It doesn't mention error handling or pagination, but these are not essential for the tool's core purpose, so the completeness is high.
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 schema already provides 100% coverage of parameter descriptions. The description adds meaningful guidance beyond the schema, such as recommending 3-5 keyword-dense query variations, using array syntax instead of full sentences, and explaining how filters and date parameters should be used. This elevates the semantic clarity beyond the baseline.
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 runs Chronicle retrieval for a string or list of sub-queries and returns standardized chunks with metadata. It mentions optional date window and metadata filters, and the first sentence is specific and action-oriented. The sibling 'health_check' is clearly unrelated, so this tool is well-differentiated.
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 includes a dedicated 'Best practices for the calling LLM' section with explicit guidance on decomposing complex questions, using array syntax, applying filters, and using date filters. It tells the agent exactly when and how to use the tool, effectively substituting for absence of sibling alternatives.
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. Dates show when Glama detected each change.
v0.1.0health_checkretrieve_chunksThe two tools are completely distinct: retrieve_chunks handles data retrieval while health_check verifies connectivity/status. There is no overlap or ambiguity between their purposes.
Both tools follow a clear verb_noun pattern using snake_case (retrieve_chunks, health_check). The naming convention is consistent and predictable.
With only 2 tools, the set feels thin for a full-featured retrieval server, though it covers the core retrieval use case plus a health check. It is borderline but could be expanded.
The retrieval operation is well-covered with filtering and date windows, and health_check provides necessary diagnostics. However, there are no tools for browsing available filters, projects, or content types, which agents might need.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Persistent personal memory for AI assistants — save, search, and recall across every MCP client.
Persistent memory for AI agents — log and recall conversation context over MCP.
Private persistent memory for Claude, ChatGPT & Gemini via MCP - semantic search, zero-code setup.
Persistent, portable memory for AI assistants — your private memory graph, from any MCP client.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/AnirudhB-6001/chronicle_beta'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
