Skip to main content
Glama
Sign In
chat-export-server

chat-export-server

by svergio
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

chat_outline

Read-onlyIdempotent

Builds a turn index with short previews for a chat, warming the SQLite cache for long threads so you can pick start and end indexes before reading or fetching the full payload.

Instructions

Build a turn index with short previews for a chat (auto-warms the SQLite cache for long threads). Prefer before chat_read to choose start/end indexes; use chats_get for the full payload, chat_cache_read when the cache is already warm. Empty/omitted chatId = open tab. Requires browsers_bind.

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>"
    },
    "name": "chat_outline"
  }
}

Input Schema

NameRequiredDescriptionDefault
branchNoConversation branch: active thread only, or all branches when the provider supports them
chatIdNoChat id; omit or empty for the open tab
platformYesProvider id: chatgpt | grok | grok-x | claude | copilot | qwen | deepseek | perplexity
previewCharsNoPreview length per turn (40-300 chars)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.0.4
    • 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; omit or empty for the open tab"
    • addedInput schema / properties / platform / description
      Added value: +"Provider id: chatgpt | grok | grok-x | claude | copilot | qwen | deepseek | perplexity"
    • addedInput schema / properties / previewChars / description
      Added value: +"Preview length per turn (40-300 chars)"
  2. First observedv1.0.3

TDQS

A4.5/5.0
Behavior4/5

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

The annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description adds real behavioral context beyond them: it auto-warms the SQLite cache for long threads, which is a side effect on shared state an agent would not infer. It also states the precondition 'Requires browsers_bind', which the annotations do not express. It stops short of noting any cost/latency of the warm-up or the default preview length, 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 compact sentences, front-loaded with what the tool produces, then routing, then the precondition. Every clause carries information an agent needs; there is no filler or restatement of the title.

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 read-only index builder with a fully documented four-parameter schema and no output schema, the description supplies the missing pieces: the shape of the result (turn index with short previews), the prerequisite binding, the cache side effect, and the alternative tools. Nothing an agent needs in order to call it correctly is absent.

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 description coverage is 100%, including enum values for platform and branch and the 40-300 range for previewChars, so the schema already carries parameter meaning. The description's only parameter-adjacent note is 'Empty/omitted chatId = open tab', which restates the schema's own wording. Baseline 3 is appropriate.

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 ('Build a turn index with short previews for a chat'), and immediately distinguishes the output from siblings by calling it an index of turns rather than a full read or a cache read. An agent can tell what artifact it gets back without consulting 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?

It gives explicit sequencing ('Prefer before chat_read to choose start/end indexes') plus named alternatives with their conditions ('chats_get for the full payload, chat_cache_read when the cache is already warm'). This is a complete routing rule, not vague guidance.

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