Skip to main content
Glama
Sign In
ChatAtlas-local

ChatAtlas-local

by hnt504
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Read a chat

read_chat
Read-onlyIdempotent

Reads a saved conversation message by message, with pagination for long chats and part-by-part access to oversized messages.

Instructions

Read one saved conversation, message by message, numbered from 1. Long chats come a page at a time: carry on with from_message. A very long single message comes in parts: carry on with part.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "chat": "<chat>"
    },
    "name": "read_chat"
  }
}

Input Schema

NameRequiredDescriptionDefault
chatYesThe chat's id from search_chats or list_chats (its start is enough)
partNoFor a message too long for one page: which part of it (default 1)
from_messageNoStart at this message (default 1)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare the safe, read-only, idempotent profile. The description adds valuable behavior beyond annotations: messages are numbered from 1, long chats are paged via from_message, and oversized messages are split into parts via part.

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

Conciseness5/5

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

The description is three compact sentences, front-loaded with the main action and then the pagination behavior. Every sentence earns its place.

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

Completeness4/5

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

For a simple read tool with full schema coverage and annotations covering safety, the description is largely complete. It explains paging and message-part handling, though it leaves return-shape details implicit since there is no output schema.

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, but the description adds conceptual meaning by explaining how from_message and part are used to continue reading across pages and message parts.

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?

The description gives a specific verb and resource: reading one saved conversation message by message. The phrase 'one saved conversation' clearly distinguishes it from the sibling search/list tools that handle collections.

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

Usage Guidelines3/5

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

It explains continuation behavior for long chats and long messages, which is useful usage guidance. However, it does not explicitly say when to choose this tool over search_chats, list_chats, or archive_overview.

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