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

chat-export-server

by svergio
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

chats_get

Read-onlyIdempotent

Retrieve the full export payload for one chat by platform and chat ID from the bound browser, enabling complete dumps of known chats.

Instructions

Return the full ExportPayload for one chat on the bound browser. Prefer for a complete dump of a known chatId; for turn index/previews use chat_outline, for a bounded slice use chat_read, for offline SQLite reuse use chat_cache_*. Empty chatId = currently 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>",
      "chatId": "<chatId>"
    },
    "name": "chats_get"
  }
}

Input Schema

NameRequiredDescriptionDefault
branchNoConversation branch: active thread only, or all branches when the provider supports them
chatIdYesChat id, or empty string for the currently open tab
platformYesProvider id: chatgpt | grok | grok-x | claude | copilot | qwen | deepseek | perplexity

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 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"
    • changedInput schema / properties / chatId / description
      Previous value: -"chat id, or empty string for current tab"New value: +"Chat id, or empty string for the currently open tab"
    • addedInput schema / properties / platform / description
      Added value: +"Provider id: chatgpt | grok | grok-x | claude | copilot | qwen | deepseek | perplexity"
  2. First observedv1.0.3

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, open-world, so the safety profile is covered; the description adds real context beyond them: it requires browsers_bind, and an empty chatId resolves to the currently open tab. It does not describe the shape or size of the ExportPayload, which matters somewhat since there is no output schema.

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?

One dense, front-loaded block: return value first, then routing alternatives, then the chatId edge case, then the prerequisite. Every clause carries information and nothing is padded.

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?

Covers purpose, alternatives, the chatId special case, and the browsers_bind prerequisite for a 3-param read tool with no output schema. The only shortfall is that 'ExportPayload' is named but never characterized, leaving an agent unsure how large or structured the returned dump is.

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 all three parameters including the branch enum are already documented in the schema. The description's 'empty chatId = currently open tab' repeats the schema's own chatId description rather than adding format or size semantics, and branch is not mentioned. Baseline 3 applies.

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 (Return) and resource (the full ExportPayload for one chat) plus the execution context (on the bound browser). It is immediately distinguishable from chat_outline, chat_read, and chat_cache_* by the 'complete dump' scope.

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?

Explicitly says when to prefer this tool ('a complete dump of a known chatId') and names the alternatives with the condition that selects each: chat_outline for turn index/previews, chat_read for a bounded slice, chat_cache_* for offline SQLite reuse. This is exactly the routing an agent needs.

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