Chronicle is a production-grade Model Context Protocol (MCP) server designed to sync, clean, format, and index local artificial intelligence chat transcripts. By bridging the gap between local editor history and large language model contexts, Chronicle allows agents to search, compare, retrieve, and reference past conversation logs. It features optimized token-saving heuristics that compress code blocks and limit message lengths, reducing context window utilization by up to 40 percent.
AI providers and editor clients save conversation logs in diverse formats. Chronicle normalizes these structures into a standard role-and-content message format:
ChatGPT Exports: ChatGPT exports conversation histories in recursive mapping node structures. Chronicle traverses and flattens these maps, sorts messages chronologically by creation timestamp, and extracts the plain-text message threads.
Claude Exports: Claude structures messages as flat lists nested under the chat_messages field. Chronicle parses these lists, maps custom sender roles (such as human and assistant) to standard roles, and cleans the text strings.
Generic and Markdown Formats: Chronicle includes parsers for flat JSON message lists (such as Cline or Continue) and structured Markdown logs (mapping headers like User and Assistant to message boundaries).
Large chat logs can quickly exhaust context windows and increase API costs. Chronicle implements proactive token-saving mechanisms:
Code Block Summarization: Automatically replaces verbose code blocks with metadata summaries indicating the programming language and line count. This behavior can be disabled on demand to read full code snippets.
Length Limiting: Truncates extremely long individual messages at a configurable character threshold, appending a notice that the user can re-run the tool with expanded limits if necessary.
To verify these savings, we executed multi-turn conversation benchmarks. The graph below displays total token usage over a sequence of message turns:
By condensing repetitive syntax and large raw code snippets, Chronicle achieves up to 40 percent token savings, directly lowering API usage costs and preventing context-window exhaustion.
To make workspace searches extremely sharp and retrieve context-aware answers, Chronicle incorporates a state-of-the-art retrieval pipeline:
Hybrid Document Splitting: Slices long conversations into logical parts at indexing time. Splits are triggered temporally if a gap of more than 1800 seconds (30 minutes) occurs between consecutive messages, or lexically if the Jaccard similarity of vocabulary sliding groups of 4 messages drops below 0.12. Each split is stored and queried as a virtual document (filename__chunk_idx).
Okapi BM25 Scorer: Replaces naive keyword matching and raw TF-IDF with Okapi BM25 scoring (k1 = 1.5 and b = 0.85). The parameter b = 0.85 enforces an aggressive length penalty, which ensures long, rambling chat logs do not overshadow short, precise bug fixes.
Handoff Receipts Prioritization: Integrates a direct tool to save compact agent state files documenting modified paths, commitments, skipped tests, and next actions. Active handoff receipts are automatically prioritized and bubbled to the very top of search results.
Related MCP server: conversation-history-mcp
The cli.py file serves as the system's entry point, registering a unified chronicle command on the system path via the pyproject.toml configuration (chronicle = "cli:main").
Chronicle features an interactive, zero-dependency TTY setup wizard. Running chronicle setup or executing chronicle without arguments in an interactive terminal starts the setup flow:
The setup wizard is styled with a premium purple theme, supporting arrow-key navigation, spacebar toggles, inline input editing, and real-time path validation!
Keyboard Navigation & Controls
Use the following controls when interacting with the select menu:
Command / Action | Key Control | Description |
Move Highlight |
| Navigates the interactive list focus |
Toggle Checkbox |
| Selects or deselects the highlighted app |
Enter Custom IDE | Navigate to Other & type | Type custom app directory directly inline |
Erase Character |
| Removes characters inside the custom entry |
Confirm & Inject |
| Validates target existence and runs config injection |
Cancel Setup |
| Aborts setup process cleanly |
Wizard Phases & Actions
The wizard guides you through the following phases:
Step | Phase Name | What You Do | Result & Behavior |
Step 1 | Monolithic Split Engine | Input JSON file path (or press | Automatically partitions unified chat history exports |
Step 2 | Storage Directory Configuration | Specify directory path (or press | Creates local storage folder for transcripts |
Step 3 | Interactive IDE Selection | Toggle checkboxes, navigate submenus, type custom targets | Performs TTY selection and checks path validation |
Step 4 | Config Injection & Live Dashboard | Review final summary configuration | Injects server configs into target IDE settings |
HOW TO USE THE WIZARD — A STEP-BY-STEP SHOWCASE GUIDE
Start the Process: Launch the wizard with chronicle setup in your terminal.
Split Monolithic Files: Paste the path to your exported conversations.json (from ChatGPT or Claude). This splits them into clean individual threads inside your chats folder.
Define Your Chats Directory: Keep the default ~/universal-chats folder or type a custom path.
Select Your Target IDEs:
Press Down Arrow to scroll down to VS Code, Trae, etc.
Press Space to toggle selections.
If you select Antigravity, checking it will automatically expand sub-choices (Antigravity IDE, Antigravity 2.0, Antigravity CLI) right underneath!
Scroll down to Other (Enter custom entry) and type any system-specific folder name to add emerging editors.
Real-time Path Validation: If the custom configuration path parent doesn't exist, a warning alerts you at the bottom: ⚠ App/IDE "<name>" was not found on your system.. Erase it with Backspace or type a valid path to proceed.
Complete and Launch: Press Enter to write the JSON configuration file for all selected apps. The Live Environment Dashboard will display a complete summary of your workspace configs.
Run the setup command:
chronicle setupThe wizard asks if you want to partition any monolithic chat logs (such as the single conversations.json from ChatGPT/Claude exports) into separate files in your new storage folder:
── Chronicle Archive Setup ─────────────────────────────────────
Do you want to split a single conversations.json file?
Enter path to export file (or press ENTER to skip): Define the folder path where Chronicle will clean and store all conversation history:
Enter path to folder containing your conversations [Default: ~/universal-chats]:
✓ Using existing storage directory: /Users/username/universal-chats
Successfully set chats directory to: /Users/username/universal-chatsAn interactive selection menu with a premium purple theme. Navigate with the arrow keys, toggle checkboxes with the Spacebar, edit custom inputs inline, and press Enter to confirm:
Please select the applications/IDEs where you want to install Chronicle MCP:
(Use arrow keys to navigate, Space to toggle, Enter to confirm)
[✓] Cursor
[ ] VS Code (Cline / Roo Code)
[ ] Trae IDE
[ ] Claude Code
[ ] Windsurf
[ ] Claude Desktop
[ ] ChatGPT Desktop
❯ [✓] Antigravity
[✓] Antigravity IDE
[ ] Antigravity 2.0
[ ] Antigravity CLI
Other (Enter custom entry): If you enter a custom app/IDE name under "Other" that does not exist on your system, the wizard's built-in path validation checker will instantly display a warning at the bottom:⚠ App/IDE "mycustomide" was not found on your system.
Once selections are confirmed, Chronicle automatically resolves uvx paths on your system, writes the MCP server configuration into each selected app, and presents a live environment dashboard summary:
── Chronicle Environment Live ──────────────────────────────────
✓ Storage Folder : /Users/username/universal-chats
✓ Auto-Saved Configs for: [Cursor, Antigravity IDE]
How to run the server manually:
$ uvx --from chronicle-mcp-server chronicle
recalled in <1ms · 100% local · zero cloud
────────────────────────────────────────────────────────────────When run without subcommands, the chronicle command behaves contextually:
Interactive TTY Terminal: Launches the interactive setup wizard.
Non-TTY/Subprocesses: Launches the stdio transport server for MCP clients.
It accepts options like --chats-folder to configure custom storage directories, and exposes the subcommands add and split.
The CLI implements path resolution logic using Python's sys.platform and pathlib.Path to match standard OS conventions for user directories:
macOS (Darwin): Resolves configurations to the user's home Library folder, typically under ~/Library/Application Support/.
Windows (Win32): Leverages the %APPDATA% environment variable, falling back to ~/AppData/Roaming/ if the variable is not set.
Linux: Follows the XDG base directory specification, resolving to ~/.config/.
The CLI wrapper provides out-of-the-box support for leading AI-assisted development tools and editors:
Cursor: Reads and writes configurations to ~/.cursor/mcp.json.
Claude Code: Integrates with ~/.claude.json.
VS Code (Cline/RooCode/Continue): Standardizes pathing across platforms:
macOS: ~/Library/Application Support/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json
Windows: %APPDATA%/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json
Linux: ~/.config/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json
Trae: Resolves configuration to:
macOS: ~/Library/Application Support/Trae/mcp.json
Windows: %APPDATA%/Trae/mcp.json
Linux: ~/.config/Trae/mcp.json
Dynamic Fallback Engine: For emerging platforms (such as Kiro, MiniMax, Qwen Code, Grok Build, or Antigravity), the CLI employs a fallback search pattern. It first checks for a user home dot-directory configuration (such as ~/.<app_name>/mcp.json). If that directory is missing, it creates the app-specific configuration in the standard application support folder for the respective platform (e.g. ~/Library/Application Support/<app_name>/mcp.json on macOS).
Host clients (like Claude Desktop or Cline) spawn MCP servers within isolated subprocesses that often do not inherit the user's login shell environment variables (such as custom paths defined in .bashrc or .zshrc).
To solve this, the chronicle add utility uses Python's shutil.which("uvx") to scan the host machine path during configuration. It resolves the absolute system path of uvx (such as /opt/homebrew/bin/uvx or /usr/local/bin/uvx) and writes this absolute path directly to the IDE's JSON configuration file.
Users downloading conversational archives from ChatGPT or Claude are often provided with a single monolithic JSON file (such as conversations.json) containing hundreds of distinct threads.
The chronicle split subcommand parses these large payloads and splits them into individual JSON files:
Automatically detects the schema format (nested conversation trees or flat lists).
Identifies thread titles using key fallback fields (checking title, name, and chat_title).
Sanitizes file names to remove platform-forbidden characters (such as /, \, *, ?, :, ", <, >, and |) and limits length.
Resolves filename collisions by appending incremental numeric suffixes.
chronicle split /path/to/conversations.json --out /path/to/output_directoryBy default, Chronicle stores processed archives in ~/.chronicle/chats. You can configure a custom global storage folder using the --chats-folder parameter:
chronicle --chats-folder /path/to/custom/chatsThis saves the target path to a local settings file (~/.chronicle_settings.json), allowing you to centralize your archives across multiple development environments.
Chronicle consolidates its behaviors into 6 versatile, parameterized tools. This design avoids cognitive overhead for client AI models while preserving the server's complete feature set.
search_historyDescription: Unified search and filter interface for local chat transcripts. Supports keyword, Okapi BM25 semantic, date range, and related chat lookups.
Parameters:
query (str, default: ""): The search query string or keywords list.
method (str, default: "semantic"): Search methodology. Supported options:
semantic: Standard semantic retrieval using Okapi BM25 scoring with exponential temporal decay.
keyword: Exact string matching against terms in files.
date_range: Filters files modified within a date interval (requires start_date and end_date).
related: Finds archives semantically close to a reference file.
keywords (list of strings, optional): Optional list of keywords for keyword search.
start_date (str, optional): Start date string (YYYY-MM-DD) for date range filtering.
end_date (str, optional): End date string (YYYY-MM-DD) for date range filtering.
limit (int, default: 50): Maximum result count for keyword or date range searches.
top_k (int, default: 10): Maximum matches for semantic or related chat searches.
client (str, default: "default"): Subfolder client identifier.
file_name (str, optional): Reference chat filename for related search.
get_chat_logsDescription: Unified read interface for stored transcripts. Fetches paginated file lists, summaries, file metadata, or message ranges with token-saving options.
Parameters:
chat_id (str, optional): Filename of the target chat. If omitted, lists all available files.
view_type (str, default: "content"): The type of information to retrieve. Supported options:
content: Message text slice within specified index ranges.
metadata: File statistics including message counts and modification dates.
summary: Structural summary highlighting the opener and closer context.
start_msg (int, default: 1): Message slice start index (1-indexed).
end_msg (int, default: 20): Message slice end index.
max_msg_len (int, default: 1000): Character limit for messages to prevent token inflation. Set to 0 for unlimited.
summarize_code (bool, default: True): Summarizes markdown code blocks into metadata headers.
page (int, default: 1): Page index for folder listing (used when chat_id is omitted).
per_page (int, default: 50): Page result limit for folder listing.
client (str, default: "default"): Subfolder client identifier.
sync_workspace_dataDescription: Ingests, imports, and syncs external conversation transcripts or workspace logs from various tools and formats.
Parameters:
source_type (str): Source type identifier. Supported options:
raw_content: Direct JSON import from text buffers or clipboard paste.
local_path: Copies a JSON file from a local path on disk.
agent_transcripts: Syncs transcripts (JSON, JSONL, MD) from configured third-party client folders.
cursor_agent_transcripts: Deprecated. Scans Cursor workspace project transcript folders.
payload (str, dict, or list, optional): Input data payload (raw JSON text, file path on disk, or folder path).
title (str, optional): Target file name or title for imports.
source_dir (str, optional): Override folder directory for scanning transcripts.
limit (int, default: 50): Maximum files to synchronize.
client (str, default: "default"): Subfolder client identifier.
compile_project_insightsDescription: Aggregates and compiles insights from chat logs, including action item extraction, index indexing, chat comparisons, and brief generation.
Parameters:
insight_type (str): Compilation format. Supported options:
action_items: Extract todos, checkboxes, and task lists.
knowledge_index: Rebuild or list the topic-categorized index of files.
compare_chats: Analyze and detail shared and unique terms across two files.
project_brief: Synthesize summaries and action items from multiple chats into one markdown document.
target_chats (list of strings, optional): List of target chat filenames for briefs or comparisons.
file_name (str, optional): Target chat filename for action item extraction.
file_name_a (str, optional): First chat filename for comparison.
file_name_b (str, optional): Second chat filename for comparison.
brief_title (str, default: "Project Brief"): Title header for compiled briefs.
rebuild (bool, default: False): Re-scans all files to update the knowledge index.
summary_only (bool, default: False): Returns topic file counts instead of full file lists in index lookup.
client (str, default: "default"): Subfolder client identifier.
maintain_storageDescription: Performs server operations, storage cleanups, settings configuration, and capabilities lookup.
Parameters:
op_type (str): Maintenance operation name. Supported options:
compress: Compresses historical archives older than a set age using Gzip.
deduplicate: Content-hash based search and deletion of duplicate logs.
configure: Updates auto-save message limits, paths, and transcripts.
capabilities: Returns server meta-capabilities and client configurations.
settings (dict, optional): Settings payload dict (for configure).
days_old (int, optional): Cutoff threshold age in days for compression.
dry_run (bool, default: True): Lists duplicates without performing deletions.
client (str, default: "default"): Subfolder client identifier.
manage_session_stateDescription: Manages active session caching, folder monitoring, file merges, markdown exports, and file deletions.
Parameters:
action (str): Operation to perform. Supported options:
save: Commits active messages list to storage.
register_auto_save: Registers the session for auto-saving on connection termination.
trigger_auto_save: Instantly flushes pending sessions to disk.
watch_folder: Reports file changes since the last execution.
merge: Appends new messages to an existing chat archive.
export_markdown: Converts a JSON transcript to a Markdown document.
delete: Permanently deletes an archive file (requires confirm=True).
conversation_name (str, optional): Active conversation name.
messages (list of dicts, optional): Message list payload.
force_save (bool, default: False): Saves the chat session even if below message limit thresholds.
file_name (str, optional): Target file name.
confirm (bool, default: False): Confirms deletion.
new_messages (list of dicts, optional): Message list to merge.
client (str, default: "default"): Subfolder client identifier.
save_handoff_receiptDescription: Saves a handoff receipt for the current execution to document the active state (touched files, open promises, skipped checks, next safe actions). Saved receipts are indexed and automatically bubbled to the very top of search results.
Parameters:
touched_files (list of strings): Paths to files modified during the run.
open_promises (list of strings): List of unresolved commitments or tasks left open.
skipped_checks (list of strings): List of tests or validation tasks skipped.
next_safe_action (str): A clear, direct prompt instructing the next agent on exactly what to do next.
client (str, default: "default"): Subfolder client identifier.
Install the package directly from PyPI and run the interactive setup wizard to configure your storage paths and editor integrations automatically:
pip install chronicle-mcp-server
chronicle setupPython 3.10 or higher.
Python packages mcp (Model Context Protocol SDK).
Python setuptools (for installation as a package).
Clone the repository:
git clone https://github.com/Leviathan0x0/Chronicle-MCP.git
cd Chronicle-MCPSet up a Python virtual environment:
python3 -m venv venv
source venv/bin/activateInstall dependencies and the package in editable mode:
pip install -e .Since editors (like Cursor or VS Code) do not notify MCP servers when a chat window or tab is closed, Chronicle implements a multi-step solution to ensure your conversation history is saved automatically:
The Chronicle server includes an exit handler registered via Python's atexit module. When you close a chat tab or close the editor, the editor terminates the stdio connection, shutting down the Chronicle process. Upon receiving this shutdown trigger, the server automatically flushes the registered pending session to the local chats folder.
For this flush to succeed, the active chat session must be registered during the conversation. Chronicle handles this setup automatically: upon server startup, it checks the active project workspace root directory and automatically creates or appends the required rules to all major rule files (such as .cursorrules, .clinerules, .windsurfrules, .clauderules, etc.).
This ensures that the AI agent is automatically instructed to register the session at the start of the chat. The generated rule states:
At the beginning of the chat session, you must call the "manage_session_state" tool with action="register_auto_save" to register this conversation. Provide a descriptive title based on the user's initial prompt. As the conversation progresses, periodically update the registration payload to keep it current.This ensures that the chat history is registered dynamically, and Chronicle will write the complete history to your storage folder as soon as the editor terminates the connection.
Chronicle contains unit and integration tests to verify platform path resolution, parsing logic, and tool compatibility:
To execute the suite of unit tests verifying core business logic:
python3 -m unittest test_chat_connector.pyTo test all 27 tools against the live storage connector:
python3 test_all_tools.pyFeatures | Chronicle MCP | Mem0 | Raw RAG / Naive VecDB |
Cloud Dependency | Local first (Zero Cloud dependencies) | Cloud-reliant | Cloud or complex local setup |
Token Savings | Up to 40% reduction (Smart code folding and pruning) | None (transfers full history) | None |
Setup Complexity | 1-click CLI installer ( | Requires API keys and database configs | High (VecDB setups and loaders) |
Auto-Save Support | Native via workspace rules and exit hooks | Requires manual application integration | None |
Local Resources | Minimal CPU and RAM (light TF-IDF) | Heavy | High (vector indexing overhead) |
We welcome community contributions. To get started:
Fork the repository and create a new branch.
Write unit tests for new behavior inside test_chat_connector.py.
Verify all code changes by running the test suite locally:
python3 -m unittest test_chat_connector.py
python3 test_all_tools.pyEnsure code formatting is clean and all imports are properly sorted.
Submit a pull request detailing your changes and test coverage.
Planned future features and enhancements for Chronicle:
Local Embeddings: Add optional local vector retrieval using lightweight ONNX models.
Database Auditing: Automatic cache cleanups and data integrity audits for historical logs.
Dynamic Tailoring: Specific prompt formats optimized for different LLM host architectures (Claude, GPT, Gemini).
Extended IDE Support: Out-of-the-box config injection scripts for additional emerging developer environments.
General & Setup Inquiries
Q: What is the benefit of the new Interactive Setup Wizard?
A: It completely automates the configuration process. In less than 10 seconds, it configures your storage directory, partitions raw monolithic conversation logs, checks system environments, validates custom paths, and injects configurations into all target applications.
Q: Why does the setup wizard use a purple theme?
A: Chronicle is designed to feel premium and state of the art. The setup wizard uses a vibrant, highly readable purple/magenta theme (
\033[1;35m) with custom cursor pointers (❯) and status checks ([✓]) for an optimized terminal experience.
Q: What happens if a custom app directory is not found on my system?
A: The interactive selector prevents invalid configurations. If you type a custom name under "Other" whose configuration directory cannot be resolved, an alert appears inline at the bottom:
⚠ App/IDE "<name>" was not found on your system.. You can easily backspace and edit the input without losing other selections.
Q: How does the Automatic Session Saving work?
A: Chronicle generates workspace rule files (e.g.
.cursorrules,.clinerules) instructing your AI agent to register the session at startup. On tab or editor shutdown, the server's process exit hooks trigger an automatic flush to write the transcripts to your storage folder.
This project is licensed under the MIT License. See the LICENSE file for details.
Analyze historical logs to extract tasks, briefs, or indices. Options for insight_type: 'action_items', 'knowledge_index', 'compare_chats', 'project_brief'.
| Name | Required | Description | Default |
|---|---|---|---|
| client | No | default | |
| rebuild | No | ||
| file_name | No | ||
| brief_title | No | Project Brief | |
| file_name_a | No | ||
| file_name_b | No | ||
| insight_type | Yes | ||
| summary_only | No | ||
| target_chats | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for disclosing behavioral traits. It only states the high-level action without mentioning side effects, authorization requirements, rate limits, or performance implications. The description does not reveal that the tool may be computationally intensive or require specific data, leaving the agent with incomplete behavioral understanding.
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 short (two sentences) and front-loaded, efficiently conveying the core purpose. However, it could be slightly more informative without adding length, such as by mentioning that the tool produces structured outputs. Nonetheless, it avoids unnecessary verbosity.
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 has 9 parameters, many optional, and an output schema, the description is markedly incomplete. It fails to explain how parameters like rebuild, target_chats, or file_name affect behavior, and it does not clarify relationships to sibling tools. The agent lacks crucial context for correct usage.
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 0%, so the description must compensate. Only the insight_type parameter receives partial explanation via the listed options. The other eight parameters (client, rebuild, file_name, etc.) are not explained at all, leaving their purpose and valid values ambiguous. This insufficient compensation for the schema gap results in poor parameter semantics.
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: analyzing historical logs to extract tasks, briefs, or indices. The verb 'analyze' and resource 'historical logs' are specific, and the listing of insight_type options further clarifies what outputs are possible. It distinguishes itself from sibling tools like get_chat_logs (which retrieves raw logs) by focusing on derived insights.
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 explicit guidance on when to use this tool versus alternatives. It lists insight_type options but does not explain contexts where one type is preferred over another, nor does it mention prerequisites or exclusions. An agent would have to infer usage from the brief description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve lists of files, metadata, summaries, or specific message ranges. Options for view_type: 'content', 'metadata', 'summary'.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| client | No | default | |
| chat_id | No | ||
| end_msg | No | ||
| per_page | No | ||
| start_msg | No | ||
| view_type | No | content | |
| max_msg_len | No | ||
| summarize_code | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It does not mention if it is read-only, authentication needs, side effects, or limits. Only states it retrieves 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?
Two sentences, front-loaded purpose, but lacks structure for a 9-parameter tool. Could enumerate parameters or provide formatting hints.
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?
Despite an output schema, the description omits pagination, filtering mechanics, and parameter defaults. Incomplete for a tool with 9 optional parameters and no annotations.
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 0%. The description only references view_type options, leaving 8 parameters (page, client, chat_id, end_msg, etc.) unexplained.
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 it retrieves lists of files, metadata, summaries, or specific message ranges, but 'files' is misleading since it returns chat logs. It lacks differentiation from sibling tools like search_history.
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 on when to use this tool versus alternatives. Sibling tools exist (e.g., search_history) but no exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the current workspace handoff status, including active chain of receipts, blocked status, and any next safe action.
| Name | Required | Description | Default |
|---|---|---|---|
| client | No | default |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It discloses it is a read operation retrieving status information, but does not mention any side effects, permissions, or rate limits. Adequate but not rich.
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 clear sentence with no wasted words. Front-loaded with verb and resource, efficient.
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 one optional parameter and no output schema, the description provides core purpose and output components, but lacks details on return format or when to call. Adequate but not fully complete.
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 0% and description does not explain the single 'client' parameter, its meaning, or how it affects the results. This is a significant gap.
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 clearly states it retrieves workspace handoff status with specific components (active chain, blocked status, next safe action). Distinguishable from sibling tools like save_handoff_receipt which writes, but could be more explicit about differentiation.
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 on when to use this tool versus alternatives like save_handoff_receipt or get_chat_logs. The description only states what it does, not the context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform storage maintenance, deduplication, configuration, and capabilities retrieval. Options for op_type: 'compress', 'deduplicate', 'configure', 'capabilities'.
| Name | Required | Description | Default |
|---|---|---|---|
| client | No | default | |
| dry_run | No | ||
| op_type | Yes | ||
| days_old | No | ||
| settings | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only lists operation types without explaining side effects, permission requirements, or outcomes of each op_type. The dry_run parameter hints at safe execution but is not elaborated.
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 sentences) but front-loads the purpose. However, it sacrifices clarity by omitting necessary details for each parameter and operation.
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 five parameters, four op_type options, and an output schema, the description is insufficient. It does not explain return values, error cases, or relationships between parameters like days_old and deduplication.
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 0%, so the description must clarify parameters. It only enumerates op_type values, ignoring client, dry_run, days_old, and settings. No default behaviors or allowed values beyond the schema are provided.
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 that the tool performs storage maintenance actions including compress, deduplicate, configure, and capabilities retrieval. However, it bundles multiple distinct operations without specifying what each entails, and does not differentiate from sibling tools like compile_project_insights or sync_workspace_data.
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 the listed siblings. There are no scenarios, prerequisites, or alternatives mentioned, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage session auto-saving, folder watching, merging, exporting, and deletion. Options for action: 'save', 'register_auto_save', 'trigger_auto_save', 'watch_folder', 'merge', 'export_markdown', 'delete'.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| client | No | default | |
| confirm | No | ||
| messages | No | ||
| file_name | No | ||
| force_save | No | ||
| new_messages | No | ||
| conversation_name | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description lacks behavioral details such as side effects (e.g., deletion implications), required permissions, or idempotency of actions. Only lists action names.
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 concise (one sentence) but not well-structured; actions are listed inline without grouping or clarification. It earns its place but could be improved.
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 8 parameters, no annotations, and an output schema not described, the description is insufficient. It does not cover parameter usage, return values, or action-specific 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?
With 0% schema description coverage, the description fails to explain parameters like client, confirm, messages, file_name, etc. It only enumerates actions, leaving all parameters undocumented.
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 manages session state operations and lists specific actions like auto-saving, folder watching, merging, exporting, and deletion. It distinguishes from sibling tools which focus on other aspects.
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 on when to use this tool versus alternatives (e.g., compile_project_insights). The description does not specify contexts or conditions for selecting an action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a structured, continuation-biased handoff receipt conforming to the strict state-machine DAG model.
| Name | Required | Description | Default |
|---|---|---|---|
| client | No | default | |
| status | No | open | |
| closure | No | ||
| evidence | Yes | ||
| receipt_id | No | ||
| supersedes | No | ||
| work_state | Yes | ||
| obligations | Yes | ||
| invalidation | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It hints at behavioral traits ('continuation-biased', 'state-machine DAG model') but does not disclose side effects, overwrite behavior, permission requirements, or error conditions.
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 very short (one sentence, 14 words). While concise, it packs jargon without explanation, making it less useful. It could be clearer without sacrificing brevity.
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 9 parameters, nested objects, and an output schema, the description is completely inadequate. It does not explain the return value, parameter structure, or when to use the tool. A well-rounded description would need several sentences.
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 0%, yet the description provides no information about any of the 9 parameters (4 required). The agent receives no guidance on what 'obligations', 'work_state', 'evidence', or 'invalidation' mean or how to structure them.
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 'Save' and resource 'handoff receipt', indicating a write operation. However, terms like 'continuation-biased' and 'state-machine DAG model' are jargon that reduce clarity. It does not explicitly distinguish from sibling tools like 'get_handoff_status'.
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 on when to use this tool vs alternatives. The description gives no context about prerequisites, conditions, or exclusions. Sibling tools exist but are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search and filter historical transcripts. Options for method: 'semantic', 'keyword', 'date_range', 'related'.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | ||
| top_k | No | ||
| client | No | default | |
| method | No | semantic | |
| end_date | No | ||
| keywords | No | ||
| file_name | No | ||
| start_date | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description merely says 'Search and filter' but does not disclose read-only nature, performance characteristics, or whether results are paginated. Given the lack of annotations, the description carries full burden and fails to provide sufficient behavioral context.
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 very short (one sentence) and front-loads the verb and resource. However, it sacrifices necessary detail for brevity, making it minimally adequate but not optimally structured for an AI agent.
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?
With 9 parameters, no annotations, and an output schema present, the description fails to cover essential aspects like parameter usage, return value structure, or edge cases. It is incomplete for the complexity of the tool.
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 0%. The description only mentions the 'method' parameter's options, leaving all other 8 parameters (limit, top_k, client, end_date, keywords, file_name, start_date, query) completely unexplained. No details on formats, defaults, or relationships.
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 and filters historical transcripts, with specific method options listed. It distinguishes itself from siblings like 'get_chat_logs' which likely retrieves logs directly, but does not explicitly differentiate.
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 on when to use this tool versus its siblings (e.g., compile_project_insights, get_chat_logs). The description only lists method options without explaining their appropriate contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ingest and normalize external conversations or live transcripts. Options for source_type: 'agent_transcripts', 'cursor_agent_transcripts', 'local_path', 'raw_content'.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| title | No | ||
| client | No | default | |
| payload | No | ||
| source_dir | No | ||
| source_type | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description should disclose behavioral traits. It only says 'ingest and normalize' without mentioning whether data is overwritten, if permissions are needed, or any restrictions. The listed source_type options provide minor context but not behavioral details.
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?
Two concise sentences without wasted words. Front-loaded with purpose, then enumerates options. Could benefit from a brief example but is appropriately sized.
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?
Description is incomplete for a 6-parameter tool with an output schema. No information on return values, side effects, or dependencies. Agent lacks enough context to use the tool correctly without guessing.
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 0%. Description only lists possible values for source_type, ignoring other 5 parameters (limit, title, client, payload, source_dir). No explanation of what these parameters do or their expected formats.
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 uses specific verb 'Ingest and normalize' and resource 'external conversations or live transcripts', clearly differentiating from sibling tools like compile_project_insights or get_chat_logs which handle existing data.
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 on when to use this tool versus alternatives, no conditions or prerequisites mentioned. Agent must infer usage from tool name 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. Dates show when Glama detected each change.
v1.5.4compile_project_insightsget_chat_logsget_handoff_statusmaintain_storagemanage_session_statesave_handoff_receiptsearch_historysync_workspace_dataEach tool targets a distinct operation: insights, logs, handoff status, storage maintenance, session management, handoff receipts, search, and data ingestion. No overlapping purposes, making selection unambiguous.
All tool names follow a consistent verb_noun pattern with snake_case (e.g., compile_project_insights, get_chat_logs). No mixing of styles, ensuring predictability.
With 8 tools, the server is well-scoped for its domain of workspace and chronicle management. Each tool serves a clear function without excess or insufficiency.
The tool set covers all key workflows: data ingestion, retrieval, search, analysis, maintenance, session management, and handoff procedures. No obvious gaps for the intended purpose.
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.
Search your AI chat history (ChatGPT, Claude, Codex) from any MCP client. Remote, private, read-only
One memory, every AI: Claude, ChatGPT, Perplexity, Gemini, Cursor, OpenClaw, Hermes, any MCP client.
Persistent memory for AI assistants. Save once; recall from Claude, ChatGPT, or 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/Leviathan0x0/Chronicle-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
