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

chat-export-server

by svergio
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

chat_cache_append

Append new chat turns to an existing local SQLite cache and refresh full-text search and totals for incremental offline updates without writing to the provider UI.

Instructions

Append turns to an existing local SQLite cache copy and refresh FTS/totals. Prefer for incremental offline updates; use chat_cache_sync to rebuild from the live tab, chat_cache_update_block to edit one turn. Does not write to the provider UI.

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": {
      "turns": "<turns>"
    },
    "name": "chat_cache_append"
  }
}

Input Schema

NameRequiredDescriptionDefault
turnsYesOne or more turns to append
chatIdNoChat id when selecting cache by platform+chatId
cacheIdNoCache row id to append into
platformNoProvider id: chatgpt | grok | grok-x | claude | copilot | qwen | deepseek | perplexity

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv1.0.4
    • addedInput schema / properties / cacheId / description
      Added value: +"Cache row id to append into"
    • addedInput schema / properties / chatId / description
      Added value: +"Chat id when selecting cache by platform+chatId"
    • addedInput schema / properties / platform / description
      Added value: +"Provider id: chatgpt | grok | grok-x | claude | copilot | qwen | deepseek | perplexity"
    • addedInput schema / properties / turns / description
      Added value: +"One or more turns to append"
    • addedInput schema / properties / turns / items / properties / content / description
      Added value: +"Alternate content field when text is not used"
    • addedInput schema / properties / turns / items / properties / role / description
      Added value: +"Turn role (user/assistant/system/tool)"
    • addedInput schema / properties / turns / items / properties / text / description
      Added value: +"Plain text body for the turn"
  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?

Beyond the annotations, it discloses that the write targets a local SQLite cache, that FTS indexes and totals are refreshed, and critically that it "Does not write to the provider UI" — a boundary an agent could not infer from destructiveHint=false alone. It does not say what happens on duplicate turns or partial failures, which is why it falls short of a 5.

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?

Two sentences, zero filler, with the primary action and scope front-loaded before the sibling routing. Every clause carries information an agent needs.

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 four-parameter local mutation tool with full schema coverage and no output schema, the description covers action, side effects, alternatives, and the provider-UI boundary. It stops short of describing the result of an append or how conflicting cacheId/platform+chatId combinations resolve.

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% with all four parameters documented, so the schema already carries the semantics. The description adds no format or selection detail (e.g. cacheId vs platform+chatId precedence), so the 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 and resource ("Append turns to an existing local SQLite cache copy") plus the side effect ("refresh FTS/totals"), which distinguishes it from sync and edit siblings without opening 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?

Explicitly routes: "Prefer for incremental offline updates", with named alternatives — chat_cache_sync for rebuilds from the live tab, chat_cache_update_block for editing a single turn. The when and the when-not are both stated.

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