chat-export-server

Overview Schema Source Related Servers Discussions Admin

chat_read

Read-onlyIdempotent

Read a bounded slice of chat turns with a maxChars cap and auto-fill the SQLite cache. Use start/end indexes from chat_outline to fetch only the conversation segment you need.

Instructions

Read a bounded slice of chat turns with a maxChars cap (uses/auto-fills the SQLite cache). Prefer after chat_outline for start/end indexes; use chats_get for the entire chat, chat_cache_read for offline cache-only access. Requires browsers_bind when the cache miss needs a host fetch.

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": {
      "platform": "<platform>",
      "chatId": "<chatId>"
    },
    "name": "chat_read"
  }
}

Input Schema

Name	Required	Description
`end`	No	Exclusive end turn index from chat_outline
`start`	No	Inclusive start turn index from chat_outline
`branch`	No	Conversation branch: active thread only, or all branches when the provider supports them
`chatId`	Yes	Chat id to read
`maxChars`	No	Hard cap on returned characters (200-20000)
`platform`	Yes	Provider id: chatgpt \| grok \| grok-x \| claude \| copilot \| qwen \| deepseek \| perplexity

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv1.0.4Nov 11, 2026

addedInput schema / properties / branch / description

Added value: +"Conversation branch: active thread only, or all branches when the provider supports them"

addedInput schema / properties / chatId / description
```
Added value: +"Chat id to read"
```

addedInput schema / properties / end / description

Added value: +"Exclusive end turn index from chat_outline"

addedInput schema / properties / maxChars / description

Added value: +"Hard cap on returned characters (200-20000)"

addedInput schema / properties / platform / description

Added value: +"Provider id: chatgpt | grok | grok-x | claude | copilot | qwen | deepseek | perplexity"

addedInput schema / properties / start / description

Added value: +"Inclusive start turn index from chat_outline"

First observedv1.0.3Nov 11, 2026

TDQS

A4.4/5.0

Behavior4/5

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

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered; the description adds genuinely new behavior — that a read also uses/auto-fills the SQLite cache (a side effect), and that a cache miss requires browsers_bind for a host fetch. It stops short of describing pagination or error behavior on a fetch failure, so it is strong but not exhaustive.

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?

Three short sentences, each doing distinct work: what it does, where it fits in the call sequence with alternatives, and the prerequisite for the fallback path. Nothing is redundant with the annotations or schema.

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 six-parameter read tool with no output schema, it covers the selection decision, the index provenance, and the host-fetch prerequisite. The remaining gap is what a bounded slice actually returns (truncation indicators when maxChars clips), which an agent may need to interpret results.

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

Parameters3/5

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

Schema coverage is 100%, so start/end, maxChars, branch, and platform are already documented with enums and bounds; the baseline is 3. The description adds only the provenance hint that start/end indexes come from chat_outline, which is a modest but real addition beyond the schema.

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 opens with a specific verb and resource ('Read a bounded slice of chat turns') plus the scoping constraint (maxChars cap, SQLite cache), and explicitly separates this from chats_get, chat_cache_read, and chat_outline. An agent can select it without opening a sibling 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?

It states the preferred call sequence ('Prefer after chat_outline for start/end indexes') and names two alternatives with their selecting conditions: chats_get for the entire chat and chat_cache_read for offline cache-only access. It also gives a prerequisite (browsers_bind) for the cache-miss path, which is the one condition that could otherwise cause a silent failure.

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