Skip to main content
Glama
Leviathan0x0

Chronicle MCP

by Leviathan0x0
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Compile Project Insights

compile_project_insights
Idempotent

Extract structured insights from archived chats: action items, topic indexes, chat comparisons, or Markdown briefs. Get digests instead of raw text.

Instructions

Derive structured insight from archived chats: action items, a topic index, a two-chat comparison, or a Markdown project brief. Use it when you need a digest rather than raw text; to find chats use search_history and to read them use get_chat_logs. insight_type 'action_items': TODOs, checkboxes and 'next' tasks from file_name (or the first of target_chats), returned as a list of strings. 'knowledge_index': chats grouped by topic, returned as {topic: [files], built_at}, or file counts when summary_only=true (use that on large archives); rebuild=true rescans every file. 'compare_chats': shared and unique topics of file_name_a and file_name_b (or the first two target_chats) as Markdown. 'project_brief': merges summaries and action items of target_chats (or file_name) into exports/<brief_title>.md and returns its path. Side effects: 'project_brief' writes or overwrites an export file; 'knowledge_index' rewrites the cached index file. Chat files are never modified.

Input Schema

NameRequiredDescriptionDefault
clientNoArchive namespace (a subfolder of the chats directory). Built-in: 'default', 'cursor', 'chatgpt', 'claude'; any other name creates its own subfolder. Omit to use 'default'.default
rebuildNoFor 'knowledge_index': rescan all chats instead of returning the cached index.
file_nameNoSingle chat file for 'action_items' (or a one-chat 'project_brief'), such as 'my-chat.json'.
brief_titleNoHeading and export file name for 'project_brief' (an existing brief with this title is overwritten).Project Brief
file_name_aNoFirst chat file for 'compare_chats'.
file_name_bNoSecond chat file for 'compare_chats'.
insight_typeYesWhich insight to produce (see the tool description).
summary_onlyNoFor 'knowledge_index': return file counts per topic instead of full file lists.
target_chatsNoChat file names: all of them for 'project_brief', the first two for 'compare_chats', the first for 'action_items'.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed10 schema fields changedv1.6.2
    • addedInput schema / properties / brief_title / description
      Added value: +"Heading and export file name for 'project_brief' (an existing brief with this title is overwritten)."
    • addedInput schema / properties / client / description
      Added value: +"Archive namespace (a subfolder of the chats directory). Built-in: 'default', 'cursor', 'chatgpt', 'claude'; any other name creates its own subfolder. Omit to use 'default'."
    • addedInput schema / properties / file_name / description
      Added value: +"Single chat file for 'action_items' (or a one-chat 'project_brief'), such as 'my-chat.json'."
    • addedInput schema / properties / file_name_a / description
      Added value: +"First chat file for 'compare_chats'."
    • addedInput schema / properties / file_name_b / description
      Added value: +"Second chat file for 'compare_chats'."
    • addedInput schema / properties / insight_type / description
      Added value: +"Which insight to produce (see the tool description)."
    • addedInput schema / properties / insight_type / enum
      Added value: +[
+  "action_items",
+  "knowledge_index",
+  "compare_chats",
+  "project_brief"
+]
    • addedInput schema / properties / rebuild / description
      Added value: +"For 'knowledge_index': rescan all chats instead of returning the cached index."
    • addedInput schema / properties / summary_only / description
      Added value: +"For 'knowledge_index': return file counts per topic instead of full file lists."
    • addedInput schema / properties / target_chats / description
      Added value: +"Chat file names: all of them for 'project_brief', the first two for 'compare_chats', the first for 'action_items'."
  2. First observedv1.5.4

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare write-capable, idempotent, non-destructive, closed-world, and the description builds on that by naming exactly what gets written: 'project_brief' writes/overwrites exports/<brief_title>.md and 'knowledge_index' rewrites the cached index file. It also reassures that 'Chat files are never modified', which is context the flags alone do not convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads purpose and alternative routing, then lays out each insight_type in a compact clause. Dense but every sentence carries mode-specific information; minor redundancy between the description and 100%-covered schema descriptions keeps it from a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter, four-mode tool with a sibling cluster, the description covers purpose, mode selection, side effects, and parameter routing. An output schema exists, and the description still summarizes return shapes ({topic: [files], built_at}, path of written brief) so the agent is not left guessing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, yet the description adds genuine cross-parameter meaning: which parameter each insight_type consumes (file_name or first of target_chats for action_items, file_name_a/b or first two target_chats for compare_chats), and when rebuild/summary_only matter. It stops short of documenting client-namespace or brief_title overwrite nuance, keeping it a 4 rather than a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('Derive structured insight from archived chats') and enumerates the four concrete outputs: action items, topic index, two-chat comparison, and Markdown brief. It also names the sibling tools (search_history, get_chat_logs) that do the adjacent jobs, so an agent can distinguish it without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use ('when you need a digest rather than raw text') plus explicit routing to alternatives for finding and reading chats. Per-mode guidance is also given, e.g. summary_only=true 'on large archives' and rebuild=true rescans every file, so the agent knows the conditions that select each path.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools