Skip to main content
Glama
Leviathan0x0

Chronicle MCP

by Leviathan0x0
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Read Chat Logs

get_chat_logs
Read-onlyIdempotent

Browse archived AI chats page by page or open a selected chat to read a message range, short summary, or metadata—use it after searching to inspect a matching conversation.

Instructions

List archived chats, or read one chat as a message range, a short summary, or metadata. Use it after search_history to open a hit, or with no chat_id to browse the archive page by page. To search by topic use search_history instead. Without chat_id: returns a page header '[Page N of M (Total chats: T)]' followed by file names. With chat_id: view_type 'content' returns messages start_msg..end_msg as plain text with a '... of N total' header, truncating each message to max_msg_len characters and collapsing code blocks to one-line summaries unless summarize_code=false; 'summary' returns the opener and closer; 'metadata' returns {file_name, title, message_count, file_size_bytes, last_modified, saved_at, client}. Older chats are shown pruned to save tokens. Keep ranges small (the default is 20 messages): max_msg_len=0 with a wide range can return a whole transcript. Read-only.

Input Schema

NameRequiredDescriptionDefault
pageNoPage number (1-based) when listing chats without chat_id.
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
chat_idNoChat file or chunk id to read, such as 'my-chat.json' or 'my-chat__part_2.json'. Omit to list chats.
end_msgNoLast message to return (inclusive) for view_type='content'.
per_pageNoChats per page when listing without chat_id.
start_msgNoFirst message to return (1-based) for view_type='content'.
view_typeNoWhat to return for chat_id: message text ('content'), file statistics ('metadata') or a short 'summary'.content
max_msg_lenNoPer-message character cap for view_type='content'; 0 means no cap (can be very large).
summarize_codeNoReplace fenced code blocks with a one-line language and line-count summary to save tokens.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed15 schema fields changedv1.6.2
    • addedInput schema / properties / chat_id / description
      Added value: +"Chat file or chunk id to read, such as 'my-chat.json' or 'my-chat__part_2.json'. Omit to list chats."
    • 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 / end_msg / description
      Added value: +"Last message to return (inclusive) for view_type='content'."
    • addedInput schema / properties / end_msg / minimum
      Added value: +1
    • addedInput schema / properties / max_msg_len / description
      Added value: +"Per-message character cap for view_type='content'; 0 means no cap (can be very large)."
    • addedInput schema / properties / max_msg_len / minimum
      Added value: +0
    • addedInput schema / properties / page / description
      Added value: +"Page number (1-based) when listing chats without chat_id."
    • addedInput schema / properties / page / minimum
      Added value: +1
    • addedInput schema / properties / per_page / description
      Added value: +"Chats per page when listing without chat_id."
    • addedInput schema / properties / per_page / minimum
      Added value: +1
    • addedInput schema / properties / start_msg / description
      Added value: +"First message to return (1-based) for view_type='content'."
    • addedInput schema / properties / start_msg / minimum
      Added value: +1
    • addedInput schema / properties / summarize_code / description
      Added value: +"Replace fenced code blocks with a one-line language and line-count summary to save tokens."
    • addedInput schema / properties / view_type / description
      Added value: +"What to return for chat_id: message text ('content'), file statistics ('metadata') or a short 'summary'."
    • addedInput schema / properties / view_type / enum
      Added value: +[
+  "content",
+  "metadata",
+  "summary"
+]
  2. First observedv1.5.4

TDQS

A4.6/5.0
Behavior4/5

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

Goes well beyond the readOnly/idempotent annotations by disclosing return shapes per view_type, message truncation, code-block collapsing, and that older chats are shown pruned to save tokens. The token-blowup warning is concrete. It stops short of stating whether list results paginate deterministically or what happens on an out-of-range page, so a 4 rather than 5.

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?

The first sentence front-loads the two modes and the routing hint, which is exactly the right ordering. The second paragraph is one long semicolon-chained sentence covering every view_type, which is dense but nearly all of it is load-bearing; a short bulleted split would read better.

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 dual-mode tool with an output schema, the description covers both modes, each view_type, defaults, and the token-risk caveat. Nothing an agent needs to make a correct first call is missing.

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 100%, so the baseline is 3; the description earns an extra point by explaining parameter interactions the schema does not — e.g. max_msg_len=0 combined with a wide range returns a whole transcript, and 'keep ranges small (the default is 20 messages)'. It also ties start/end_msg and view_type to the active chat_id path.

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?

Names specific verbs and resources: list archived chats, or read one chat as a message range, summary, or metadata. It also explicitly separates itself from search_history ('To search by topic use search_history instead'), so an agent can route without opening the 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?

Gives explicit when-to-use scenarios: after search_history to open a hit, or with no chat_id to browse page by page. It also names the exclusion (topic search belongs to search_history), leaving little to inference.

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